linux-kernel - Re: [PATCH v3 10/16] KVM: selftests: Reuse virt mapping functions for nested EPTs

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: <aVMX9a2gVxToXjlL@google.com>
Date: Mon, 29 Dec 2025 16:08:21 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 10/16] KVM: selftests: Reuse virt mapping functions for
 nested EPTs

On Tue, Dec 23, 2025, Yosry Ahmed wrote:
> On Tue, Dec 23, 2025 at 03:12:09PM -0800, Sean Christopherson wrote:
> > On Thu, Nov 27, 2025, Yosry Ahmed wrote:
> > > diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h
> > > index fb2b2e53d453..62e10b296719 100644
> > > --- a/tools/testing/selftests/kvm/include/x86/processor.h
> > > +++ b/tools/testing/selftests/kvm/include/x86/processor.h
> > > @@ -1447,6 +1447,7 @@ struct pte_masks {
> > >  	uint64_t dirty;
> > >  	uint64_t huge;
> > >  	uint64_t nx;
> > > +	uint64_t x;
> > 
> > To be consistent with e.g. writable, call this executable.
> 
> Was trying to be consistent with 'nx' :) 
> 
> > 
> > >  	uint64_t c;
> > >  	uint64_t s;
> > >  };
> > > @@ -1464,6 +1465,7 @@ struct kvm_mmu {
> > >  #define PTE_DIRTY_MASK(mmu) ((mmu)->pte_masks.dirty)
> > >  #define PTE_HUGE_MASK(mmu) ((mmu)->pte_masks.huge)
> > >  #define PTE_NX_MASK(mmu) ((mmu)->pte_masks.nx)
> > > +#define PTE_X_MASK(mmu) ((mmu)->pte_masks.x)
> > >  #define PTE_C_MASK(mmu) ((mmu)->pte_masks.c)
> > >  #define PTE_S_MASK(mmu) ((mmu)->pte_masks.s)
> > >  
> > > @@ -1474,6 +1476,7 @@ struct kvm_mmu {
> > >  #define pte_dirty(mmu, pte) (!!(*(pte) & PTE_DIRTY_MASK(mmu)))
> > >  #define pte_huge(mmu, pte) (!!(*(pte) & PTE_HUGE_MASK(mmu)))
> > >  #define pte_nx(mmu, pte) (!!(*(pte) & PTE_NX_MASK(mmu)))
> > > +#define pte_x(mmu, pte) (!!(*(pte) & PTE_X_MASK(mmu)))
> > 
> > And then here to not assume PRESENT == READABLE, just check if the MMU even has
> > a PRESENT bit.  We may still need changes, e.g. the page table builders actually
> > need to verify a PTE is _writable_, not just present, but that's largely an
> > orthogonal issue.
> 
> Not sure what you mean? How is the PTE being writable relevant to
> assuming PRESENT == READABLE?

Only tangentially, I was try to say that if we ever get to a point where selftests
support read-only mappings, then the below check won't suffice because walking
page tables would get false positives on whether or not an entry is usable, e.g.
if a test wants to create a writable mapping and ends up re-using a read-only
mapping.

The PRESENT == READABLE thing is much more about execute-only mappings (which
selftests also don't support, but as you allude to below, don't require new
hardware functionality).

> > #define is_present_pte(mmu, pte)		\
> > 	(PTE_PRESENT_MASK(mmu) ?		\
> > 	 !!(*(pte) & PTE_PRESENT_MASK(mmu)) :	\
> > 	 !!(*(pte) & (PTE_READABLE_MASK(mmu) | PTE_EXECUTABLE_MASK(mmu))))
> 
> and then Intel will introduce VMX_EPT_WRITE_ONLY_BIT :P