Re: [PATCH v4 00/17] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation

On Tue, Feb 06, 2018 at 05:56:04PM +, Marc Zyngier wrote: > ARM has recently published a SMC Calling Convention (SMCCC) > specification update[1] that provides an optimised calling convention > and optional, discoverable support for mitigating CVE-2017-5715. ARM > Trusted Firmware (ATF) has

Re: [RFC 2/4] KVM: arm64: Support dirty page tracking for PUD hugepages

Christoffer Dall writes: > On Wed, Jan 10, 2018 at 07:07:27PM +, Punit Agrawal wrote: >> In preparation for creating PUD hugepages at stage 2, add support for >> write protecting PUD hugepages when they are encountered. Write >> protecting guest tables is used to

Re: [RFC 4/4] KVM: arm64: Add support for PUD hugepages at stage 2

Christoffer Dall writes: > On Wed, Jan 10, 2018 at 07:07:29PM +, Punit Agrawal wrote: >> KVM only supports PMD hugepages at stage 2. Extend the stage 2 fault >> handling to add support for PUD hugepages. >> >> Addition of PUD hugpage support enables additional

[PATCH v4 17/17] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround

Now that we've standardised on SMCCC v1.1 to perform the branch prediction invalidation, let's drop the previous band-aid. If vendors haven't updated their firmware to do SMCCC 1.1, they haven't updated PSCI either, so we don't loose anything. Tested-by: Ard Biesheuvel

[PATCH v4 16/17] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1. It is lovely. Really. Tested-by: Ard Biesheuvel Signed-off-by: Marc Zyngier --- arch/arm64/kernel/bpi.S| 20 + arch/arm64/kernel/cpu_errata.c | 68

[PATCH v4 15/17] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive

One of the major improvement of SMCCC v1.1 is that it only clobbers the first 4 registers, both on 32 and 64bit. This means that it becomes very easy to provide an inline version of the SMC call primitive, and avoid performing a function call to stash the registers that would otherwise be

[PATCH v4 14/17] arm/arm64: smccc: Make function identifiers an unsigned quantity

Function identifiers are a 32bit, unsigned quantity. But we never tell so to the compiler, resulting in the following: 4ac: b26187e0mov x0, #0x8001 We thus rely on the firmware narrowing it for us, which is not always a reasonable expectation. Cc:

[PATCH v4 13/17] firmware/psci: Expose SMCCC version through psci_ops

Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed, let's do that at boot time, and expose the version of the calling convention as part of the psci_ops structure. Acked-by: Lorenzo Pieralisi Reviewed-by: Robin Murphy Tested-by:

[PATCH v4 12/17] firmware/psci: Expose PSCI conduit

In order to call into the firmware to apply workarounds, it is useful to find out whether we're using HVC or SMC. Let's expose this through the psci_ops. Acked-by: Lorenzo Pieralisi Reviewed-by: Robin Murphy Tested-by: Ard Biesheuvel

[PATCH v4 11/17] arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling

We want SMCCC_ARCH_WORKAROUND_1 to be fast. As fast as possible. So let's intercept it as early as we can by testing for the function call number as soon as we've identified a HVC call coming from the guest. Tested-by: Ard Biesheuvel Reviewed-by: Christoffer Dall

[PATCH v4 10/17] arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support

A new feature of SMCCC 1.1 is that it offers firmware-based CPU workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides BP hardening for CVE-2017-5715. If the host has some mitigation for this issue, report that we deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the host workaround

[PATCH v4 09/17] arm/arm64: KVM: Turn kvm_psci_version into a static inline

We're about to need kvm_psci_version in HYP too. So let's turn it into a static inline, and pass the kvm structure as a second parameter (so that HYP can do a kern_hyp_va on it). Tested-by: Ard Biesheuvel Reviewed-by: Christoffer Dall

[PATCH v4 05/17] arm/arm64: KVM: Add PSCI_VERSION helper

As we're about to trigger a PSCI version explosion, it doesn't hurt to introduce a PSCI_VERSION helper that is going to be used everywhere. Reviewed-by: Christoffer Dall Tested-by: Ard Biesheuvel Signed-off-by: Marc Zyngier

[PATCH v4 08/17] arm/arm64: KVM: Advertise SMCCC v1.1

The new SMC Calling Convention (v1.1) allows for a reduced overhead when calling into the firmware, and provides a new feature discovery mechanism. Make it visible to KVM guests. Tested-by: Ard Biesheuvel Reviewed-by: Christoffer Dall

[PATCH v4 07/17] arm/arm64: KVM: Implement PSCI 1.0 support

