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]

Date:   Wed, 08 Apr 2020 18:41:44 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Peter Zijlstra <peterz@...radead.org>
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

Peter Zijlstra <peterz@...radead.org> writes:
> 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.

Yes, but this requires software based injection.

>> 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.

Fail or fixup via extable.

>> 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.

Not if the injection is actually done by the hardware. Then the guest
handles #VE and tells the host what to do.

> 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 ?

*SHUDDER*

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

With the hardware based #VE and a hypercall which tells the host how to
handle the EPT fixup (suspend the vcpu or let it continue and do the
completion later) you don't have to play any games on the host. If the
guest tells the host the wrong thing, then the guest will have to mop up
the pieces.

Thanks,

        tglx