[v9,4/5] KVM: arm64: Add capability to advertise ptrauth for guest
diff mbox series

Message ID 1555039236-10608-5-git-send-email-amit.kachhap@arm.com
State New, archived
Headers show
Series
  • Add ARMv8.3 pointer authentication for kvm guest
Related show

Commit Message

Amit Kachhap April 12, 2019, 3:20 a.m. UTC
This patch advertises the capability of two cpu feature called address
pointer authentication and generic pointer authentication. These
capabilities depend upon system support for pointer authentication and
VHE mode.

The current arm64 KVM partially implements pointer authentication and
support of address/generic authentication are tied together. However,
separate ABI requirements for both of them is added so that any future
isolated implementation will not require any ABI changes.

Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
---
Changes since v8:
*  Keep the capability check same for the 2 vcpu ptrauth features. [Dave Martin]

 Documentation/virtual/kvm/api.txt | 2 ++
 arch/arm64/kvm/reset.c            | 5 +++++
 include/uapi/linux/kvm.h          | 2 ++
 3 files changed, 9 insertions(+)

Comments

Dave Martin April 16, 2019, 4:32 p.m. UTC | #1
On Fri, Apr 12, 2019 at 08:50:35AM +0530, Amit Daniel Kachhap wrote:
> This patch advertises the capability of two cpu feature called address
> pointer authentication and generic pointer authentication. These
> capabilities depend upon system support for pointer authentication and
> VHE mode.
> 
> The current arm64 KVM partially implements pointer authentication and
> support of address/generic authentication are tied together. However,
> separate ABI requirements for both of them is added so that any future
> isolated implementation will not require any ABI changes.
> 
> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Christoffer Dall <christoffer.dall@arm.com>
> Cc: kvmarm@lists.cs.columbia.edu
> ---
> Changes since v8:
> *  Keep the capability check same for the 2 vcpu ptrauth features. [Dave Martin]
> 
>  Documentation/virtual/kvm/api.txt | 2 ++
>  arch/arm64/kvm/reset.c            | 5 +++++
>  include/uapi/linux/kvm.h          | 2 ++
>  3 files changed, 9 insertions(+)
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 9d202f4..56021d0 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2756,9 +2756,11 @@ Possible features:
>  	- KVM_ARM_VCPU_PTRAUTH_ADDRESS: Enables Address Pointer authentication
>  	  for the CPU and supported only on arm64 architecture.
>  	  Must be requested if KVM_ARM_VCPU_PTRAUTH_GENERIC is also requested.
> +	  Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS.

What if KVM_CAP_ARM_PTRAUTH_ADDRESS is absent and
KVM_ARM_VCPU_PTRAUTH_GENERIC is requested?  By these rules, we have a
contradiction: userspace both must request and must not request
KVM_ARM_VCPU_PTRAUTH_ADDRESS.

We could qualify as follows:

	Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS.
	Must be requested if KVM_CAP_ARM_PTRAUTH_ADDRESS is present and
	KVM_ARM_VCPU_PTRAUTH_GENERIC is also requested.

>  	- KVM_ARM_VCPU_PTRAUTH_GENERIC: Enables Generic Pointer authentication
>  	  for the CPU and supported only on arm64 architecture.
>  	  Must be requested if KVM_ARM_VCPU_PTRAUTH_ADDRESS is also requested.
> +	  Depends on KVM_CAP_ARM_PTRAUTH_GENERIC.

Similarly.

Or, we go back to having a single cap and a single feature, and add
more caps/features later on if we decide it's possible to support
address/generic auth separately later on.

Otherwise, we end up with complex rules that can't be tested.  This is a
high price to pay for forwards compatibility: userspace's conformance to
the rules can't be fully tested, so there's a fair chance it won't work
properly anyway when hardware/KVM with just one auth type appears.

[...]

Thoughts?

Cheers
---Dave
Amit Kachhap April 17, 2019, 9:39 a.m. UTC | #2
Hi,

