linux-kernel - Re: [PATCH] ARM: OMAP: Use ARM SMC Calling Convention when OP-TEE is available

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191119194425.GQ35479@atomide.com>
Date:   Tue, 19 Nov 2019 11:44:25 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     "Andrew F. Davis" <afd@...com>
Cc:     Mark Rutland <mark.rutland@....com>, linux-omap@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: OMAP: Use ARM SMC Calling Convention when OP-TEE is
 available

* Andrew F. Davis <afd@...com> [191119 19:36]:
> On 11/19/19 2:20 PM, Tony Lindgren wrote:
> > * Andrew F. Davis <afd@...com> [191119 19:13]:
> >> On 11/19/19 2:07 PM, Tony Lindgren wrote:
> >>> * Andrew F. Davis <afd@...com> [191119 18:51]:
> >>>> On 11/19/19 1:32 PM, Tony Lindgren wrote:
> >>>>> It would allow us to completely change over to using
> >>>>> arm_smccc_smc() and forget the custom calls.
> >>>>
> >>>> We would need more than just the r12 quirk to replace all our custom SMC
> >>>> handlers, we would need quirks for omap_smc2 which puts process ID in r1
> >>>> and puts #0xff in r6, and omap_smc3 that uses smc #1. All of our legacy
> >>>> SMC calls also trash r4-r11, that is very non SMCCC complaint as only
> >>>> r4-r7 need be caller saved. I don't see arm_smccc_smc() working with
> >>>> legacy ROM no matter how much we hack at it :(
> >>>
> >>> We would just have omap_smc2() call arm_smccc_smc() and in that
> >>> case. And omap_smc2() would still deal with saving and restoring
> >>> the registers.
> >>
> >> Then why call arm_smccc_smc()? omap_smc2() is already an assembly
> >> function, all it needs to do after loading the registers and saving the
> >> right ones is issue an "smc #0" instruction, why would we want to
> >> instead call into some other function to re-save registers and issue the
> >> exact same instruction?
> > 
> > To use Linux generic API for smc calls where possible.
> 
> But we are not using generic API calls, we are using omap_smcx() which
> cannot call into arm_smccc_smc(). For all the above reasons plus
> arm_smccc_smc() uses r12 to save the stack pointer, our ROM expects r12
> to store the function ID.

Saving and restoring r12 could be handled by the arm_smccc_smc() quirk
for the non-optee case.

Then we could get rid of omap_smc1() and arm_smccc_smc() should work
for the optee case and non-optee case, right.

> >>> Certainly the wrapper functions calling arm_smccc_smc() can deal
> >>> with r12 too if the r12-quirk version and the plain version are
> >>> never needed the same time on a booted SoC.
> >>>
> >>> Are they ever needed the same time on a booted SoC or not?

> They should not be needed at the same time, either OP-TEE is on the
> secure side or ROM is there.

OK thanks. So we could just modify the code dynamically on boot
based on if optee is found or not. The quirk could be done along
the lines of the qcom quirk but only for the non-optee case:

$ git grep -C10 ARM_SMCCC_QUIRK_QCOM_A6

Regards,

Tony