linux-kernel - Re: [PATCH v8 5/6] KVM: arm64: Initialize the ptdump parser with stage-2 attributes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8634mwy1mt.wl-maz@kernel.org>
Date: Thu, 22 Aug 2024 17:15:54 +0100
From: Marc Zyngier <maz@...nel.org>
To: Sebastian Ene <sebastianene@...gle.com>
Cc: akpm@...ux-foundation.org,
	alexghiti@...osinc.com,
	ankita@...dia.com,
	ardb@...nel.org,
	catalin.marinas@....com,
	christophe.leroy@...roup.eu,
	james.morse@....com,
	vdonnefort@...gle.com,
	mark.rutland@....com,
	oliver.upton@...ux.dev,
	rananta@...gle.com,
	ryan.roberts@....com,
	shahuang@...hat.com,
	suzuki.poulose@....com,
	will@...nel.org,
	yuzenghui@...wei.com,
	kvmarm@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	kernel-team@...roid.com
Subject: Re: [PATCH v8 5/6] KVM: arm64: Initialize the ptdump parser with stage-2 attributes

On Tue, 20 Aug 2024 15:20:25 +0100,
Marc Zyngier <maz@...nel.org> wrote:
> 
> On Fri, 16 Aug 2024 13:39:05 +0100,
> Sebastian Ene <sebastianene@...gle.com> wrote:
> > 
> > Define a set of attributes used by the ptdump parser to display the
> > properties of a guest memory region covered by a pagetable descriptor.
> > Build a description of the pagetable levels and initialize the parser
> > with this configuration.
> > 
> > Signed-off-by: Sebastian Ene <sebastianene@...gle.com>
> > ---
> >  arch/arm64/kvm/ptdump.c | 135 ++++++++++++++++++++++++++++++++++++++--
> >  1 file changed, 129 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
> > index 52483d56be2e..79be07ec3c3c 100644
> > --- a/arch/arm64/kvm/ptdump.c
> > +++ b/arch/arm64/kvm/ptdump.c
> > @@ -14,6 +14,51 @@
> >  #include <kvm_ptdump.h>
> >  
> >  
> > +#define MARKERS_LEN		(2)
> > +#define KVM_PGTABLE_MAX_LEVELS	(KVM_PGTABLE_LAST_LEVEL + 1)
> > +
> > +struct kvm_ptdump_guest_state {
> > +	struct kvm		*kvm;
> > +	struct ptdump_pg_state	parser_state;
> > +	struct addr_marker	ipa_marker[MARKERS_LEN];
> > +	struct ptdump_pg_level	level[KVM_PGTABLE_MAX_LEVELS];
> > +	struct ptdump_range	range[MARKERS_LEN];
> > +};
> > +
> > +static const struct ptdump_prot_bits stage2_pte_bits[] = {
> > +	{
> > +		.mask	= PTE_VALID,
> > +		.val	= PTE_VALID,
> > +		.set	= " ",
> > +		.clear	= "F",
> > +	}, {
> > +		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R | PTE_VALID,
> > +		.val	= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R | PTE_VALID,
> > +		.set	= "R",
> > +		.clear	= " ",
> > +	}, {
> > +		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | PTE_VALID,
> > +		.val	= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | PTE_VALID,
> > +		.set	= "W",
> > +		.clear	= " ",
> > +	}, {
> > +		.mask	= KVM_PTE_LEAF_ATTR_HI_S2_XN | PTE_VALID,
> > +		.val	= PTE_VALID,
> > +		.set	= " ",
> > +		.clear	= "X",
> > +	}, {
> > +		.mask	= KVM_PTE_LEAF_ATTR_LO_S2_AF | PTE_VALID,
> > +		.val	= KVM_PTE_LEAF_ATTR_LO_S2_AF | PTE_VALID,
> > +		.set	= "AF",
> > +		.clear	= "  ",
> > +	}, {
> > +		.mask	= PTE_TABLE_BIT | PTE_VALID,
> > +		.val	= PTE_VALID,
> > +		.set	= "BLK",
> > +		.clear	= "   ",
> > +	},
> > +};
> > +
> >  static int kvm_ptdump_visitor(const struct kvm_pgtable_visit_ctx *ctx,
> >  			      enum kvm_pgtable_walk_flags visit)
> >  {
> > @@ -40,15 +85,81 @@ static int kvm_ptdump_show_common(struct seq_file *m,
> >  	return kvm_pgtable_walk(pgtable, 0, BIT(pgtable->ia_bits), &walker);
> >  }
> >  
> > +static int kvm_ptdump_build_levels(struct ptdump_pg_level *level, u32 start_lvl)
> > +{
> > +	static const char * const level_names[] = {"PGD", "PUD", "PMD", "PTE"};
> 
> How about 5 level page tables, which we support since v6.8? The
> architecture uses a SL=-1 in this case, and I have the feeling this is
> going to expose in a lovely way, given that you use a u32 for
> start_level... :-/

Talking to Oliver, I just had an epiphany: we never have a 5th level
with KVM, because we always use concatenated page tables at the start
level. So the depth is still 4 levels, but we get up to 16 pages at
level 0, and that's how we expand the IPA space from 48 to 52 bits.

So by the look of it, your code should still be OK with only 4 levels.

Apologies for leading you in the wrong direction.

	M.

-- 
Without deviation from the norm, progress is not possible.