linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Amit Daniel Kachhap <amit.kachhap@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Andrew Jones <drjones@redhat.com>,
	linux-kernel@vger.kernel.org,
	Julien Thierry <julien.thierry@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Kristina Martsenko <kristina.martsenko@arm.com>,
	kvmarm@lists.cs.columbia.edu,
	Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 5/6] arm64/kvm: control accessibility of ptrauth key registers
Date: Tue, 26 Feb 2019 18:34:39 +0000	[thread overview]
Message-ID: <fb401da1-63cb-fde1-67e4-e15f58940ae9@arm.com> (raw)
In-Reply-To: <1550568271-5319-6-git-send-email-amit.kachhap@arm.com>

Hi Amit,

On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> According to userspace settings, ptrauth key registers are conditionally
> present in guest system register list based on user specified flag
> KVM_ARM_VCPU_PTRAUTH.
> 
> Reset routines still sets these registers to default values but they are
> left like that as they are conditionally accessible (set/get).

What problem is this patch solving?

I think it's that now we have ptrauth support, we have a glut of new registers visible to
user-space. This breaks migration and save/resume if the target machine doesn't have
pointer-auth configured, even if the guest wasn't using it.
Because we've got a VCPU bit, we can be smarter about this, and only expose the registers
if user-space was able to enable ptrauth.


> ---
> This patch needs patch [1] by Dave Martin and adds feature to manage accessibility in a scalable way.
> 
> [1]: https://lore.kernel.org/linux-arm-kernel/1547757219-19439-13-git-send-email-Dave.Martin@arm.com/ 

This is v4. Shortly before you posted this there was a v5 (but the subject changed, easily
missed). V5 has subsequently been reviewed. As we can't have both, could you rebase onto
that v5 so that there is one way of doing this?

(in general if you could re-post the version you develop/tested with then it makes it
clear what is going on)


> diff --git a/Documentation/arm64/pointer-authentication.txt b/Documentation/arm64/pointer-authentication.txt
> index 0529a7d..996e435 100644
> --- a/Documentation/arm64/pointer-authentication.txt
> +++ b/Documentation/arm64/pointer-authentication.txt
> @@ -87,3 +87,7 @@ created by passing a flag (KVM_ARM_VCPU_PTRAUTH) requesting this feature
>  to be enabled. Without this flag, pointer authentication is not enabled
>  in KVM guests and attempted use of the feature will result in an UNDEFINED
>  exception being injected into the guest.
> +
> +Additionally, when KVM_ARM_VCPU_PTRAUTH is not set then KVM will filter
> +out the Pointer Authentication system key registers from KVM_GET/SET_REG_*
> +ioctls.
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index f7bcc60..c2f4974 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1005,8 +1005,13 @@ static bool trap_ptrauth(struct kvm_vcpu *vcpu,
>  	return false;
>  }
>  
> +static bool check_ptrauth(const struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd)
> +{
> +	return kvm_arm_vcpu_ptrauth_allowed(vcpu);
> +}
> +
>  #define __PTRAUTH_KEY(k)						\
> -	{ SYS_DESC(SYS_## k), trap_ptrauth, reset_unknown, k }
> +	{ SYS_DESC(SYS_## k), trap_ptrauth, reset_unknown, k , .check_present = check_ptrauth}


Looks good. I'm pretty sure the changes due to Dave's v5 map neatly.


Thanks,

James

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-02-26 18:34 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-19  9:24 [PATCH v6 0/6] Add ARMv8.3 pointer authentication for kvm guest Amit Daniel Kachhap
2019-02-19  9:24 ` [PATCH v6 1/6] arm64/kvm: preserve host HCR_EL2 value Amit Daniel Kachhap
2019-02-21 11:50   ` Mark Rutland
2019-02-25 18:09     ` Marc Zyngier
2019-02-28  6:43     ` Amit Daniel Kachhap
2019-02-21 15:49   ` Dave Martin
2019-03-01  5:56     ` Amit Daniel Kachhap
2019-02-25 17:39   ` James Morse
2019-02-26 10:06     ` James Morse
2019-03-02 11:09     ` Amit Daniel Kachhap
2019-02-19  9:24 ` [PATCH v6 2/6] arm64/kvm: preserve host MDCR_EL2 value Amit Daniel Kachhap
2019-02-21 11:57   ` Mark Rutland
2019-02-21 15:51   ` Dave Martin
2019-03-01  6:10     ` Amit Daniel Kachhap
2019-02-19  9:24 ` [PATCH v6 3/6] arm64/kvm: context-switch ptrauth registers Amit Daniel Kachhap
2019-02-21 12:29   ` Mark Rutland
2019-02-21 15:51     ` Dave Martin
2019-03-01  6:17       ` Amit Daniel Kachhap
2019-02-28  9:07     ` Amit Daniel Kachhap
2019-02-21 15:53   ` Dave Martin
2019-03-01  9:35     ` Amit Daniel Kachhap
2019-02-26 18:31   ` James Morse
2019-03-04 10:51     ` Amit Daniel Kachhap
2019-02-19  9:24 ` [PATCH v6 4/6] arm64/kvm: add a userspace option to enable pointer authentication Amit Daniel Kachhap
2019-02-21 12:34   ` Mark Rutland
2019-02-28  9:25     ` Amit Daniel Kachhap
2019-02-21 15:53   ` Dave Martin
2019-03-01  9:41     ` Amit Daniel Kachhap
2019-03-01 12:22       ` Dave P Martin
2019-02-26 18:33   ` James Morse
2019-03-04 10:56     ` Amit Daniel Kachhap
2019-02-19  9:24 ` [PATCH v6 5/6] arm64/kvm: control accessibility of ptrauth key registers Amit Daniel Kachhap
2019-02-21 15:53   ` Dave Martin
2019-02-26 18:34   ` James Morse [this message]
2019-02-19  9:24 ` [kvmtool PATCH v6 6/6] arm/kvm: arm64: Add a vcpu feature for pointer authentication Amit Daniel Kachhap
2019-02-21 15:54   ` Dave Martin
2019-03-01 10:37     ` Amit Daniel Kachhap
2019-03-01 11:24       ` Dave P Martin
2019-03-04 11:08         ` Amit Daniel Kachhap
2019-03-05 11:11           ` Dave Martin
2019-02-26 18:03 ` [PATCH v6 0/6] Add ARMv8.3 pointer authentication for kvm guest James Morse

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=fb401da1-63cb-fde1-67e4-e15f58940ae9@arm.com \
    --to=james.morse@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=amit.kachhap@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=drjones@redhat.com \
    --cc=julien.thierry@arm.com \
    --cc=kristina.martsenko@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=ramana.radhakrishnan@arm.com \
    --cc=will.deacon@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).