Message ID | 20231124163510.1835740-1-joey.gouly@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | Permission Overlay Extension | expand |
Hi Joey, On Fri, 24 Nov 2023 16:34:45 +0000, Joey Gouly <joey.gouly@arm.com> wrote: > > Hello everyone, > > This series implements the Permission Overlay Extension introduced in 2022 > VMSA enhancements [1]. It is based on v6.7-rc2. > > Changes since v2[2]: > # Added ptrace support and selftest > # Add missing POR_EL0 initialisation in fork/clone > # Rebase onto v6.7-rc2 > # Add r-bs > > The Permission Overlay Extension allows to constrain permissions on memory > regions. This can be used from userspace (EL0) without a system call or TLB > invalidation. I have given this series a few more thoughts, and came to the conclusion that is it still incomplete on the KVM front: * FEAT_S1POE often comes together with FEAT_S2POE. For obvious reasons, we cannot afford to let the guest play with S2POR_EL1, nor do we want to advertise FEAT_S2POE to the guest. You will need to add some additional FGT for this, and mask out FEAT_S2POE from the guest's view of the ID registers. * letting the guest play with POE comes with some interesting strings attached: a guest that has started on a POE-enabled host cannot be migrated to one that doesn't have POE. which means that the POE registers should only be visible to the host userspace if enabled in the guest's ID registers, and thus only context-switched in these conditions. They should otherwise UNDEF. Thanks, M.
Hi Marc, On Mon, Dec 04, 2023 at 11:03:24AM +0000, Marc Zyngier wrote: > Hi Joey, > > On Fri, 24 Nov 2023 16:34:45 +0000, > Joey Gouly <joey.gouly@arm.com> wrote: > > > > Hello everyone, > > > > This series implements the Permission Overlay Extension introduced in 2022 > > VMSA enhancements [1]. It is based on v6.7-rc2. > > > > Changes since v2[2]: > > # Added ptrace support and selftest > > # Add missing POR_EL0 initialisation in fork/clone > > # Rebase onto v6.7-rc2 > > # Add r-bs > > > > The Permission Overlay Extension allows to constrain permissions on memory > > regions. This can be used from userspace (EL0) without a system call or TLB > > invalidation. > > I have given this series a few more thoughts, and came to the > conclusion that is it still incomplete on the KVM front: > > * FEAT_S1POE often comes together with FEAT_S2POE. For obvious > reasons, we cannot afford to let the guest play with S2POR_EL1, nor > do we want to advertise FEAT_S2POE to the guest. > > You will need to add some additional FGT for this, and mask out > FEAT_S2POE from the guest's view of the ID registers. I found out last week that I had misunderstood S2POR_EL1, so yes looks like we need to trap that. I will add that in. > > * letting the guest play with POE comes with some interesting strings > attached: a guest that has started on a POE-enabled host cannot be > migrated to one that doesn't have POE. which means that the POE > registers should only be visible to the host userspace if enabled in > the guest's ID registers, and thus only context-switched in these > conditions. They should otherwise UNDEF. Can you give me some clarification here? - By visible to the host userspace do you mean via the GET_ONE_REG API? - Currently the ID register (ID_AA64MMFR3_EL1) is not ID_WRITABLE, should this series or another make it so? Currently if the host had POE it's enabled in the guest, so I believe migration to a non-POE host will fail? - For the context switch, do you mean something like: if (system_supports_poe() && ID_REG(MMFR3_EL1) & S1POE) ctxt_sys_reg(ctxt, POR_EL0) = read_sysreg_s(SYS_POR_EL0); That would need some refactoring, since I don't see how to access id_regs from struct kvm_cpu_context. Thanks, Joey