LKML Archive on
 help / color / Atom feed
From: Mark Rutland <>
To: Christoffer Dall <>
Subject: Re: [PATCHv2 10/12] arm64/kvm: context-switch ptrauth registers
Date: Fri, 9 Mar 2018 14:28:38 +0000
Message-ID: <> (raw)
In-Reply-To: <20180206123847.GY21802@cbox>

On Tue, Feb 06, 2018 at 01:38:47PM +0100, Christoffer Dall wrote:
> On Mon, Nov 27, 2017 at 04:38:04PM +0000, Mark Rutland wrote:
> > When pointer authentication is supported, a guest may wish to use it.
> > This patch adds the necessary KVM infrastructure for this to work, with
> > a semi-lazy context switch of the pointer auth state.
> > 
> > When we schedule a vcpu, 
> That's not quite what the code does, the code only does this when we
> schedule back a preempted or blocked vcpu thread.

Does that only leave the case of the vCPU being scheduled for the first
time? Or am I missing something else?


> > we disable guest usage of pointer
> > authentication instructions and accesses to the keys. While these are
> > disabled, we avoid context-switching the keys. When we trap the guest
> > trying to use pointer authentication functionality, we change to eagerly
> > context-switching the keys, and enable the feature. The next time the
> > vcpu is scheduled out/in, we start again.
> > 
> > Pointer authentication consists of address authentication and generic
> > authentication, and CPUs in a system might have varied support for
> > either. Where support for either feature is not uniform, it is hidden
> > from guests via ID register emulation, as a result of the cpufeature
> > framework in the host.
> > 
> > Unfortunately, address authentication and generic authentication cannot
> > be trapped separately, as the architecture provides a single EL2 trap
> > covering both. If we wish to expose one without the other, we cannot
> > prevent a (badly-written) guest from intermittently using a feature
> > which is not uniformly supported (when scheduled on a physical CPU which
> > supports the relevant feature). 
> We could choose to always trap and emulate in software in this case,
> couldn't we?  (not saying we should though).

Practically speaking, we cannot. Emulating the feature would be so
detrimental to performance as to render the feature useless --  every
function prologue/epilogue in a guest would end up trapping to hyp.

Additionally, if the algorithm is IMP DEF, we simply don't know how to
emulate it.


> Also, this patch doesn't let userspace decide if we should hide or
> expose the feature to guests, and will expose new system registers to
> userspace.  That means that on hardware supporting pointer
> authentication, with this patch, it's not possible to migrate to a
> machine which doesn't have the support.  That's probably a good thing
> (false sense of security etc.), but I wonder if we should have a
> mechanism for userspace to ask for pointer authentication in the guest
> and only if that's enabled, do we expose the feature to the guest and in
> the system register list to user space as well?

Making this an opt-in makes sense to me, given it affects migration.
I'll take a look at what we do for SVE.


> > When the guest is scheduled on a
> > physical CPU lacking the feature, these atetmps will result in an UNDEF
> attempts

Whoops. Fixed.


> > +static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu)
> > +{
> > +	kvm_arm_vcpu_ptrauth_disable(vcpu);
> > +}
> > +
> I still find this decision to begin trapping again quite arbitrary, and
> would at least prefer this to be in vcpu_load (which would make the
> behavior match the commit text as well).

Sure, done.

> My expectation would be that if a guest is running software with pointer
> authentication enabled, then it's likely to either keep using the
> feature, or not use it at all, so I would make this a one-time flag.

I think it's likely that some applications will use ptrauth while others
do not. Even if the gust OS supports ptrauth, KVM may repeatedly preempt
an application that doesn't use it, and we'd win in that case.

There are also some rarer cases, like kexec in a guest from a
ptrauth-aware kernel to a ptrauth-oblivious one.

I don't have strong feelings either way, and I have no data.


  reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27 16:37 [PATCHv2 00/12] ARMv8.3 pointer authentication userspace support Mark Rutland
2017-11-27 16:37 ` [PATCHv2 01/12] asm-generic: mm_hooks: allow hooks to be overridden individually Mark Rutland
2017-11-27 16:37 ` [PATCHv2 02/12] arm64: add pointer authentication register bits Mark Rutland
2017-11-27 16:37 ` [PATCHv2 03/12] arm64/cpufeature: add ARMv8.3 id_aa64isar1 bits Mark Rutland
2017-11-27 16:37 ` [PATCHv2 04/12] arm64/cpufeature: detect pointer authentication Mark Rutland
2017-11-27 16:37 ` [PATCHv2 05/12] arm64: Don't trap host pointer auth use to EL2 Mark Rutland
2018-02-06 12:39   ` Christoffer Dall
2018-02-12 16:00     ` Mark Rutland
2017-11-27 16:38 ` [PATCHv2 06/12] arm64: add basic pointer authentication support Mark Rutland
2018-05-22 19:06   ` Adam Wallis
2017-11-27 16:38 ` [PATCHv2 07/12] arm64: expose user PAC bit positions via ptrace Mark Rutland
2017-11-27 16:38 ` [PATCHv2 08/12] arm64: perf: strip PAC when unwinding userspace Mark Rutland
2017-11-27 16:38 ` [PATCHv2 09/12] arm64/kvm: preserve host HCR_EL2 value Mark Rutland
2018-02-06 12:39   ` Christoffer Dall
2018-04-09 14:57     ` Mark Rutland
2018-04-09 19:03       ` Christoffer Dall
2017-11-27 16:38 ` [PATCHv2 10/12] arm64/kvm: context-switch ptrauth registers Mark Rutland
2018-02-06 12:38   ` Christoffer Dall
2018-03-09 14:28     ` Mark Rutland [this message]
2018-04-09 12:58       ` Christoffer Dall
2018-04-09 14:37         ` Mark Rutland
2017-11-27 16:38 ` [PATCHv2 11/12] arm64: enable pointer authentication Mark Rutland
2017-11-27 16:38 ` [PATCHv2 12/12] arm64: docs: document " Mark Rutland
2017-11-28 15:07   ` Andrew Jones
2017-12-04 12:39     ` Mark Rutland
2017-12-04 12:49       ` Andrew Jones

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone