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]

Date:   Tue, 19 Nov 2019 13:20:14 -0500
From:   "Andrew F. Davis" <afd@...com>
To:     Tony Lindgren <tony@...mide.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

On 11/19/19 1:05 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony@...mide.com> [191119 16:43]:
>> What I'd like to have though is to make arm_smccc_smc()
>> work for optee and non-optee case for mach-omap2 as it
>> already has the features necessary to do the runtime
>> patching of the code for the quirks.
> 
> In any case sounds like we only need the r12 quirk when
> optee is _not_ enabled.
> 
> So a modified version of your earlier smccc-call.S patch
> modified to only enable the r12 quirk when no optee is
> loaded just might be all we need :)
> 

Doesn't change the reason the earlier patch was NAKd, we would still be
modifying the core SMCCC call to be non-compliant.

And doing it only when OP-TEE is not installed doesn't gain us anything,
we already have our own SMC calls for when OP-TEE is not available, this
patch is specifically so the OMAP2+ boot still works even when OP-TEE is
installed.

If you can get Mark to take my old patch then we can think about moving
more legacy SMC callers to the SMCCC, otherwise this patch is what we
need to get OP-TEE enabled OMAP2+ platforms to boot and we will just
stick to the custom SMC functions we already have for everything else.

Andrew

> Regards,
> 
> Tony
>