* [PATCH] KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden
@ 2024-12-03 19:02 Marc Zyngier
2024-12-03 21:22 ` Catalin Marinas
2024-12-04 0:38 ` Oliver Upton
0 siblings, 2 replies; 3+ messages in thread
From: Marc Zyngier @ 2024-12-03 19:02 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Catalin Marinas, stable, Will Deacon, Mark Rutland, James Morse
Catalin reports that a hypervisor lying to a guest about the size
of the ASID field may result in unexpected issues:
- if the underlying HW does only supports 8 bit ASIDs, the ASID
field in a TLBI VAE1* operation is only 8 bits, and the HW will
ignore the other 8 bits
- if on the contrary the HW is 16 bit capable, the ASID field
in the same TLBI operation is always 16 bits, irrespective of
the value of TCR_ELx.AS.
This could lead to missed invalidations if the guest was lead to
assume that the HW had 8 bit ASIDs while they really are 16 bit wide.
In order to avoid any potential disaster that would be hard to debug,
prenent the migration between a host with 8 bit ASIDs to one with
wider ASIDs (the converse was obviously always forbidden). This is
also consistent with what we already do for VMIDs.
If it becomes absolutely mandatory to support such a migration path
in the future, we will have to trap and emulate all TLBIs, something
that nobody should look forward to.
Fixes: d5a32b60dc18 ("KVM: arm64: Allow userspace to change ID_AA64MMFR{0-2}_EL1")
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Oliver Upton <oliver.upton@linux.dev>
---
arch/arm64/kvm/sys_regs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index a26f02ec8748..b1918adbd0aa 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2674,7 +2674,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
ID_WRITABLE(ID_AA64MMFR0_EL1, ~(ID_AA64MMFR0_EL1_RES0 |
ID_AA64MMFR0_EL1_TGRAN4_2 |
ID_AA64MMFR0_EL1_TGRAN64_2 |
- ID_AA64MMFR0_EL1_TGRAN16_2)),
+ ID_AA64MMFR0_EL1_TGRAN16_2 |
+ ID_AA64MMFR0_EL1_ASIDBITS)),
ID_WRITABLE(ID_AA64MMFR1_EL1, ~(ID_AA64MMFR1_EL1_RES0 |
ID_AA64MMFR1_EL1_HCX |
ID_AA64MMFR1_EL1_TWED |
--
2.43.0
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden
2024-12-03 19:02 [PATCH] KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden Marc Zyngier
@ 2024-12-03 21:22 ` Catalin Marinas
2024-12-04 0:38 ` Oliver Upton
1 sibling, 0 replies; 3+ messages in thread
From: Catalin Marinas @ 2024-12-03 21:22 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, kvmarm, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, stable, Will Deacon, Mark Rutland,
James Morse
On Tue, Dec 03, 2024 at 07:02:36PM +0000, Marc Zyngier wrote:
> Catalin reports that a hypervisor lying to a guest about the size
> of the ASID field may result in unexpected issues:
>
> - if the underlying HW does only supports 8 bit ASIDs, the ASID
> field in a TLBI VAE1* operation is only 8 bits, and the HW will
> ignore the other 8 bits
>
> - if on the contrary the HW is 16 bit capable, the ASID field
> in the same TLBI operation is always 16 bits, irrespective of
> the value of TCR_ELx.AS.
>
> This could lead to missed invalidations if the guest was lead to
> assume that the HW had 8 bit ASIDs while they really are 16 bit wide.
>
> In order to avoid any potential disaster that would be hard to debug,
> prenent the migration between a host with 8 bit ASIDs to one with
> wider ASIDs (the converse was obviously always forbidden). This is
> also consistent with what we already do for VMIDs.
>
> If it becomes absolutely mandatory to support such a migration path
> in the future, we will have to trap and emulate all TLBIs, something
> that nobody should look forward to.
>
> Fixes: d5a32b60dc18 ("KVM: arm64: Allow userspace to change ID_AA64MMFR{0-2}_EL1")
> Reported-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Cc: stable@vger.kernel.org
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: James Morse <james.morse@arm.com>
> Cc: Oliver Upton <oliver.upton@linux.dev>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden
2024-12-03 19:02 [PATCH] KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden Marc Zyngier
2024-12-03 21:22 ` Catalin Marinas
@ 2024-12-04 0:38 ` Oliver Upton
1 sibling, 0 replies; 3+ messages in thread
From: Oliver Upton @ 2024-12-04 0:38 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, stable, Will Deacon, Mark Rutland, James Morse
On Tue, 03 Dec 2024 19:02:36 +0000, Marc Zyngier wrote:
> Catalin reports that a hypervisor lying to a guest about the size
> of the ASID field may result in unexpected issues:
>
> - if the underlying HW does only supports 8 bit ASIDs, the ASID
> field in a TLBI VAE1* operation is only 8 bits, and the HW will
> ignore the other 8 bits
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden
https://git.kernel.org/kvmarm/kvmarm/c/03c7527e97f7
--
Best,
Oliver
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-12-04 0:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-03 19:02 [PATCH] KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden Marc Zyngier
2024-12-03 21:22 ` Catalin Marinas
2024-12-04 0:38 ` Oliver Upton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox