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

Message-ID: <41dd2283-d5d8-4171-980d-6385f8b62f68@sirena.org.uk>
Date: Wed, 28 Aug 2024 16:10:35 +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 Thu, Aug 22, 2024 at 06:44:08PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:

> > 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.

> Sure, you can do that. Or rather, you can do that *right now*. But
> that's not what the architecture says (there is no statement saying
> that Op1==4 for an EL2 register). So the forward-looking way to do it
> is to match the full encoding of a register against the properties
> that define its existence.  Anything else is a short lived hack, and I
> don't care much for them.

Oh, well - I had thought that was a case of me not having found the rule
rather than the rule not existing given how consistent the scheme is
currently but yes, if a rule definiteively doesn't exist then I agree
that making one up in software is a bad idea.

> > 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).

> Well, they don't quite advertise the same thing. If you decode the
> feature specification, you get:

> (FEAT_SME <-> (AArch64 ID_AA64PFR1_EL1.SME >= 1))
> (FEAT_SME2 --> (AArch64 ID_AA64SMFR0_EL1.SMEver >= 1))
> (FEAT_SME2 --> (AArch64 ID_AA64PFR1_EL1.SME >= 2))
> (((AArch64 ID_AA64SMFR0_EL1.SMEver >= 1) || (AArch64 ID_AA64PFR1_EL1.SME >= 2)) --> FEAT_SME2)
> (FEAT_SME2p1 <-> (AArch64 ID_AA64SMFR0_EL1.SMEver >= 2))

> So SME isn't really advertised in SMEver, SME2 is advertised in both
> (and it is enough that one advertises SME2 for the feature to be
> present), and SME2p1 is only advertised in SMEver.

> That's what we need to implement. Yes, this part of the architecture
> is... interesting.

Yes, it's not a 1:1 mapping but you can for example identify the
presence of ZT0 via either SME or SMEVer since either implies FEAT_SME2
which like you say makes things a bit interesting.

> > 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.

> We definitely rely on userspace to enforce consistency. If userspace
> messes up, it's "garbage in, garbage out".

It's definitely the simpler approach.

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