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 alr
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 track dirty pages when migrat
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 hugepage sizes (1G
>
>
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
Signed-off-by: Marc Zyngier
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 +-
2 files changed,
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 clobbered
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: sta...@vger.kernel.or
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: Ard Biesheuvel
Signed-off-by: Marc Zyngier
---
dr
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
Signed-off-by: Marc Zyngier
---
drivers/firmware/psci.c | 2
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
Signed-off-by: Marc Zyngier
---
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 on
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
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/hyp/switch.c
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
---
include/kvm/arm_psci.h| 6 --
include/uapi/linux/psci.h |
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
Signed-off-by: Marc Zyngier
---
arch/arm/kvm/handle_exit.c
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 decid
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 ++--
1 file changed, 42 insertions
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
---
arch/arm/include/asm/kvm_psci.h|
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 (
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
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 th
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
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 triv
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 granul
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 gues
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 HCR_E
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
> abl
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,
Tha
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 KVM
28 matches
Mail list logo