Re: [PATCH v6 04/13] arm64/kvm: hide ptrauth from guests
On Mon, 10 Dec 2018 at 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. 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 ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v6 04/13] arm64/kvm: hide ptrauth from guests
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 ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v6 04/13] arm64/kvm: hide ptrauth from guests
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~ ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v6 04/13] arm64/kvm: hide ptrauth from guests
On 09/12/2018 14:53, Richard Henderson wrote:
> On 12/7/18 12:39 PM, Kristina Martsenko wrote:
>> From: Mark Rutland
>>
>> 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
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v6 04/13] arm64/kvm: hide ptrauth from guests
On 12/7/18 12:39 PM, Kristina Martsenko wrote:
> From: Mark Rutland
>
> 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~
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v6 04/13] arm64/kvm: hide ptrauth from guests
On Fri, 07 Dec 2018 18:39:22 +, Kristina Martsenko wrote: > > From: Mark Rutland > > 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 > Signed-off-by: Kristina Martsenko > Reviewed-by: Andrew Jones > Reviewed-by: Christoffer Dall > Cc: Marc Zyngier > Cc: kvmarm@lists.cs.columbia.edu Reviewed-by: Marc Zyngier M. -- Jazz is not dead, it just smell funny. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
