| Message ID | 20220816192554.1455559-1-oliver.upton@linux.dev (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM: arm64: Uphold 64bit-only behavior on asymmetric systems | expand |
On Tue, 16 Aug 2022 19:25:52 +0000, Oliver Upton wrote: > Small series to fix a couple issues around when 64bit-only behavior is > applied. As KVM is more restrictive than the kernel in terms of 32bit > support (no asymmetry), we really needed our own predicate when the > meaning of system_supports_32bit_el0() changed in commit 2122a833316f > ("arm64: Allow mismatched 32-bit EL0 support"). > > Lightly tested as I do not have any asymmetric systems on hand at the > moment. Attention on patch 2 would be appreciated as it affects ABI. > > [...] Applied to fixes, thanks! [1/2] KVM: arm64: Treat PMCR_EL1.LC as RES1 on asymmetric systems commit: f3c6efc72f3b20ec23566e768979802f0a398f04 [2/2] KVM: arm64: Reject 32bit user PSTATE on asymmetric systems commit: b10d86fb8e46cc812171728bcd326df2f34e9ed5 Cheers, M.
On Tue, 16 Aug 2022 20:25:52 +0100, Oliver Upton <oliver.upton@linux.dev> wrote: > > Small series to fix a couple issues around when 64bit-only behavior is > applied. As KVM is more restrictive than the kernel in terms of 32bit > support (no asymmetry), we really needed our own predicate when the > meaning of system_supports_32bit_el0() changed in commit 2122a833316f > ("arm64: Allow mismatched 32-bit EL0 support"). > > Lightly tested as I do not have any asymmetric systems on hand at the > moment. Attention on patch 2 would be appreciated as it affects ABI. I don't think this significantly affect the ABI, as it is pretty unlikely that you'd have been able to execute the result, at least on VM creation (set PSTATE.M=USR, start executing, get the page fault on the first instruction... bang). You could have tricked it in other ways, but at the end of the day you're running a broken hypervisor on an even more broken system... Anyway, I've applied this to fixes. Thanks, M.
Hi, On Wed, Aug 17, 2022 at 11:07:10AM +0100, Marc Zyngier wrote: > On Tue, 16 Aug 2022 20:25:52 +0100, > Oliver Upton <oliver.upton@linux.dev> wrote: > > > > Small series to fix a couple issues around when 64bit-only behavior is > > applied. As KVM is more restrictive than the kernel in terms of 32bit > > support (no asymmetry), we really needed our own predicate when the > > meaning of system_supports_32bit_el0() changed in commit 2122a833316f > > ("arm64: Allow mismatched 32-bit EL0 support"). > > > > Lightly tested as I do not have any asymmetric systems on hand at the > > moment. Attention on patch 2 would be appreciated as it affects ABI. > > I don't think this significantly affect the ABI, as it is pretty > unlikely that you'd have been able to execute the result, at least on > VM creation (set PSTATE.M=USR, start executing, get the page fault on > the first instruction... bang). > > You could have tricked it in other ways, but at the end of the day > you're running a broken hypervisor on an even more broken system... Just FYI, you can create such a system on models, by running two clusters and setting clusterX.max_32bit_el=-1. Or you can have even crazier configurations, where AArch32 support is present on only one cluster, and only for EL0. Thanks, Alex > > Anyway, I've applied this to fixes. > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible.
On Wed, 17 Aug 2022 11:52:06 +0100, Alexandru Elisei <alexandru.elisei@arm.com> wrote: > > Hi, > > On Wed, Aug 17, 2022 at 11:07:10AM +0100, Marc Zyngier wrote: > > On Tue, 16 Aug 2022 20:25:52 +0100, > > Oliver Upton <oliver.upton@linux.dev> wrote: > > > > > > Small series to fix a couple issues around when 64bit-only behavior is > > > applied. As KVM is more restrictive than the kernel in terms of 32bit > > > support (no asymmetry), we really needed our own predicate when the > > > meaning of system_supports_32bit_el0() changed in commit 2122a833316f > > > ("arm64: Allow mismatched 32-bit EL0 support"). > > > > > > Lightly tested as I do not have any asymmetric systems on hand at the > > > moment. Attention on patch 2 would be appreciated as it affects ABI. > > > > I don't think this significantly affect the ABI, as it is pretty > > unlikely that you'd have been able to execute the result, at least on > > VM creation (set PSTATE.M=USR, start executing, get the page fault on > > the first instruction... bang). > > > > You could have tricked it in other ways, but at the end of the day > > you're running a broken hypervisor on an even more broken system... > > Just FYI, you can create such a system on models, by running two clusters > and setting clusterX.max_32bit_el=-1. Or you can have even crazier > configurations, where AArch32 support is present on only one cluster, and > only for EL0. You mean, just as crazy as some of the systems out there? :D Thanks, M.
On Wed, Aug 17, 2022 at 11:56:50AM +0100, Marc Zyngier wrote: > On Wed, 17 Aug 2022 11:52:06 +0100, > Alexandru Elisei <alexandru.elisei@arm.com> wrote: > > > > Hi, > > > > On Wed, Aug 17, 2022 at 11:07:10AM +0100, Marc Zyngier wrote: > > > On Tue, 16 Aug 2022 20:25:52 +0100, > > > Oliver Upton <oliver.upton@linux.dev> wrote: > > > > > > > > Small series to fix a couple issues around when 64bit-only behavior is > > > > applied. As KVM is more restrictive than the kernel in terms of 32bit > > > > support (no asymmetry), we really needed our own predicate when the > > > > meaning of system_supports_32bit_el0() changed in commit 2122a833316f > > > > ("arm64: Allow mismatched 32-bit EL0 support"). > > > > > > > > Lightly tested as I do not have any asymmetric systems on hand at the > > > > moment. Attention on patch 2 would be appreciated as it affects ABI. > > > > > > I don't think this significantly affect the ABI, as it is pretty > > > unlikely that you'd have been able to execute the result, at least on > > > VM creation (set PSTATE.M=USR, start executing, get the page fault on > > > the first instruction... bang). > > > > > > You could have tricked it in other ways, but at the end of the day > > > you're running a broken hypervisor on an even more broken system... Lol, fair enough. Just wanted to make sure we're all happy with how we turn the guest into rubble on the other end :) > > Just FYI, you can create such a system on models, by running two clusters > > and setting clusterX.max_32bit_el=-1. Or you can have even crazier > > configurations, where AArch32 support is present on only one cluster, and > > only for EL0. Doh! Forgot about the fast model. -- Thanks, Oliver
Small series to fix a couple issues around when 64bit-only behavior is applied. As KVM is more restrictive than the kernel in terms of 32bit support (no asymmetry), we really needed our own predicate when the meaning of system_supports_32bit_el0() changed in commit 2122a833316f ("arm64: Allow mismatched 32-bit EL0 support"). Lightly tested as I do not have any asymmetric systems on hand at the moment. Attention on patch 2 would be appreciated as it affects ABI. Applies to 6.0-rc1. v1 -> v2: - Fix a silly logic inversion in vcpu_mode_is_bad_32bit() - Rebase to 6.0-rc1 Oliver Upton (2): KVM: arm64: Treat PMCR_EL1.LC as RES1 on asymmetric systems KVM: arm64: Reject 32bit user PSTATE on asymmetric systems arch/arm64/include/asm/kvm_host.h | 4 ++++ arch/arm64/kvm/arm.c | 3 +-- arch/arm64/kvm/guest.c | 2 +- arch/arm64/kvm/sys_regs.c | 4 ++-- 4 files changed, 8 insertions(+), 5 deletions(-) base-commit: 568035b01cfb107af8d2e4bd2fb9aea22cf5b868