On systems with SME access to the SMPRI_EL1 priority management register is controlled by the nSMPRI_EL1 fine grained trap. We manage this trap in nVHE mode but do not do so when in VHE mode, add the required management.
On systems which do not implement priority mapping not enabling this trap will allow the guest to discover if the host support SME since the register will be RES0 rather than UNDEF. On systems implementing priority mapping the register could be used as a side channel by guests.
Fixes: 861262ab8627 ("KVM: arm64: Handle SME host state when running guests") Signed-off-by: Mark Brown broonie@kernel.org Cc: stable@vger.kernel.org --- arch/arm64/kvm/hyp/vhe/switch.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c index 7acb87eaa092..cae581e8dd56 100644 --- a/arch/arm64/kvm/hyp/vhe/switch.c +++ b/arch/arm64/kvm/hyp/vhe/switch.c @@ -63,10 +63,20 @@ static void __activate_traps(struct kvm_vcpu *vcpu) __activate_traps_fpsimd32(vcpu); }
- if (cpus_have_final_cap(ARM64_SME)) + if (cpus_have_final_cap(ARM64_SME)) { write_sysreg(read_sysreg(sctlr_el2) & ~SCTLR_ELx_ENTP2, sctlr_el2);
+ /* + * Disable access to SMPRI_EL1 - we don't need to control + * nTPIDR2_EL0 in VHE mode. + */ + sysreg_clear_set_s(SYS_HFGRTR_EL2, HFGxTR_EL2_nSMPRI_EL1_MASK, + 0); + sysreg_clear_set_s(SYS_HFGWTR_EL2, HFGxTR_EL2_nSMPRI_EL1_MASK, + 0); + } + write_sysreg(val, cpacr_el1);
write_sysreg(__this_cpu_read(kvm_hyp_vector), vbar_el1); @@ -88,9 +98,19 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu) */ asm(ALTERNATIVE("nop", "isb", ARM64_WORKAROUND_SPECULATIVE_AT));
- if (cpus_have_final_cap(ARM64_SME)) + if (cpus_have_final_cap(ARM64_SME)) { + /* + * Enable access to SMPRI_EL1 - we don't need to + * control nTPIDR2_EL0 in VHE mode. + */ + sysreg_clear_set_s(SYS_HFGRTR_EL2, 0, + HFGxTR_EL2_nSMPRI_EL1_MASK); + sysreg_clear_set_s(SYS_HFGWTR_EL2, 0, + HFGxTR_EL2_nSMPRI_EL1_MASK); + write_sysreg(read_sysreg(sctlr_el2) | SCTLR_ELx_ENTP2, sctlr_el2); + }
write_sysreg(CPACR_EL1_DEFAULT, cpacr_el1);
On Thu, 27 Oct 2022 22:04:40 +0100, Mark Brown broonie@kernel.org wrote:
On systems with SME access to the SMPRI_EL1 priority management register is controlled by the nSMPRI_EL1 fine grained trap. We manage this trap in nVHE mode but do not do so when in VHE mode, add the required management.
On systems which do not implement priority mapping not enabling this trap will allow the guest to discover if the host support SME since the register will be RES0 rather than UNDEF. On systems implementing priority mapping the register could be used as a side channel by guests.
Fixes: 861262ab8627 ("KVM: arm64: Handle SME host state when running guests") Signed-off-by: Mark Brown broonie@kernel.org Cc: stable@vger.kernel.org
arch/arm64/kvm/hyp/vhe/switch.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c index 7acb87eaa092..cae581e8dd56 100644 --- a/arch/arm64/kvm/hyp/vhe/switch.c +++ b/arch/arm64/kvm/hyp/vhe/switch.c @@ -63,10 +63,20 @@ static void __activate_traps(struct kvm_vcpu *vcpu) __activate_traps_fpsimd32(vcpu); }
- if (cpus_have_final_cap(ARM64_SME))
- if (cpus_have_final_cap(ARM64_SME)) { write_sysreg(read_sysreg(sctlr_el2) & ~SCTLR_ELx_ENTP2, sctlr_el2);
/** Disable access to SMPRI_EL1 - we don't need to control* nTPIDR2_EL0 in VHE mode.
It really isn't obvious to me why this is the case. The pseudocode says for a 'MSR TPIDR2_EL0, <Xt>' (DDI0616 A.a p225):
<quote> elsif PSTATE.EL == EL1 then if Halted() && HaveEL(EL3) && EDSCR.SDD == '1' && boolean IMPLEMENTATION_DEFINED "EL3 trap priority, when SDD == '1'" && SCR_EL3.EnTP2 == '0' then UNDEFINED; elsif EL2Enabled() && (!HaveEL(EL3) || SCR_EL3.FGTEn == '1') && HFGWTR_EL2.nTPIDR2_EL0 == '0' then AArch64.SystemAccessTrap(EL2, 0x18); elsif HaveEL(EL3) && SCR_EL3.EnTP2 == '0' then if Halted() && EDSCR.SDD == '1' then UNDEFINED; else AArch64.SystemAccessTrap(EL3, 0x18); else TPIDR2_EL0 = X[t, 64]; </quote>
So when running at EL1, and short of clearing nTPIDR2_EL0, EL1 will have access to TPIDR2_EL0. What prevents that?
The write to SCTLR_EL2.EnTP2 is also pretty dubious, and doesn't really cover the access to EL0 (think SCTLR_EL1.EnTP2=1 and HCR_EL2.{E2H,TGE}={1,0}, for example).
M.
On Mon, Oct 31, 2022 at 09:45:48AM +0000, Marc Zyngier wrote:
Mark Brown broonie@kernel.org wrote:
/** Disable access to SMPRI_EL1 - we don't need to control* nTPIDR2_EL0 in VHE mode.
It really isn't obvious to me why this is the case. The pseudocode says for a 'MSR TPIDR2_EL0, <Xt>' (DDI0616 A.a p225):
Yes, I was just discovering that while checking and replying to your earlier mail about the other series. I'll respin.
linux-stable-mirror@lists.linaro.org
-
Marc Zyngier -
Mark Brown