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: <861q2gxxjr.wl-maz@kernel.org>
Date: Thu, 22 Aug 2024 18:44:08 +0100
From: Marc Zyngier <maz@...nel.org>
To: Mark Brown <broonie@...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, 22 Aug 2024 16:30:42 +0100,
Mark Brown <broonie@...nel.org> wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> 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.

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.

But a simple way to deal with that is to encode a property that checks
a vcpu creation property (EL2, PAuth...).

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

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

We enforce the sysregs visible by the guest and userspace based on
that, and if that means evaluating 10 registers because there is a
terrible set of combinations (such as PAuth-like features), so be it.
We can always find ways to accelerate that.

	M.

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