On Thu, 06 Jan 2022 17:20:33 +0000,
Richard Henderson <richard.henderson@xxxxxxxxxx> wrote:
>
> 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.
Indeed. But KVM never returns just one flag. It only exposes both or
none.
> 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.
We explicitly decided against supporting such a configuration. If
someone comes up with such a contraption, guests won't be able to see
it.
M.
--
Without deviation from the norm, progress is not possible.
