linux-kernel - Re: [PATCH v10 1/9] KVM: x86/mmu: Use GENMASK_ULL() to define __PT_BASE_ADDR

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: <ZPDpYGzt0GdDQxEQ@google.com>
Date:   Thu, 31 Aug 2023 12:26:24 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Binbin Wu <binbin.wu@...ux.intel.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        pbonzini@...hat.com, chao.gao@...el.com, kai.huang@...el.com,
        David.Laight@...lab.com, robert.hu@...ux.intel.com,
        guang.zeng@...el.com
Subject: Re: [PATCH v10 1/9] KVM: x86/mmu: Use GENMASK_ULL() to define __PT_BASE_ADDR_MASK

On Mon, Aug 28, 2023, Binbin Wu wrote:
> 
> 
> On 8/17/2023 5:00 AM, Sean Christopherson wrote:
> > On Wed, Jul 19, 2023, Binbin Wu wrote:
> > > Use GENMASK_ULL() to define __PT_BASE_ADDR_MASK.
> > Using GENMASK_ULL() is an opportunistic cleanup, it is not the main purpose for
> > this patch.  The main purpose is to extract the maximum theoretical mask for guest
> > MAXPHYADDR so that it can be used to strip bits from CR3.
> > 
> > And rather than bury the actual use in "KVM: x86: Virtualize CR3.LAM_{U48,U57}",
> > I think it makes sense to do the masking in this patch.  That change only becomes
> > _necessary_ when LAM comes along, but it's completely valid without LAM.
> > 
> > That will also provide a place to explain why we decided to unconditionally mask
> > the pgd (it's harmless for 32-bit guests, querying 64-bit mode would be more
> > expensive, and for EPT the mask isn't tied to guest mode).
> OK.
> 
> > And it should also
> > explain that using PT_BASE_ADDR_MASK would actually be wrong (PAE has 64-bit
> > elements _except_ for CR3).
> Hi Sean, I am not sure if I understand it correctly.  Do you mean when KVM
> shadows the page table of guest using 32-bit paging or PAE paging, guest CR3
> is or can be 32 bits for 32-bit paging or PAE paging, so that apply the mask
> to a 32-bit value CR3 "would actually be wrong" ?

It would be technically wrong for PAE paging, as the PTEs themselves are 64 bits,
i.e. PT_BASE_ADDR_MASK would be 51:12, but CR3 is still only 32 bits.  Wouldn't
matter in practice, but I think it's worth calling out that going out of our way
to use PT_BASE_ADDR_MASK wouldn't actually "fix" anything.