Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

From: Robin Murphy
Date: Tue Mar 27 2018 - 07:55:08 EST


On 26/03/18 22:20, Dmitry Osipenko wrote:
On 25.03.2018 21:09, Stefan Agner wrote:
As documented in GCC naked functions should only use Basic asm
syntax. The Extended asm or mixture of Basic asm and "C" code is
not guaranteed. Currently this works because it was hard coded
to follow and check GCC behavior for arguments and register
placement.

Furthermore with clang using parameters in Extended asm in a
naked function is not supported:
arch/arm/firmware/trusted_foundations.c:47:10: error: parameter
references not allowed in naked functions
: "r" (type), "r" (arg1), "r" (arg2)
^

Use a regular function to be more portable. This aligns also with
the other smc call implementations e.g. in qcom_scm-32.c and
bcm_kona_smc.c.

Cc: Dmitry Osipenko <digetx@xxxxxxxxx>
Cc: Stephen Warren <swarren@xxxxxxxxxx>
Cc: Thierry Reding <treding@xxxxxxxxxx>
Signed-off-by: Stefan Agner <stefan@xxxxxxxx>
---
Changes in v2:
- Keep stmfd/ldmfd to avoid potential ABI issues

arch/arm/firmware/trusted_foundations.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/firmware/trusted_foundations.c b/arch/arm/firmware/trusted_foundations.c
index 3fb1b5a1dce9..689e6565abfc 100644
--- a/arch/arm/firmware/trusted_foundations.c
+++ b/arch/arm/firmware/trusted_foundations.c
@@ -31,21 +31,25 @@
static unsigned long cpu_boot_addr;
-static void __naked tf_generic_smc(u32 type, u32 arg1, u32 arg2)
+static void tf_generic_smc(u32 type, u32 arg1, u32 arg2)
{
+ register u32 r0 asm("r0") = type;
+ register u32 r1 asm("r1") = arg1;
+ register u32 r2 asm("r2") = arg2;
+
asm volatile(
".arch_extension sec\n\t"
- "stmfd sp!, {r4 - r11, lr}\n\t"
+ "stmfd sp!, {r4 - r11}\n\t"
__asmeq("%0", "r0")
__asmeq("%1", "r1")
__asmeq("%2", "r2")
"mov r3, #0\n\t"
"mov r4, #0\n\t"
"smc #0\n\t"
- "ldmfd sp!, {r4 - r11, pc}"
+ "ldmfd sp!, {r4 - r11}\n\t"
:
- : "r" (type), "r" (arg1), "r" (arg2)
- : "memory");
+ : "r" (r0), "r" (r1), "r" (r2)
+ : "memory", "r3", "r12", "lr");

Although seems "lr" won't be affected by SMC invocation because it should be
banked and hence could be omitted entirely from the code. Maybe somebody could
confirm this.
Strictly per the letter of the architecture, the SMC could be trapped to Hyp mode, and a hypervisor might clobber LR_usr in the process of forwarding the call to the firmware secure monitor (since Hyp doesn't have a banked LR of its own). Admittedly there are probably no real systems with the appropriate hardware/software combination to hit that, but on the other hand if this gets inlined where the compiler has already created a stack frame then an LR clobber is essentially free, so I reckon we're better off keeping it for reassurance. This isn't exactly a critical fast path anyway.

Robin.