On 4/16/19 10:02 PM, Dave Martin wrote:
> On Fri, Apr 12, 2019 at 08:50:35AM +0530, Amit Daniel Kachhap wrote:
>> This patch advertises the capability of two cpu feature called address
>> pointer authentication and generic pointer authentication. These
>> capabilities depend upon system support for pointer authentication and
>> VHE mode.
>>
>> The current arm64 KVM partially implements pointer authentication and
>> support of address/generic authentication are tied together. However,
>> separate ABI requirements for both of them is added so that any future
>> isolated implementation will not require any ABI changes.
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>> Cc: kvmarm@lists.cs.columbia.edu
>> ---
>> Changes since v8:
>> *  Keep the capability check same for the 2 vcpu ptrauth features. [Dave Martin]
>>
>>   Documentation/virtual/kvm/api.txt | 2 ++
>>   arch/arm64/kvm/reset.c            | 5 +++++
>>   include/uapi/linux/kvm.h          | 2 ++
>>   3 files changed, 9 insertions(+)
>>
>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>> index 9d202f4..56021d0 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -2756,9 +2756,11 @@ Possible features:
>>   	- KVM_ARM_VCPU_PTRAUTH_ADDRESS: Enables Address Pointer authentication
>>   	  for the CPU and supported only on arm64 architecture.
>>   	  Must be requested if KVM_ARM_VCPU_PTRAUTH_GENERIC is also requested.
>> +	  Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS.
> 
> What if KVM_CAP_ARM_PTRAUTH_ADDRESS is absent and
> KVM_ARM_VCPU_PTRAUTH_GENERIC is requested?  By these rules, we have a
> contradiction: userspace both must request and must not request
> KVM_ARM_VCPU_PTRAUTH_ADDRESS.
> 
> We could qualify as follows:
> 
> 	Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS.
> 	Must be requested if KVM_CAP_ARM_PTRAUTH_ADDRESS is present and
> 	KVM_ARM_VCPU_PTRAUTH_GENERIC is also requested.
ok agree. This makes it clear.
> 
>>   	- KVM_ARM_VCPU_PTRAUTH_GENERIC: Enables Generic Pointer authentication
>>   	  for the CPU and supported only on arm64 architecture.
>>   	  Must be requested if KVM_ARM_VCPU_PTRAUTH_ADDRESS is also requested.
>> +	  Depends on KVM_CAP_ARM_PTRAUTH_GENERIC.
> 
> Similarly.
> 
> Or, we go back to having a single cap and a single feature, and add
> more caps/features later on if we decide it's possible to support
> address/generic auth separately later on.
> 
> Otherwise, we end up with complex rules that can't be tested.  This is a
> high price to pay for forwards compatibility: userspace's conformance to
> the rules can't be fully tested, so there's a fair chance it won't work
> properly anyway when hardware/KVM with just one auth type appears.
> 
> [...]
> 
> Thoughts?
I agree that single cpufeature/capability is a simple solution to 
implement. The bifurcation of feature was done to reflect the different 
ID register split up.

But the h/w implementation provides a same EL2 exception trap for both 
the features and hence current implementation ties both of the features 
together. I guess in future if this is limitation goes away then one 
auth type is possible. Here I am not sure if the future h/w will retain 
this merged exception trap and add 2 new separate exception trap in 
addition to it.

I guess it will be probably simple split-up of this merged exception 
trap. In this case there won't be any ABI change required as per current 
implementation.

Thanks,
Amit Daniel


> 
> Cheers
> ---Dave
>
Dave Martin April 17, 2019, 3:22 p.m. UTC | #3
On Wed, Apr 17, 2019 at 03:09:02PM +0530, Amit Daniel Kachhap wrote:
> Hi,
> 
> On 4/16/19 10:02 PM, Dave Martin wrote:
> >On Fri, Apr 12, 2019 at 08:50:35AM +0530, Amit Daniel Kachhap wrote:
> >>This patch advertises the capability of two cpu feature called address
> >>pointer authentication and generic pointer authentication. These
> >>capabilities depend upon system support for pointer authentication and
> >>VHE mode.
> >>
> >>The current arm64 KVM partially implements pointer authentication and
> >>support of address/generic authentication are tied together. However,
> >>separate ABI requirements for both of them is added so that any future
> >>isolated implementation will not require any ABI changes.
> >>
> >>Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
> >>Cc: Mark Rutland <mark.rutland@arm.com>
> >>Cc: Marc Zyngier <marc.zyngier@arm.com>
> >>Cc: Christoffer Dall <christoffer.dall@arm.com>
> >>Cc: kvmarm@lists.cs.columbia.edu
> >>---
> >>Changes since v8:
> >>*  Keep the capability check same for the 2 vcpu ptrauth features. [Dave Martin]
> >>
> >>  Documentation/virtual/kvm/api.txt | 2 ++
> >>  arch/arm64/kvm/reset.c            | 5 +++++
> >>  include/uapi/linux/kvm.h          | 2 ++
> >>  3 files changed, 9 insertions(+)
> >>
> >>diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> >>index 9d202f4..56021d0 100644
> >>--- a/Documentation/virtual/kvm/api.txt
> >>+++ b/Documentation/virtual/kvm/api.txt
> >>@@ -2756,9 +2756,11 @@ Possible features:
> >>  	- KVM_ARM_VCPU_PTRAUTH_ADDRESS: Enables Address Pointer authentication
> >>  	  for the CPU and supported only on arm64 architecture.
> >>  	  Must be requested if KVM_ARM_VCPU_PTRAUTH_GENERIC is also requested.
> >>+	  Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS.
> >
> >What if KVM_CAP_ARM_PTRAUTH_ADDRESS is absent and
> >KVM_ARM_VCPU_PTRAUTH_GENERIC is requested?  By these rules, we have a
> >contradiction: userspace both must request and must not request
> >KVM_ARM_VCPU_PTRAUTH_ADDRESS.
> >
> >We could qualify as follows:
> >
> >	Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS.
> >	Must be requested if KVM_CAP_ARM_PTRAUTH_ADDRESS is present and
> >	KVM_ARM_VCPU_PTRAUTH_GENERIC is also requested.
> ok agree. This makes it clear.

