[PATCH 10/11] arm64/kvm: context-switch ptrauth registers

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, we disable guest usage of pointer authentication instructions and accesses

[PATCH 07/11] arm64: add basic pointer authentication support

This patch adds basic support for pointer authentication, allowing userspace to make use of APIAKey. The kernel maintains an APIAKey value for each process (shared by all threads within), which is initialised to a random value at exec() time. Instructions using other keys (APIBKey, APDAKey,

[PATCH 09/11] arm64/kvm: preserve host HCR_EL2 value

When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which is a constant value. This works today, as the host HCR_EL2 value is always the same, but this will get in the way of supporting extensions that require HCR_EL2 bits to be set conditionally for the host. To allow such features

[PATCH 11/11] arm64: docs: document pointer authentication

Now that we've added code to support pointer authentication, add some documentation so that people can figure out if/how to use it. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Jiong Wang Cc: Will Deacon

[PATCH 06/11] arm64: Don't trap host pointer auth use to EL2

To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions and accesses to pointer authentication keys are not trapped to EL2 (where we will not be able to handle them). This patch ensures that HCR_EL2 is configured appropriately

[PATCH 05/11] arm64/cpufeature: detect pointer authentication

So that we can dynamically handle the presence of pointer authentication functionality, wire up probing code in cpufeature.c. Currently, this only detects the presence of an architected algorithm. Signed-off-by: Mark Rutland Cc: Catalin Marinas

[PATCH 04/11] arm64/cpufeature: add ARMv8.3 id_aa64isar1 bits

>From ARMv8.3 onwards, ID_AA64ISAR1 is no longer entirely RES0, and now has four fields describing the presence of pointer authentication functionality: * APA - address authentication present, using an architected algorithm * API - address authentication present, using an IMP DEF algorithm * GPA

[PATCH 00/11] ARMv8.3 pointer authentication userspace support

This series adds support for the ARMv8.3 pointer authentication extension. Since RFC [1]: * Make the KVM context switch (semi-lazy) * Rebase to v4.13-rc1 * Improve pointer authentication documentation * Add hwcap documentation * Various minor cleanups I've pushed the series to the

[PATCH 02/11] asm-generic: mm_hooks: allow hooks to be overridden individually

Currently, an architecture must either implement all of the mm hooks itself, or use all of those provided by the asm-generic implementation. When an architecture only needs to override a single hook, it must copy the stub implementations from the asm-generic version. To avoid this repetition,

[PATCH 03/11] arm64: add pointer authentication register bits

The ARMv8.3 pointer authentication extension adds: * New fields in ID_AA64ISAR1 to report the presence of pointer authentication functionality. * New control bits in SCTLR_ELx to enable this functionality. * New system registers to hold the keys necessary for this functionality. * A new

[PATCH 01/11] arm64: docs: describe ELF hwcaps

We don't document our ELF hwcaps, leaving developers to interpret them according to hearsay, guesswork, or (in exceptional cases) inspection of the current kernel code. This is less than optimal, and it would be far better if we had some definitive description of each of the ELF hwcaps that

Re: [PATCH] arm64: kvm: reuse existing cache type/info related macros

On Thu, Jun 29, 2017 at 07:06:44PM +0100, Sudeep Holla wrote: > We already have various macros related to cache type and bitfields in > CLIDR system register. We can replace some of the hardcoded values > here using those existing macros. > > This patch reuses those existing cache type/info

Re: [RFC PATCH v2 00/38] Nested Virtualization on KVM/ARM

Hi Jintack, On Tue, Jul 18, 2017 at 10:23:05PM -0400, Jintack Lim wrote: > On Tue, Jul 18, 2017 at 12:58 PM, Jintack Lim wrote: > > Nested virtualization is the ability to run a virtual machine inside another > > virtual machine. In other words, it’s about running a

Re: [PATCH] arm64: kvm: reuse existing cache type/info related macros

On 19/07/17 10:01, Christoffer Dall wrote: > On Thu, Jun 29, 2017 at 07:06:44PM +0100, Sudeep Holla wrote: >> We already have various macros related to cache type and bitfields in >> CLIDR system register. We can replace some of the hardcoded values >> here using those existing macros. >> >>

Re: [PATCH 07/11] firmware: arm_sdei: Add driver for Software Delegated Exceptions

On Mon, May 15, 2017 at 06:43:55PM +0100, James Morse wrote: > The Software Delegated Exception Interface (SDEI) is an ARM standard > for registering callbacks from the platform firmware into the OS. > This is typically used to implement RAS notifications. > > Add the code for detecting the SDEI

Re: [RFC PATCH v2 00/38] Nested Virtualization on KVM/ARM

On Wed, Jul 19, 2017 at 4:49 AM, Christoffer Dall wrote: > Hi Jintack, > > On Tue, Jul 18, 2017 at 10:23:05PM -0400, Jintack Lim wrote: >> On Tue, Jul 18, 2017 at 12:58 PM, Jintack Lim wrote: >> > Nested virtualization is the ability to run a virtual