linux-kernel - Re: [PATCH] KVM: x86/mmu: Calculate and check "full" mmu

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] [day] [month] [year] [list]

Message-ID: <YMO+qj36W2isnlxC@google.com>
Date:   Fri, 11 Jun 2021 19:51:06 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     Paolo Bonzini <pbonzini@...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] KVM: x86/mmu: Calculate and check "full" mmu_role for
 nested MMU

On Fri, Jun 11, 2021, Sean Christopherson wrote:
> On Fri, Jun 11, 2021, Vitaly Kuznetsov wrote:
> > What I don't quite like (besides the fact that this 'nested_mmu' exists
> > but I don't see an elegant way to get rid of it) is the fact that we now
> > have the same logic to compute 'level' both in
> > kvm_calc_nested_mmu_role() and init_kvm_nested_mmu(). We could've
> > avoided that by re-aranging code in init_kvm_nested_mmu() I
> > guess. Something like (untested):
> 
> Yep, cleaning all that up is on my todo list, but there are some hurdles to
> clear first.
> 
> My thought is to either (a) initialize the context from the role, or (b) drop the
> duplicate context information altogether.  For (a), the NX bit is calculated
> incorrectly in the role stuff, e.g. if paging is disabled then NX is effectively 0,
> and I need that fix for the vCPU RESET/INIT series.  It's benign for the role,
> but not for the context.  And (b) will require auditing for all flavors of MMUs;
> I wouldn't be the least bit surprised to discover there's a corner case (or just
> a regular case) that I'm overlooking.

Ugh, nested NPT is completely fubar.  Except for the "core" mode, all of the role
and context calculations are done using L2 state instead of L1 host state.  The
APM explicitly states that CR0.WP is ignored, and SMEP/SMAP are implicitly ignored
by virtue of the NPT walks always being tagged "user", but KVM botches the NX
behavior and would mess up LA57 if it were supported.

I sort out the mess, though I'm not sure how it will interact with the reset series...