PSCI 1.0 can be trivially implemented by providing the FEATURES call on top of PSCI 0.2 and returning 1.0 as the PSCI version. We happily ignore everything else, as they are either optional or are clarifications that do not require any additional change. PSCI 1.0 is now the default until we

[PATCH v4 06/17] arm/arm64: KVM: Add smccc accessors to PSCI code

Instead of open coding the accesses to the various registers, let's add explicit SMCCC accessors. Reviewed-by: Christoffer Dall Tested-by: Ard Biesheuvel Signed-off-by: Marc Zyngier --- virt/kvm/arm/psci.c | 52

[PATCH v4 04/17] arm/arm64: KVM: Consolidate the PSCI include files

As we're about to update the PSCI support, and because I'm lazy, let's move the PSCI include file to include/kvm so that both ARM architectures can find it. Acked-by: Christoffer Dall Tested-by: Ard Biesheuvel Signed-off-by: Marc Zyngier

[PATCH v4 03/17] arm64: KVM: Increment PC after handling an SMC trap

When handling an SMC trap, the "preferred return address" is set to that of the SMC, and not the next PC (which is a departure from the behaviour of an SMC that isn't trapped). Increment PC in the handler, as the guest is otherwise forever stuck... Cc: sta...@vger.kernel.org Fixes: acfb3b883f6d

[PATCH v4 02/17] arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls

KVM doesn't follow the SMCCC when it comes to unimplemented calls, and inject an UNDEF instead of returning an error. Since firmware calls are now used for security mitigation, they are becoming more common, and the undef is counter productive. Instead, let's follow the SMCCC which states that -1

[PATCH v4 00/17] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation

ARM has recently published a SMC Calling Convention (SMCCC) specification update[1] that provides an optimised calling convention and optional, discoverable support for mitigating CVE-2017-5715. ARM Trusted Firmware (ATF) has already gained such an implementation[2]. This series addresses a few

[PATCH v4 01/17] arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls

KVM doesn't follow the SMCCC when it comes to unimplemented calls, and inject an UNDEF instead of returning an error. Since firmware calls are now used for security mitigation, they are becoming more common, and the undef is counter productive. Instead, let's follow the SMCCC which states that -1

Re: [RFC 4/4] KVM: arm64: Add support for PUD hugepages at stage 2

On Wed, Jan 10, 2018 at 07:07:29PM +, Punit Agrawal wrote: > KVM only supports PMD hugepages at stage 2. Extend the stage 2 fault > handling to add support for PUD hugepages. > > Addition of PUD hugpage support enables additional hugepage sizes (1G *hugepage > with 4K

Re: [RFC 2/4] KVM: arm64: Support dirty page tracking for PUD hugepages

On Wed, Jan 10, 2018 at 07:07:27PM +, Punit Agrawal wrote: > In preparation for creating PUD hugepages at stage 2, add support for > write protecting PUD hugepages when they are encountered. Write > protecting guest tables is used to track dirty pages when migrating VMs. > > Also, provide

Re: [RFC v2 REPOST] arm64: KVM: KVM API extensions for SVE

On Tue, Feb 06, 2018 at 11:43:16AM +, Dave Martin wrote: > On Mon, Feb 05, 2018 at 05:13:08PM +0100, Christoffer Dall wrote: > > Hi Dave, > > > > On Fri, Jan 26, 2018 at 05:28:49PM +, Dave Martin wrote: > > > New feature KVM_ARM_VCPU_SVE: > > > > > > * enables exposure of SVE to the

Re: [PATCHv2 09/12] arm64/kvm: preserve host HCR_EL2 value

On Mon, Nov 27, 2017 at 04:38:03PM +, Mark Rutland wrote: > 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

Re: [PATCHv2 05/12] arm64: Don't trap host pointer auth use to EL2

Hi Mark, On Mon, Nov 27, 2017 at 04:37:59PM +, Mark Rutland wrote: > 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 >

Re: [PATCHv2 10/12] arm64/kvm: context-switch ptrauth registers

On Mon, Nov 27, 2017 at 04:38:04PM +, 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,

Re: [RFC v2 REPOST] arm64: KVM: KVM API extensions for SVE

On Mon, Feb 05, 2018 at 05:13:08PM +0100, Christoffer Dall wrote: > Hi Dave, > > On Fri, Jan 26, 2018 at 05:28:49PM +, Dave Martin wrote: > > New feature KVM_ARM_VCPU_SVE: > > > > * enables exposure of SVE to the guest > > > > * enables visibility of / access to KVM_REG_ARM_SVE_*() via