Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 27 Feb 2015 11:56:25 -0800 | Subject | Re: [PATCH] x86, traps: install gates using IST after cpu_init(). |
| |
On Thu, Feb 26, 2015 at 8:34 PM, Wang Nan <wangnan0@huawei.com> wrote: > On 2015/2/26 23:14, Andy Lutomirski wrote: >> On Wed, Feb 25, 2015 at 10:15 PM, Wang Nan <wangnan0@huawei.com> wrote: >>> X86_TRAP_NMI, X86_TRAP_DF and X86_TRAP_MC use their own stack. Those >>> stacks are invalid until cpu_init() installs TSS. >>> >>> This patch moves setting of the 3 gates after cpu_init(). >>> >>> Signed-off-by: Wang Nan <wangnan0@huawei.com> >>> --- >>> >>> If I understand correctly, logically speaking the original code is >>> incorrect. However, there is no real bug caused by it for serval years. >>> I'm not sure whether this fix is practical or not. Fix them only for >>> logical correctness. >> >> Acked-by: Andy Lutomirski <luto@amacapital.net> >> >> That being said, I'm pretty sure you're not fixing a bug here. > > Agree. > >> Delivery of an exception with no handler is every bit as fatal as >> delivery of an exception with a non-working IST handler. >> > > Just curious: in original code, what will happen if an NMI or MC raises after > 'set_intr_gate_ist(X86_TRAP_NMI, &nmi, NMI_STACK);' and before cpu_init()? > In my opinion, at that time the interrupt handler is set but IST is not ready. > > In addition, why it's never happened for real? Does it means NMI is possible > to be disabled?
It means that no NMI sources are enabled (hopefully) that early. If they were, we'd be doomed -- AFAIK it's impossible to maintain a continuously valid IDT all the way through the transition from real mode to long mode. (Maybe I'm wrong and there's some trick that would work.)
--Andy
> > Thank you! > >> --Andy >> > >
-- Andy Lutomirski AMA Capital Management, LLC
| |