linux-kernel - Re: [PATCH v2 2/2] KVM: VMX: Invoke NMI handler via indirect call instead of INTn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 26 Apr 2021 09:59:07 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Maxim Levitsky <mlevitsk@...hat.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Lai Jiangshan <jiangshanlai+lkml@...il.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Uros Bizjak <ubizjak@...il.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v2 2/2] KVM: VMX: Invoke NMI handler via indirect call
 instead of INTn

On Mon, 26 Apr 2021 14:44:49 +0300
Maxim Levitsky <mlevitsk@...hat.com> wrote:

> On Mon, 2021-04-26 at 12:40 +0200, Paolo Bonzini wrote:
> > On 26/04/21 11:33, Lai Jiangshan wrote:  
> > > When handle_interrupt_nmi_irqoff() is called, we may lose the
> > > CPU-hidden-NMI-masked state due to IRET of #DB, #BP or other traps
> > > between VMEXIT and handle_interrupt_nmi_irqoff().
> > > 
> > > But the NMI handler in the Linux kernel*expects*  the CPU-hidden-NMI-masked
> > > state is still set in the CPU for no nested NMI intruding into the beginning
> > > of the handler.

This is incorrect. The Linux kernel has for some time handled the case of
nested NMIs. It had to, to implement the ftrace break point updates, as it
would trigger an int3 in an NMI which would "unmask" the NMIs. It has also
been a long time bug where a page fault could do the same (the reason you
could never do a dump all tasks from NMI without triple faulting!).

But that's been fixed a long time ago, and I even wrote an LWN article
about it ;-)

 https://lwn.net/Articles/484932/

The NMI handler can handle the case of nested NMIs, and implements a
software "latch" to remember that another NMI is to be executed, if there
is a nested one. And it does so after the first one has finished.

-- Steve