[Xen-devel] Boot time trap handling

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

Hello,

When reviewing the SMAP series, Jan noticed an issue I had overlooked
while developing 7e510a7b874fa "x86/boot: move some __high_start code
and data into init sections".

All interrupts we expect to receive are indeed replaced with real
handlers, but the reserved exceptions are left as-are pointing at
ignore_int().  With ignore_int() in the init section, it will point
somewhere arbitrary after boot.  This is obviously a bad thing, but the
previous behaviour wasn't much more useful in this regard, by locking up
a pcpu without bringing the system down.

While attempting to fix this issue, I discovered some more concerning ones.

On the BSP, we:
* load the empty 'idt_table'
* patch ignore_int() into every entry (and indeed, bottom first which is
rather unsafe)
* enter __start_xen()
* patch in early_page_fault()
* perform large mounts of setup
* enter trap_init()
* patch the real trap handlers into 'idt_table'
* Set up ISTs for #DF, #NMI, #MCE in 'idt_table'
* Set up IST stacks in our local TSS
* Load our local TSS

On APs, we:
* Load mmu_cr4_features, including CR4.MCE
* Load the BSPs 'idt_table', complete with IST information
* Set up IST stacks in our local TSS
* Load our local TSS
* Switch onto our own local memcpy() of the BSPs idt.

In both cases, until we have loaded the TSS, we risk trying to take an
MCE or NMI without a TSS loaded.  I cant spot which contributory
exception would be generated, but I suspect #NP, or possibly #TS.  With
#DF set up in the same way, we will triple fault.


Looking at the real trap handlers, they appear to be safe from almost
the start of __start_xen().  Therefore, I propose:

* The boot critical region with an empty idtr gets extended slightly
into the top of __start_xen() and start_secondary()
* Inside this critical region, set set up and load the TSS.
* Load ourselves onto our local idt.
* Load cr4, after the MCE entry path is valid.

This has the added advantage that we gain full bugframe and extable
support for the earlier parts of setup.

Is there anything I have overlooked, or does this plan look plausible?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel