linux-kernel - Re: [PATCH v2 0/4] KVM: x86: APICv cleanups

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, 25 Oct 2021 15:59:40 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Maxim Levitsky <mlevitsk@...hat.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,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] KVM: x86: APICv cleanups

On Mon, Oct 25, 2021, Paolo Bonzini wrote:
> On 25/10/21 16:35, Sean Christopherson wrote:
> > > So yeah, I think you're right.
> > Yep.  The alternative would be to explicitly check for a pending APICv update.
> > I don't have a strong opinion, I dislike both options equally:-)
> 
> No, checking for the update is worse and with this example, I can now point
> my finger on why I preferred the VM check even before: because even though
> the page fault path runs in vCPU context and uses a vCPU-specific role,
> overall the page tables are still per-VM.

Arguably the lack of incorporation into the page role is the underlying bug, and
all the shenanigans with synchronizing updates are just workarounds for that bug.
I.e. page tables are never strictly per-VM, they're per-role, but we fudge it in
this case because we don't want to take on the overhead of maintaining two sets
of page tables to handle APICv.