| Message ID | 20181207183931.4285-5-kristina.martsenko@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
On Fri, 07 Dec 2018 18:39:22 +0000, Kristina Martsenko <kristina.martsenko@arm.com> wrote: > > From: Mark Rutland <mark.rutland@arm.com> > > In subsequent patches we're going to expose ptrauth to the host kernel > and userspace, but things are a bit trickier for guest kernels. For the > time being, let's hide ptrauth from KVM guests. > > Regardless of how well-behaved the guest kernel is, guest userspace > could attempt to use ptrauth instructions, triggering a trap to EL2, > resulting in noise from kvm_handle_unknown_ec(). So let's write up a > handler for the PAC trap, which silently injects an UNDEF into the > guest, as if the feature were really missing. > > Signed-off-by: Mark Rutland <mark.rutland@arm.com> > Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com> > Reviewed-by: Andrew Jones <drjones@redhat.com> > Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> > Cc: Marc Zyngier <marc.zyngier@arm.com> > Cc: kvmarm@lists.cs.columbia.edu Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> M. -- Jazz is not dead, it just smell funny.
On 12/7/18 12:39 PM, Kristina Martsenko wrote: > From: Mark Rutland <mark.rutland@arm.com> > > In subsequent patches we're going to expose ptrauth to the host kernel > and userspace, but things are a bit trickier for guest kernels. For the > time being, let's hide ptrauth from KVM guests. > > Regardless of how well-behaved the guest kernel is, guest userspace > could attempt to use ptrauth instructions, triggering a trap to EL2, > resulting in noise from kvm_handle_unknown_ec(). So let's write up a > handler for the PAC trap, which silently injects an UNDEF into the > guest, as if the feature were really missing. Reviewing the long thread that accompanied v5, I thought we were *not* going to trap PAuth instructions from the guest. In particular, the OS distribution may legitimately be built to include hint-space nops. This includes XPACLRI, which is used by the C++ exception unwinder and not controlled by SCTLR_EL1.EnI{A,B}. It seems like the header comment here, and > +/* > + * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into > + * a NOP). > + */ > +static int kvm_handle_ptrauth(struct kvm_vcpu *vcpu, struct kvm_run *run) > + here, need updating. r~
On 09/12/2018 14:53, Richard Henderson wrote: > On 12/7/18 12:39 PM, Kristina Martsenko wrote: >> From: Mark Rutland <mark.rutland@arm.com> >> >> In subsequent patches we're going to expose ptrauth to the host kernel >> and userspace, but things are a bit trickier for guest kernels. For the >> time being, let's hide ptrauth from KVM guests. >> >> Regardless of how well-behaved the guest kernel is, guest userspace >> could attempt to use ptrauth instructions, triggering a trap to EL2, >> resulting in noise from kvm_handle_unknown_ec(). So let's write up a >> handler for the PAC trap, which silently injects an UNDEF into the >> guest, as if the feature were really missing. > > Reviewing the long thread that accompanied v5, I thought we were *not* going to > trap PAuth instructions from the guest. > > In particular, the OS distribution may legitimately be built to include > hint-space nops. This includes XPACLRI, which is used by the C++ exception > unwinder and not controlled by SCTLR_EL1.EnI{A,B}. The plan was to disable trapping, yes. However, after that thread there was a retrospective change applied to the architecture, such that the XPACLRI (and XPACD/XPACI) instructions are no longer trapped by HCR_EL2.API. (The public documentation on this has not been updated yet.) This means that no HINT-space instructions should trap anymore. (The guest is expected to not set SCTLR_EL1.EnI{A,B} since ID_AA64ISAR1_EL1.{APA,API} read as 0.) > It seems like the header comment here, and Sorry, which header comment? >> +/* >> + * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into >> + * a NOP). >> + */ >> +static int kvm_handle_ptrauth(struct kvm_vcpu *vcpu, struct kvm_run *run) >> + > > here, need updating. Changed it to "a trapped ptrauth instruction". Kristina
On 12/10/18 2:12 PM, Kristina Martsenko wrote: > The plan was to disable trapping, yes. However, after that thread there > was a retrospective change applied to the architecture, such that the > XPACLRI (and XPACD/XPACI) instructions are no longer trapped by > HCR_EL2.API. (The public documentation on this has not been updated > yet.) This means that no HINT-space instructions should trap anymore. Ah, thanks for the update. I'll update my QEMU patch set. >> It seems like the header comment here, and > Sorry, which header comment? Sorry, the patch commit message. r~
On 10/12/2018 20:22, Richard Henderson wrote: > On 12/10/18 2:12 PM, Kristina Martsenko wrote: >> The plan was to disable trapping, yes. However, after that thread there >> was a retrospective change applied to the architecture, such that the >> XPACLRI (and XPACD/XPACI) instructions are no longer trapped by >> HCR_EL2.API. (The public documentation on this has not been updated >> yet.) This means that no HINT-space instructions should trap anymore. > > Ah, thanks for the update. I'll update my QEMU patch set. > >>> It seems like the header comment here, and >> Sorry, which header comment? > > Sorry, the patch commit message. Ah ok. Still seems correct. Kristina
On Mon, 10 Dec 2018 at 20:22, Richard Henderson <richard.henderson@linaro.org> wrote: > > On 12/10/18 2:12 PM, Kristina Martsenko wrote: > > The plan was to disable trapping, yes. However, after that thread there > > was a retrospective change applied to the architecture, such that the > > XPACLRI (and XPACD/XPACI) instructions are no longer trapped by > > HCR_EL2.API. (The public documentation on this has not been updated > > yet.) This means that no HINT-space instructions should trap anymore. > > Ah, thanks for the update. I'll update my QEMU patch set. Just to follow up on this loose end, this change to HCR_EL2.API trap behaviour is documented in the 00bet9 release of the system register XML which came out today: https://developer.arm.com/products/architecture/cpu-architecture/a-profile/exploration-tools/system-registers-for-armv8-a thanks -- PMM
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c index 35a81bebd02b..ab35929dcb3c 100644 --- a/arch/arm64/kvm/handle_exit.c +++ b/arch/arm64/kvm/handle_exit.c @@ -173,6 +173,23 @@ static int handle_sve(struct kvm_vcpu *vcpu, struct kvm_run *run) return 1; } +/* + * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into + * a NOP). + */ +static int kvm_handle_ptrauth(struct kvm_vcpu *vcpu, struct kvm_run *run) +{ + /* + * We don't currently support ptrauth in a guest, and we mask the ID + * registers to prevent well-behaved guests from trying to make use of + * it. + * + * Inject an UNDEF, as if the feature really isn't present. + */ + kvm_inject_undefined(vcpu); + return 1; +} + static exit_handle_fn arm_exit_handlers[] = { [0 ... ESR_ELx_EC_MAX] = kvm_handle_unknown_ec, [ESR_ELx_EC_WFx] = kvm_handle_wfx, @@ -195,6 +212,7 @@ static exit_handle_fn arm_exit_handlers[] = { [ESR_ELx_EC_BKPT32] = kvm_handle_guest_debug, [ESR_ELx_EC_BRK64] = kvm_handle_guest_debug, [ESR_ELx_EC_FP_ASIMD] = handle_no_fpsimd, + [ESR_ELx_EC_PAC] = kvm_handle_ptrauth, }; static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 22fbbdbece3c..1ca592d38c3c 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1040,6 +1040,14 @@ static u64 read_id_reg(struct sys_reg_desc const *r, bool raz) kvm_debug("SVE unsupported for guests, suppressing\n"); val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT); + } else if (id == SYS_ID_AA64ISAR1_EL1) { + const u64 ptrauth_mask = (0xfUL << ID_AA64ISAR1_APA_SHIFT) | + (0xfUL << ID_AA64ISAR1_API_SHIFT) | + (0xfUL << ID_AA64ISAR1_GPA_SHIFT) | + (0xfUL << ID_AA64ISAR1_GPI_SHIFT); + if (val & ptrauth_mask) + kvm_debug("ptrauth unsupported for guests, suppressing\n"); + val &= ~ptrauth_mask; } else if (id == SYS_ID_AA64MMFR1_EL1) { if (val & (0xfUL << ID_AA64MMFR1_LOR_SHIFT)) kvm_debug("LORegions unsupported for guests, suppressing\n");