[U-Boot] [PATCH v2 2/7] arm: mach-keystone: Implements FIT post-processing call for keystone SoCs

[Srinivas, Madan]

On 9/6/2016 9:34 AM, Tom Rini wrote:
> On Thu, Sep 01, 2016 at 01:04:37AM -0400, Madan Srinivas wrote:
>
>> From: Vitaly Andrianov <vitalya at ti.com>
>>
>> This commit implements the board_fit_image_post_process() function for
>> the keystone architecture. Unlike OMAP class devices, security
>> functions in keystone are not handled in the ROM.
>> The interface to the secure functions is TI proprietary and depending
>> on the keystone platform, the security functions like encryption,
>> decryption and authentication might even be offloaded to other secure
>> processing elements in the SoC.
>> The boot monitor acts as the gateway to these secure functions and the
>> boot monitor for secure devices is available as part of the SECDEV
>> package for KS2. For more details refer doc/README.ti-secure
>>
>> Signed-off-by: Vitaly Andrianov <vitalya at ti.com>
>> Signed-off-by: Madan Srinivas <madans at ti.com>
>>
>> Cc: Lokesh Vutla <lokeshvutla at ti.com>
>> Cc: Dan Murphy <dmurphy at ti.com>
>
> First, what is done to ensure that the magic blob we're offloading to
> isn't malicious?
The magic blob is signed and authenticated as part of the boot flow to 
ensure that it is not malicious.
> Second, this appears to be missing cache flushes
> that're done in arch/arm/cpu/armv7/omap-common/sec-common.c and, well,
> why can't we re-use the existing code?  Given how rarely IP blocks are
> written from scratch rather than being an evolution of a previous block
Valid point Tom, but this case is the exception to that rule - the 
Keystone and the OMAP ROMs were developed independently, the keystone 
ROMs were based on DSP ROMs, not on OMAP, and therefore the code 
omap-common/in sec-common.c cannot be reused at all for keystone - the 
calling conventions, parameters APIs are all different.
> I can't imagine that we can't make the code there be re-used nor that we
> don't need / couldn't use the flushing and alignment checks nor status
> messages.  Thanks!
>
Unlike OMAP, in keystone2 for eg, the authentication is also done by 
DSP, so the code in sec-common.c cannot be reused at all. Even if K2 ROM 
APIs are used, the calling conventions are different. Also, unlike OMAP, 
the boot monitor has a secure and non-secure component (everything gets 
authenticated).

Again in OMAP the authentication is always done using only ROM APIs, 
whereas in keystone the authentication and decryption can be done using 
ROM, Secure ARM libraries or Secure DSP libraries. Using the current 
scheme, this can be achieved simply by selecting a different boot 
monitor binary to include in the signing step, the same u-boot binary 
will work for all three authentication schemes.

Regards,
Madan