Files
linux/include/linux
Marc Zyngier 755a8bf557 arm/arm64: smccc-1.1: Handle function result as parameters
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 <bar>:
	 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 <foo>
	 5a4:   aa0003e1        mov     x1, x0
	 5a8:   d4000003        smc     #0x0
	 5ac:   b4000073        cbz     x19, 5b8 <bar+0x30>
	 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 <bar>:
	 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 <foo>
	 5a4:   aa0003e1        mov     x1, x0
	 5a8:   d28175a0        mov     x0, #0xbad
	 5ac:   d4000003        smc     #0x0
	 5b0:   b4000073        cbz     x19, 5bc <bar+0x34>
	 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 <julien.grall@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-08-30 14:18:03 +01:00
..
2018-07-15 13:55:44 +02:00
2018-08-09 14:05:30 -07:00
2018-05-26 09:16:44 +02:00
2018-06-15 18:10:01 -03:00
2018-07-24 14:43:26 -06:00
2018-06-15 18:10:01 -03:00
2018-06-19 10:06:29 -07:00
2018-06-19 10:06:29 -07:00
2018-08-22 10:52:48 -07:00
2018-07-22 14:13:43 +02:00
2018-06-01 07:38:16 -06:00
2018-07-24 19:11:26 +02:00
2018-07-12 10:04:29 -04:00
2018-07-27 09:57:23 +10:00
2018-06-28 20:32:51 +09:00
2018-06-07 17:34:37 -07:00
2018-08-08 11:06:20 +02:00
2018-06-22 13:43:27 +09:00
2018-06-21 12:33:21 +02:00
2018-07-12 21:35:28 +02:00
2018-06-05 08:50:16 -04:00
2018-06-07 17:34:35 -07:00
2018-06-07 17:34:39 -07:00
2018-08-22 10:52:45 -07:00
2018-07-10 17:22:35 +02:00
2018-06-07 17:34:36 -07:00
2018-08-15 14:59:03 -05:00
2018-07-19 11:34:23 +01:00
2018-06-07 17:34:35 -07:00
2018-07-25 13:41:22 -07:00
2018-07-21 10:43:12 -05:00
2018-08-22 10:52:46 -07:00
2018-05-31 00:13:56 +08:00
2018-07-20 01:11:45 +02:00
2018-08-02 17:33:06 -04:00
2018-08-02 17:16:05 +02:00
2018-06-29 08:48:06 -06:00
2018-06-07 17:34:35 -07:00
2018-07-07 17:25:23 +02:00
2018-07-03 09:20:44 +02:00
2018-08-16 12:14:42 -07:00
2018-06-20 11:35:56 +02:00