[*]

> >>  	- KVM_ARM_VCPU_PTRAUTH_GENERIC: Enables Generic Pointer authentication
> >>  	  for the CPU and supported only on arm64 architecture.
> >>  	  Must be requested if KVM_ARM_VCPU_PTRAUTH_ADDRESS is also requested.
> >>+	  Depends on KVM_CAP_ARM_PTRAUTH_GENERIC.
> >
> >Similarly.
> >
> >Or, we go back to having a single cap and a single feature, and add
> >more caps/features later on if we decide it's possible to support
> >address/generic auth separately later on.
> >
> >Otherwise, we end up with complex rules that can't be tested.  This is a
> >high price to pay for forwards compatibility: userspace's conformance to
> >the rules can't be fully tested, so there's a fair chance it won't work
> >properly anyway when hardware/KVM with just one auth type appears.
> >
> >[...]
> >
> >Thoughts?
> I agree that single cpufeature/capability is a simple solution to implement.
> The bifurcation of feature was done to reflect the different ID register
> split up.
> 
> But the h/w implementation provides a same EL2 exception trap for both the
> features and hence current implementation ties both of the features
> together. I guess in future if this is limitation goes away then one auth
> type is possible. Here I am not sure if the future h/w will retain this
> merged exception trap and add 2 new separate exception trap in addition to
> it.
> 
> I guess it will be probably simple split-up of this merged exception trap.
> In this case there won't be any ABI change required as per current
> implementation.

OK, I'm not opposed to keeping the ABI as-is, with the above
clarification [*] spelled out appropriately for both cases.

Alternatively, or in addition, we could say something like:

"If KVM_CAP_ARM_PTRAUTH_ADDRESS and KVM_CAP_ARM_PTRAUTH_GENERIC are
both present, then both KVM_ARM_VCPU_PTRAUTH_ADDRESS and
KVM_ARM_VCPU_PTRAUTH_GENERIC must be requested or neither must be
requested."

Cheers
---Dave

Patch
diff mbox series

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 9d202f4..56021d0 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2756,9 +2756,11 @@  Possible features:
 	- KVM_ARM_VCPU_PTRAUTH_ADDRESS: Enables Address Pointer authentication
 	  for the CPU and supported only on arm64 architecture.
 	  Must be requested if KVM_ARM_VCPU_PTRAUTH_GENERIC is also requested.
+	  Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS.
 	- KVM_ARM_VCPU_PTRAUTH_GENERIC: Enables Generic Pointer authentication
 	  for the CPU and supported only on arm64 architecture.
 	  Must be requested if KVM_ARM_VCPU_PTRAUTH_ADDRESS is also requested.
+	  Depends on KVM_CAP_ARM_PTRAUTH_GENERIC.
 
 	- KVM_ARM_VCPU_SVE: Enables SVE for the CPU (arm64 only).
 	  Depends on KVM_CAP_ARM_SVE.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index d13406b..be657f6 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -101,6 +101,11 @@  int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_ARM_SVE:
 		r = system_supports_sve();
 		break;
+	case KVM_CAP_ARM_PTRAUTH_ADDRESS:
+	case KVM_CAP_ARM_PTRAUTH_GENERIC:
+		r = has_vhe() && system_supports_address_auth() &&
+				system_supports_generic_auth();
+		break;
 	default:
 		r = 0;
 	}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 1d56444..4dc34f8 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -989,6 +989,8 @@  struct kvm_ppc_resize_hpt {
 #define KVM_CAP_MANUAL_DIRTY_LOG_PROTECT 166
 #define KVM_CAP_HYPERV_CPUID 167
 #define KVM_CAP_ARM_SVE 168
+#define KVM_CAP_ARM_PTRAUTH_ADDRESS 169
+#define KVM_CAP_ARM_PTRAUTH_GENERIC 170
 
 #ifdef KVM_CAP_IRQ_ROUTING