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 <vita...@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 <vita...@ti.com>
Signed-off-by: Madan Srinivas <mad...@ti.com>
Cc: Lokesh Vutla <lokeshvu...@ti.com>
Cc: Dan Murphy <dmur...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
