28 Oct, 2020
1 commit
-
According to the SMCCC spec[1](7.5.2 Discovery) the
ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and
SMCCC_RET_NOT_SUPPORTED.0 is "workaround required and safe to call this function"
1 is "workaround not required but safe to call this function"
SMCCC_RET_NOT_SUPPORTED is "might be vulnerable or might not be, who knows, I give up!"SMCCC_RET_NOT_SUPPORTED might as well mean "workaround required, except
calling this function may not work because it isn't implemented in some
cases". Wonderful. We map this SMC call to0 is SPECTRE_MITIGATED
1 is SPECTRE_UNAFFECTED
SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLEFor KVM hypercalls (hvc), we've implemented this function id to return
SMCCC_RET_NOT_SUPPORTED, 0, and SMCCC_RET_NOT_REQUIRED. One of those
isn't supposed to be there. Per the code we call
arm64_get_spectre_v2_state() to figure out what to return for this
feature discovery call.0 is SPECTRE_MITIGATED
SMCCC_RET_NOT_REQUIRED is SPECTRE_UNAFFECTED
SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLELet's clean this up so that KVM tells the guest this mapping:
0 is SPECTRE_MITIGATED
1 is SPECTRE_UNAFFECTED
SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLENote: SMCCC_RET_NOT_AFFECTED is 1 but isn't part of the SMCCC spec
Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests")
Signed-off-by: Stephen Boyd
Acked-by: Marc Zyngier
Acked-by: Will Deacon
Cc: Andre Przywara
Cc: Steven Price
Cc: Marc Zyngier
Cc: stable@vger.kernel.org
Link: https://developer.arm.com/documentation/den0028/latest [1]
Link: https://lore.kernel.org/r/20201023154751.1973872-1-swboyd@chromium.org
Signed-off-by: Will Deacon
16 Sep, 2020
2 commits
-
Using the same register-bound variable for both arguments and results
means these values share a type. That type must allow the arguments to
be assigned to it and must also be assignable to the unsigned long
fields of struct arm_smccc_res.This restriction on types causes compiler warnings when the argument
cannot be implicitly assigned to an unsigned long, for example the
pointers that are used in the KVM hyp interface.By separating the arguments and results into their own variables, the
type constraint is lifted allowing the arguments to avoid the need for
any type conversion.Signed-off-by: Andrew Scull
Signed-off-by: Marc Zyngier
Cc: Sudeep Holla
Link: https://lore.kernel.org/r/20200915104643.2543892-17-ascull@google.com -
Vendor specific hypervisor services have their own region of function
identifiers reserved by SMCCC. Extend the list of owners to include this
case.Signed-off-by: Andrew Scull
Signed-off-by: Marc Zyngier
Cc: Sudeep Holla
Link: https://lore.kernel.org/r/20200915104643.2543892-16-ascull@google.com
04 Aug, 2020
1 commit
-
Pull ARM SoC driver updates from Arnd Bergmann:
"A couple of subsystems have their own subsystem maintainers but choose
to have the code merged through the soc tree as upstream, as the code
tends to be used across multiple SoCs or has SoC specific drivers
itself:- memory controllers:
Krzysztof Kozlowski takes ownership of the drivers/memory subsystem
and its drivers, starting out with a set of cleanup patches.A larger driver for the Tegra memory controller that was
accidentally missed for v5.8 is now added.- reset controllers:
Only minor updates to drivers/reset this time
- firmware:
The "turris mox" firmware driver gains support for signed firmware
blobs The tegra firmware driver gets extended to export some debug
information Various updates to i.MX firmware drivers, mostly
cosmetic- ARM SCMI/SCPI:
A new mechanism for platform notifications is added, among a number
of minor changes.- optee:
Probing of the TEE bus is rewritten to better support detection of
devices that depend on the tee-supplicant user space. A new
firmware based trusted platform module (fTPM) driver is added based
on OP-TEE- SoC attributes:
A new driver is added to provide a generic soc_device for
identifying a machine through the SMCCC ARCH_SOC_ID firmware
interface rather than by probing SoC family specific registers.The series also contains some cleanups to the common soc_device
code.There are also a number of updates to SoC specific drivers, the main
ones are:- Mediatek cmdq driver gains a few in-kernel interfaces
- Minor updates to Qualcomm RPMh, socinfo, rpm drivers, mostly adding
support for additional SoC variants- The Qualcomm GENI core code gains interconnect path voting and
performance level support, and integrating this into a number of
device drivers.- A new driver for Samsung Exynos5800 voltage coupler for
- Renesas RZ/G2H (R8A774E1) SoC support gets added to a couple of SoC
specific device drivers- Updates to the TI K3 Ring Accelerator driver"
* tag 'arm-drivers-5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (164 commits)
soc: qcom: geni: Fix unused label warning
soc: qcom: smd-rpm: Fix kerneldoc
memory: jz4780_nemc: Only request IO memory the driver will use
soc: qcom: pdr: Reorder the PD state indication ack
MAINTAINERS: Add Git repository for memory controller drivers
memory: brcmstb_dpfe: Fix language typo
memory: samsung: exynos5422-dmc: Correct white space issues
memory: samsung: exynos-srom: Correct alignment
memory: pl172: Enclose macro argument usage in parenthesis
memory: of: Correct kerneldoc
memory: omap-gpmc: Fix language typo
memory: omap-gpmc: Correct white space issues
memory: omap-gpmc: Use 'unsigned int' for consistency
memory: omap-gpmc: Enclose macro argument usage in parenthesis
memory: omap-gpmc: Correct kerneldoc
memory: mvebu-devbus: Align with open parenthesis
memory: mvebu-devbus: Add missing braces to all arms of if statement
memory: bt1-l2-ctl: Add blank lines after declarations
soc: TI knav_qmss: make symbol 'knav_acc_range_ops' static
firmware: ti_sci: Replace HTTP links with HTTPS ones
...
07 Jul, 2020
1 commit
-
Move constants out of the C-only section of the header next to the other
constants that are available to assembly.Signed-off-by: Andrew Scull
Reviewed-by: Sudeep Holla
Acked-by: Will Deacon
Link: https://lore.kernel.org/r/20200618145511.69203-1-ascull@google.com
Signed-off-by: Catalin Marinas
06 Jul, 2020
1 commit
-
SMCCC v1.2 adds a new optional function SMCCC_ARCH_SOC_ID to obtain a
SiP defined SoC identification value. Add support for the same.Also using the SoC bus infrastructure, let us expose the platform
specific SoC atrributes under sysfs.There are various ways in which it can be represented in shortened form
for efficiency and ease of parsing for userspace. The chosen form is
described in the ABI document.Link: https://lore.kernel.org/r/20200625095939.50861-1-sudeep.holla@arm.com
Cc: Etienne Carriere
Reviewed-by: Steven Price
Signed-off-by: Sudeep Holla
21 May, 2020
4 commits
-
Commit f2ae97062a48 ("firmware: smccc: Refactor SMCCC specific bits into
separate file") introduced the following build warning:drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for
function 'arm_smccc_version_init' [-Wmissing-prototypes]
void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
^~~~~~~~~~~~~~~~~~~~~~Fix the same by adding the missing prototype in arm-smccc.h
Reported-by: kbuild test robot
Signed-off-by: Sudeep Holla
Link: https://lore.kernel.org/r/20200521110836.57252-1-sudeep.holla@arm.com
Signed-off-by: Will Deacon -
For backward compatibility reasons, PSCI maintains SMCCC version as
SMCCC didn't provide ARM_SMCCC_VERSION_FUNC_ID until v1.1.PSCI initialises both the SMCCC version and conduit. Similar to the
conduit, let us provide accessors to fetch the SMCCC version also so
that other SMCCC v1.1+ features can use it.Signed-off-by: Sudeep Holla
Tested-by: Etienne Carriere
Reviewed-by: Steven Price
Reviewed-by: Etienne Carriere
Acked-by: Mark Rutland
Link: https://lore.kernel.org/r/20200518091222.27467-7-sudeep.holla@arm.com
Signed-off-by: Will Deacon -
Add the definition for SMCCC v1.2 version and new error code added.
While at it, also add a note that ARM DEN 0070A is deprecated and is
now merged into the main SMCCC specification(ARM DEN 0028C).Signed-off-by: Sudeep Holla
Tested-by: Etienne Carriere
Reviewed-by: Steven Price
Reviewed-by: Etienne Carriere
Link: https://lore.kernel.org/r/20200518091222.27467-4-sudeep.holla@arm.com
Signed-off-by: Will Deacon -
The current link gets redirected to the revision B published in November
2016 though it actually points to the original revision A published in
June 2013.Let us update the link to point to the latest version, so that it
doesn't get stale anytime soon. Currently it points to v1.2 published in
March 2020(i.e. DEN0028C).Signed-off-by: Sudeep Holla
Tested-by: Etienne Carriere
Reviewed-by: Steven Price
Reviewed-by: Etienne Carriere
Acked-by: Mark Rutland
Link: https://lore.kernel.org/r/20200518091222.27467-3-sudeep.holla@arm.com
Signed-off-by: Will Deacon
22 Oct, 2019
2 commits
-
SMCCC 1.1 calls may use either HVC or SMC depending on the PSCI
conduit. Rather than coding this in every call site, provide a macro
which uses the correct instruction. The macro also handles the case
where no conduit is configured/available returning a not supported error
in res, along with returning the conduit used for the call.This allow us to remove some duplicated code and will be useful later
when adding paravirtualized time hypervisor calls.Signed-off-by: Steven Price
Acked-by: Will Deacon
Signed-off-by: Marc Zyngier -
This provides a mechanism for querying which paravirtualized time
features are available in this hypervisor.Also add the header file which defines the ABI for the paravirtualized
time features we're about to add.Signed-off-by: Steven Price
Signed-off-by: Marc Zyngier
14 Oct, 2019
1 commit
-
SMCCC callers are currently amassing a collection of enums for the SMCCC
conduit, and are having to dig into the PSCI driver's internals in order
to figure out what to do.Let's clean this up, with common SMCCC_CONDUIT_* definitions, and an
arm_smccc_1_1_get_conduit() helper that abstracts the PSCI driver's
internal state.We can kill off the PSCI_CONDUIT_* definitions once we've migrated users
over to the new interface.Signed-off-by: Mark Rutland
Acked-by: Lorenzo Pieralisi
Acked-by: Will Deacon
Signed-off-by: Catalin Marinas
05 Jun, 2019
1 commit
-
Based on 1 normalized pattern(s):
this software is licensed under the terms of the gnu general public
license version 2 as published by the free software foundation and
may be copied distributed and modified under those terms this
program is distributed in the hope that it will be useful but
without any warranty without even the implied warranty of
merchantability or fitness for a particular purpose see the gnu
general public license for more detailsextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 285 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Alexios Zavras
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141900.642774971@linutronix.de
Signed-off-by: Greg Kroah-Hartman
30 Aug, 2018
1 commit
-
If someone has the silly idea to write something along those lines:
extern u64 foo(void);
void bar(struct arm_smccc_res *res)
{
arm_smccc_1_1_smc(0xbad, foo(), res);
}they are in for a surprise, as this gets compiled as:
0000000000000588 :
588: a9be7bfd stp x29, x30, [sp, #-32]!
58c: 910003fd mov x29, sp
590: f9000bf3 str x19, [sp, #16]
594: aa0003f3 mov x19, x0
598: aa1e03e0 mov x0, x30
59c: 94000000 bl 0
5a0: 94000000 bl 0
5a4: aa0003e1 mov x1, x0
5a8: d4000003 smc #0x0
5ac: b4000073 cbz x19, 5b8
5b0: a9000660 stp x0, x1, [x19]
5b4: a9010e62 stp x2, x3, [x19, #16]
5b8: f9400bf3 ldr x19, [sp, #16]
5bc: a8c27bfd ldp x29, x30, [sp], #32
5c0: d65f03c0 ret
5c4: d503201f nopThe call to foo "overwrites" the x0 register for the return value,
and we end up calling the wrong secure service.A solution is to evaluate all the parameters before assigning
anything to specific registers, leading to the expected result:0000000000000588 :
588: a9be7bfd stp x29, x30, [sp, #-32]!
58c: 910003fd mov x29, sp
590: f9000bf3 str x19, [sp, #16]
594: aa0003f3 mov x19, x0
598: aa1e03e0 mov x0, x30
59c: 94000000 bl 0
5a0: 94000000 bl 0
5a4: aa0003e1 mov x1, x0
5a8: d28175a0 mov x0, #0xbad
5ac: d4000003 smc #0x0
5b0: b4000073 cbz x19, 5bc
5b4: a9000660 stp x0, x1, [x19]
5b8: a9010e62 stp x2, x3, [x19, #16]
5bc: f9400bf3 ldr x19, [sp, #16]
5c0: a8c27bfd ldp x29, x30, [sp], #32
5c4: d65f03c0 retReported-by: Julien Grall
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
29 Aug, 2018
1 commit
-
An unfortunate consequence of having a strong typing for the input
values to the SMC call is that it also affects the type of the
return values, limiting r0 to 32 bits and r{1,2,3} to whatever
was passed as an input.Let's turn everything into "unsigned long", which satisfies the
requirements of both architectures, and allows for the full
range of return values.Reported-by: Julien Grall
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
01 Jun, 2018
2 commits
-
In order for the kernel to protect itself, let's call the SSBD mitigation
implemented by the higher exception level (either hypervisor or firmware)
on each transition between userspace and kernel.We must take the PSCI conduit into account in order to target the
right exception level, hence the introduction of a runtime patching
callback.Reviewed-by: Mark Rutland
Reviewed-by: Julien Grall
Acked-by: Will Deacon
Signed-off-by: Marc Zyngier
Signed-off-by: Catalin Marinas -
We've so far used the PSCI return codes for SMCCC because they
were extremely similar. But with the new ARM DEN 0070A specification,
"NOT_REQUIRED" (-2) is clashing with PSCI's "PSCI_RET_INVALID_PARAMS".Let's bite the bullet and add SMCCC specific return codes. Users
can be repainted as and when required.Acked-by: Will Deacon
Reviewed-by: Mark Rutland
Signed-off-by: Marc Zyngier
Signed-off-by: Catalin Marinas
07 Feb, 2018
4 commits
-
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 by SMCCC v1.0.Reviewed-by: Robin Murphy
Tested-by: Ard Biesheuvel
Signed-off-by: Marc Zyngier
Signed-off-by: Catalin Marinas -
Function identifiers are a 32bit, unsigned quantity. But we never
tell so to the compiler, resulting in the following:4ac: b26187e0 mov x0, #0xffffffff80000001
We thus rely on the firmware narrowing it for us, which is not
always a reasonable expectation.Cc: stable@vger.kernel.org
Reported-by: Ard Biesheuvel
Acked-by: Ard Biesheuvel
Reviewed-by: Robin Murphy
Tested-by: Ard Biesheuvel
Signed-off-by: Marc Zyngier
Signed-off-by: Catalin Marinas -
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 every guest exit.Tested-by: Ard Biesheuvel
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Catalin Marinas -
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
Signed-off-by: Catalin Marinas
08 Feb, 2017
1 commit
-
Commit 680a0873e193 ("arm: kernel: Add SMC structure parameter") added
a new "quirk" parameter to the SMC and HVC SMCCC backends, but only
updated the comment for the SMC version. This patch adds the new
paramater to the comment describing the HVC version too.Signed-off-by: Will Deacon
04 Feb, 2017
2 commits
-
This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.
On Qualcomm ARM64 platforms, the SMC call can return before it has
completed. If this occurs, the call can be restarted, but it requires
using the returned session ID value from the interrupted SMC call.The quirk stores off the session ID from the interrupted call in the
quirk structure so that it can be used by the caller.This patch folds in a fix given by Sricharan R:
https://lkml.org/lkml/2016/9/28/272Signed-off-by: Andy Gross
Reviewed-by: Will Deacon
Signed-off-by: Will Deacon -
This patch adds a quirk parameter to the arm_smccc_(smc/hvc) calls.
The quirk structure allows for specialized SMC operations due to SoC
specific requirements. The current arm_smccc_(smc/hvc) is renamed and
macros are used instead to specify the standard arm_smccc_(smc/hvc) or
the arm_smccc_(smc/hvc)_quirk function.This patch and partial implementation was suggested by Will Deacon.
Signed-off-by: Andy Gross
Reviewed-by: Will Deacon
Signed-off-by: Will Deacon
05 Jan, 2016
1 commit
-
Adds helpers to do SMC and HVC based on ARM SMC Calling Convention.
CONFIG_HAVE_ARM_SMCCC is enabled for architectures that may support the
SMC or HVC instruction. It's the responsibility of the caller to know if
the SMC instruction is supported by the platform.This patch doesn't provide an implementation of the declared functions.
Later patches will bring in implementations and set
CONFIG_HAVE_ARM_SMCCC for ARM and ARM64 respectively.Reviewed-by: Lorenzo Pieralisi
Signed-off-by: Jens Wiklander
Signed-off-by: Russell King
