| Message ID | 20240821-kvm-arm64-hide-pie-regs-v1-0-08cb3c79cb57@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM: arm64: Control visibility of S1PIE related sysregs to userspace | expand |
On Wed, 21 Aug 2024 14:07:14 +0100, Mark Brown <broonie@kernel.org> wrote: > > While looking at the KVM system register code I noticed that we do not > have visibility operations for TCR2 or the S1PIE registers, I may be > missing some reason why they are not required but in case I'm not I > figured the most direct way to ask was to propose adding the operations. > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > Mark Brown (2): > KVM: arm64: Hide TCR2_EL1 from userspace when disabled for guests > KVM: arm64: Hide S1PIE registers from userspace when disabled for guests > > arch/arm64/include/asm/kvm_host.h | 6 ++++++ > arch/arm64/kvm/sys_regs.c | 31 ++++++++++++++++++++++++++----- > 2 files changed, 32 insertions(+), 5 deletions(-) If you are going to do this, please add it on top of [1], and handle the corresponding EL2 registers. Thanks, M. [1] https://lore.kernel.org/20240813144738.2048302-1-maz@kernel.org
On Wed, Aug 21, 2024 at 02:46:25PM +0100, Marc Zyngier wrote: > Mark Brown <broonie@kernel.org> wrote: > > Mark Brown (2): > > KVM: arm64: Hide TCR2_EL1 from userspace when disabled for guests > > KVM: arm64: Hide S1PIE registers from userspace when disabled for guests > If you are going to do this, please add it on top of [1], and handle > the corresponding EL2 registers. OK. To confirm, this is a desirable change?
On Wed, 21 Aug 2024 15:01:54 +0100, Mark Brown <broonie@kernel.org> wrote: > > [1 <text/plain; us-ascii (7bit)>] > On Wed, Aug 21, 2024 at 02:46:25PM +0100, Marc Zyngier wrote: > > Mark Brown <broonie@kernel.org> wrote: > > > > Mark Brown (2): > > > KVM: arm64: Hide TCR2_EL1 from userspace when disabled for guests > > > KVM: arm64: Hide S1PIE registers from userspace when disabled for guests > > > If you are going to do this, please add it on top of [1], and handle > > the corresponding EL2 registers. > > OK. To confirm, this is a desirable change? Yes. Ultimately, we need to revisit the way we deal with visibility, as adding a myriad of helpers checking a combination of features doesn't scale. That information should exist as a static table, just like the trap bits. But until then, that's probably the way. M.
On Wed, Aug 21, 2024 at 03:45:20PM +0100, Marc Zyngier wrote: > Ultimately, we need to revisit the way we deal with visibility, as > adding a myriad of helpers checking a combination of features doesn't > scale. That information should exist as a static table, just like the > trap bits. Indeed, I was wondering about just adding a description of the relevant ID register field to the sys_regs table. > But until then, that's probably the way. OK.
On Wed, 21 Aug 2024 16:19:59 +0100, Mark Brown <broonie@kernel.org> wrote: > > On Wed, Aug 21, 2024 at 03:45:20PM +0100, Marc Zyngier wrote: > > > Ultimately, we need to revisit the way we deal with visibility, as > > adding a myriad of helpers checking a combination of features doesn't > > scale. That information should exist as a static table, just like the > > trap bits. > > 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. 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). M.
On Wed, Aug 21, 2024 at 05:40:06PM +0100, Marc Zyngier wrote: > Mark Brown <broonie@kernel.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.
On Thu, 22 Aug 2024 16:30:42 +0100, Mark Brown <broonie@kernel.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@kernel.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.
On Thu, Aug 22, 2024 at 06:44:08PM +0100, Marc Zyngier wrote: > Mark Brown <broonie@kernel.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.
While looking at the KVM system register code I noticed that we do not have visibility operations for TCR2 or the S1PIE registers, I may be missing some reason why they are not required but in case I'm not I figured the most direct way to ask was to propose adding the operations. Signed-off-by: Mark Brown <broonie@kernel.org> --- Mark Brown (2): KVM: arm64: Hide TCR2_EL1 from userspace when disabled for guests KVM: arm64: Hide S1PIE registers from userspace when disabled for guests arch/arm64/include/asm/kvm_host.h | 6 ++++++ arch/arm64/kvm/sys_regs.c | 31 ++++++++++++++++++++++++++----- 2 files changed, 32 insertions(+), 5 deletions(-) --- base-commit: 6e4436539ae182dc86d57d13849862bcafaa4709 change-id: 20240820-kvm-arm64-hide-pie-regs-2236f70703ab Best regards,