linux-stable.git/include/linux, branch v4.4.201

arm/arm64: smccc-1.1: Handle function result as parameters

2019-11-10T10:21:22+00:00

[ Upstream commit 755a8bf5579d22eb5636685c516d8dede799e27b ]

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 <_mcount>
	 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        nop

The 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 <_mcount>
	 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        ret

Reported-by: Julien Grall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: smccc-1.1: Make return values unsigned long

2019-11-10T10:21:21+00:00

[ Upstream commit 1d8f574708a3fb6f18c85486d0c5217df893c0cf ]

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 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: smccc: Add SMCCC-specific return codes

2019-11-10T10:21:21+00:00

commit eff0e9e1078ea7dc1d794dc50e31baef984c46d7 upstream.

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 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: smccc: Implement SMCCC v1.1 inline primitive

2019-11-10T10:21:20+00:00

commit f2d3b2e8759a5833df6f022e42df2d581e6d843c upstream.

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 
Signed-off-by: Mark Rutland  [v4.9 backport]
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: smccc: Make function identifiers an unsigned quantity

2019-11-10T10:21:20+00:00

commit ded4c39e93f3b72968fdb79baba27f3b83dad34c upstream.

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 
Signed-off-by: Mark Rutland  [v4.9 backport]
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

firmware/psci: Expose SMCCC version through psci_ops

2019-11-10T10:21:19+00:00

commit e78eef554a912ef6c1e0bbf97619dafbeae3339f upstream.

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 
Signed-off-by: Catalin Marinas 
Signed-off-by: Mark Rutland  [v4.9 backport]
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

firmware/psci: Expose PSCI conduit

2019-11-10T10:21:19+00:00

commit 09a8d6d48499f93e2abde691f5800081cd858726 upstream.

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 
Signed-off-by: Catalin Marinas 
Signed-off-by: Mark Rutland  [v4.9 backport]
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support

2019-11-10T10:21:18+00:00

commit 6167ec5c9145cdf493722dfd80a5d48bafc4a18a upstream.

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 
[v4.9: account for files moved to virt/ upstream]
Signed-off-by: Mark Rutland  [v4.9 backport]
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman 
[ardb: restrict to include/linux/arm-smccc.h]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

arm/arm64: KVM: Advertise SMCCC v1.1

2019-11-10T10:21:18+00:00

commit 09e6be12effdb33bf7210c8867bbd213b66a499e upstream.

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 
[v4.9: account for files moved to virt/ upstream]
Signed-off-by: Mark Rutland  [v4.9 backport]
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman 
[ardb: restrict to include/linux/arm-smccc.h, drop KVM bits]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

ARM: 8478/2: arm/arm64: add arm-smccc

2019-11-10T10:21:15+00:00

Commit 98dd64f34f47ce19b388d9015f767f48393a81eb upstream.

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 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman