On 1/6/22 1:16 AM, Marc Zyngier wrote:
+static bool kvm_arm_pauth_supported(void) +{ + return (kvm_check_extension(kvm_state, KVM_CAP_ARM_PTRAUTH_ADDRESS) && + kvm_check_extension(kvm_state, KVM_CAP_ARM_PTRAUTH_GENERIC)); +}Do we really need to have them both set to play the game? Given that the only thing that happens is that we disable whatever host support exists, can we have "pauth enabled" mean whatever subset the host has?The host will always expose either both features or none, and that's part of the ABI. From the bit of kernel documentation located in Documentation/virt/kvm/api.rst: <quote> 4.82 KVM_ARM_VCPU_INIT ---------------------- [...] - KVM_ARM_VCPU_PTRAUTH_ADDRESS: Enables Address Pointer authentication for arm64 only. Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS. 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. - KVM_ARM_VCPU_PTRAUTH_GENERIC: Enables Generic Pointer authentication for arm64 only. Depends on KVM_CAP_ARM_PTRAUTH_GENERIC. 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. </quote> KVM will reject the initialisation if only one of the features is requested, so checking and enabling both makes sense to me.
Well, no, that's not what that says. It says that *if* both host flags are set, then both guest flags must be set or both unset.
It's probably all academic anyway, because I can't actually imagine a vendor implementing ADDR and not GENERIC, but in theory we ought to be able to support a host with only ADDR.
r~ _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
