All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: qemu-devel@nongnu.org, kvmarm@lists.cs.columbia.edu,
	kvm@vger.kernel.org, kernel-team@android.com,
	Eric Auger <eric.auger@redhat.com>,
	Andrew Jones <drjones@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [PATCH v2] hw/arm/virt: KVM: Enable PAuth when supported by the host
Date: Thu, 06 Jan 2022 17:29:10 +0000	[thread overview]
Message-ID: <875yqwvkm1.wl-maz@kernel.org> (raw)
In-Reply-To: <3db95713-2f05-3c70-82b1-7e12c579d3e2@linaro.org>

On Thu, 06 Jan 2022 17:20:33 +0000,
Richard Henderson <richard.henderson@linaro.org> 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.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2] hw/arm/virt: KVM: Enable PAuth when supported by the host
Date: Thu, 06 Jan 2022 17:29:10 +0000	[thread overview]
Message-ID: <875yqwvkm1.wl-maz@kernel.org> (raw)
In-Reply-To: <3db95713-2f05-3c70-82b1-7e12c579d3e2@linaro.org>

On Thu, 06 Jan 2022 17:20:33 +0000,
Richard Henderson <richard.henderson@linaro.org> 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.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Andrew Jones <drjones@redhat.com>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org,
	Eric Auger <eric.auger@redhat.com>,
	kernel-team@android.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2] hw/arm/virt: KVM: Enable PAuth when supported by the host
Date: Thu, 06 Jan 2022 17:29:10 +0000	[thread overview]
Message-ID: <875yqwvkm1.wl-maz@kernel.org> (raw)
In-Reply-To: <3db95713-2f05-3c70-82b1-7e12c579d3e2@linaro.org>

On Thu, 06 Jan 2022 17:20:33 +0000,
Richard Henderson <richard.henderson@linaro.org> 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.


  reply	other threads:[~2022-01-06 17:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-03 18:05 [PATCH v2] hw/arm/virt: KVM: Enable PAuth when supported by the host Marc Zyngier
2022-01-03 18:05 ` Marc Zyngier
2022-01-03 18:05 ` Marc Zyngier
2022-01-05 14:58 ` Andrew Jones
2022-01-05 14:58   ` Andrew Jones
2022-01-05 14:58   ` Andrew Jones
2022-01-05 21:36 ` Richard Henderson
2022-01-05 21:36   ` Richard Henderson
2022-01-05 21:36   ` Richard Henderson
2022-01-06  9:16   ` Marc Zyngier
2022-01-06  9:16     ` Marc Zyngier
2022-01-06  9:16     ` Marc Zyngier
2022-01-06 17:20     ` Richard Henderson
2022-01-06 17:20       ` Richard Henderson
2022-01-06 17:20       ` Richard Henderson
2022-01-06 17:29       ` Marc Zyngier [this message]
2022-01-06 17:29         ` Marc Zyngier
2022-01-06 17:29         ` Marc Zyngier
2022-01-06 18:26         ` Richard Henderson
2022-01-06 18:26           ` Richard Henderson
2022-01-06 18:26           ` Richard Henderson
2022-01-06 19:25           ` Marc Zyngier
2022-01-06 19:25             ` Marc Zyngier
2022-01-06 19:25             ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875yqwvkm1.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=drjones@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.