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: <874ktukhku.fsf@nanos.tec.linutronix.de>
Date:   Wed, 08 Apr 2020 01:21:37 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Andy Lutomirski <luto@...capital.net>,
        Vivek Goyal <vgoyal@...hat.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        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

Paolo Bonzini <pbonzini@...hat.com> writes:

> On 07/04/20 22:20, Thomas Gleixner wrote:
>>>> Havind said that, I thought disabling interrupts does not mask exceptions.
>>>> So page fault exception should have been delivered even with interrupts
>>>> disabled. Is that correct? May be there was no vm exit/entry during
>>>> those 10 seconds and that's why.
>> No. Async PF is not a real exception. It has interrupt semantics and it
>> can only be injected when the guest has interrupts enabled. It's bad
>> design.
>
> Page-ready async PF has interrupt semantics.
>
> Page-not-present async PF however does not have interrupt semantics, it
> has to be injected immediately or not at all (falling back to host page
> fault in the latter case).

If interrupts are disabled in the guest then it is NOT injected and the
guest is suspended. So it HAS interrupt semantics. Conditional ones,
i.e. if interrupts are disabled, bail, if not then inject it.

But that does not make it an exception by any means.

It never should have been hooked to #PF in the first place and it never
should have been named that way. The functionality is to opportunisticly
tell the guest to do some other stuff.

So the proper name for this seperate interrupt vector would be:

   VECTOR_OMG_DOS - Opportunisticly Make Guest Do Other Stuff

and the counter part

   VECTOR_STOP_DOS - Stop Doing Other Stuff 

> So page-not-present async PF definitely needs to be an exception, this
> is independent of whether it can be injected when IF=0.

That wants to be a straight #PF. See my reply to Andy.

> Hypervisors do not have any reserved exception vector, and must use
> vectors up to 31, which is why I believe #PF was used in the first place
> (though that predates my involvement in KVM by a few years).

No. That was just bad taste or something worse. It has nothing to do
with exceptions, see above. Stop proliferating the confusion.

> These days, #VE would be a much better exception to use instead (and
> it also has a defined mechanism to avoid reentrancy).

#VE is not going to solve anything.

The idea of OMG_DOS is to (opportunisticly) avoid that the guest (and
perhaps host) sit idle waiting for I/O until the fault has been
resolved. That makes sense as there might be enough other stuff to do
which does not depend on that particular page. If not then fine, the
guest will go idle.

Thanks,

        tglx