linux-kernel - Re: [PATCH v2] x86/kvm: Disable KVM_ASYNC_PF_SEND

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]

Message-ID: <20200408153824.GO20730@hirez.programming.kicks-ass.net>
Date:   Wed, 8 Apr 2020 17:38:24 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Andy Lutomirski <luto@...capital.net>,
        Vivek Goyal <vgoyal@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        kvm list <kvm@...r.kernel.org>, stable <stable@...r.kernel.org>
Subject: Re: [PATCH v2] x86/kvm: Disable KVM_ASYNC_PF_SEND_ALWAYS

On Wed, Apr 08, 2020 at 03:01:58PM +0200, Thomas Gleixner wrote:
> And it comes with restrictions:
> 
>     The Do Other Stuff event can only be delivered when guest IF=1.
> 
>     If guest IF=0 then the host has to suspend the guest until the
>     situation is resolved.
> 
>     The 'Situation resolved' event must also wait for a guest IF=1 slot.

Moo, can we pretty please already kill that ALWAYS and IF nonsense? That
results in that terrifyingly crap HLT loop. That needs to die with
extreme prejudice.

So the host only inject these OMFG_DOS things when the guest is in
luserspace -- which it can see in the VMCS state IIRC. And then using
#VE for the make-it-go signal is far preferred over the currentl #PF
abuse.

> > Page-not-present async page faults are almost a perfect match for the
> > hardware use of #VE (and it might even be possible to let the
> > processor deliver the exceptions).  There are other advantages:
> >
> > - the only real problem with using #PF (with or without
> > KVM_ASYNC_PF_SEND_ALWAYS) seems to be the NMI reentrancy issue, which
> > would not be there for #VE.
> >
> > - #VE are combined the right way with other exceptions (the
> > benign/contributory/pagefault stuff)
> >
> > - adjusting KVM and Linux to use #VE instead of #PF would be less than
> > 100 lines of code.
> 
> If you just want to solve Viveks problem, then its good enough. I.e. the
> file truncation turns the EPT entries into #VE convertible entries and
> the guest #VE handler can figure it out. This one can be injected
> directly by the hardware, i.e. you don't need a VMEXIT.

That sounds like something that doesn't actually need the whole
'async'/do-something-else-for-a-while crap, right? It's a #PF trap from
kernel space where we need to report fail.

> If you want the opportunistic do other stuff mechanism, then #VE has
> exactly the same problems as the existing async "PF". It's not magicaly
> making that go away.

We need to somehow have the guest teach the host how to tell if it can
inject that OMFG_DOS thing or not. Injecting it only to then instantly
exit again is stupid and expensive.

Clearly we don't want to expose preempt_count and make that ABI, but is
there some way we can push a snippet of code to the host that instructs
the host how to determine if it can sleep or not? I realize that pushing
actual x86 .text is a giant security problem, so perhaps a snipped of
BPF that the host can verify, which it can run on the guest image ?

Make it a hard error (guest cpu dies) to inject the OMFG_DOS signal on a
context that cannot put the task to sleep.