linux-kernel - Re: [PATCH 0/2] KVM: arm64: Control visibility of S1PIE related sysregs to userspace

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: <ZsdZohZhre-fRmUv@finisterre.sirena.org.uk>
Date: Thu, 22 Aug 2024 16:30:42 +0100
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Oliver Upton <oliver.upton@...ux.dev>,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Joey Gouly <joey.gouly@....com>,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] KVM: arm64: Control visibility of S1PIE related
 sysregs to userspace

On Wed, Aug 21, 2024 at 05:40:06PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:

> > Indeed, I was wondering about just adding a description of the relevant
> > ID register field to the sys_regs table.

> You'd need more than that.

> How would you express the visibility of TCR2_EL2? It depends on both
> ID_AA64PFR0_EL1.EL2==1 *and* ID_AA64MMFR3_EL1.TCRX==1. So it cannot be
> just a single tuple { idreg, field, value }. It needs to be an
> arbitrary conjunction of those.

I haven't done an audit for fun cases to see how viable things are, for
the EL2 cases I'd just have an encoding based check for EL2 rather than
explicitly enumerating the ID register for each EL2.  That seemed
quicker and less error prone.  

The other cases I'm aware of are more along the lines of features
restricting the values other features/idregs can have (eg, for SME the
information in ID_AA64PFR1_EL1.SME can also be gleaned from
ID_AA64SMFR0_EL1.SMEver).  For those I'm not sure if visibility checks
are the best approach, if we should audit the registers when starting
the guest to make sure they're self consistent or if we should just pick
the most directly relevant register and rely on userspace to enforce
consistancy.  If there's others more like the EL2 case that wouldn't be
viable though and an approach like you suggest would be better, like I
say I've not actually looked yet.

> The good news is that it is a much smaller table than the monster trap
> routing table: it is "enum vcpu_sysreg" plus things that are
> synthesised (anything with a .get_user callback).

Yes.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)