| Message ID | 1472706282-6772-3-git-send-email-madans@ti.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
On Thu, Sep 01, 2016 at 01:04:37AM -0400, Madan Srinivas wrote: > From: Vitaly Andrianov <vitalya@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@ti.com> > Signed-off-by: Madan Srinivas <madans@ti.com> > > Cc: Lokesh Vutla <lokeshvutla@ti.com> > Cc: Dan Murphy <dmurphy@ti.com> First, what is done to ensure that the magic blob we're offloading to isn't 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 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!
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@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@ti.com> >> Signed-off-by: Madan Srinivas <madans@ti.com> >> >> Cc: Lokesh Vutla <lokeshvutla@ti.com> >> Cc: Dan Murphy <dmurphy@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
diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c index 256f630..6b79077 100644 --- a/arch/arm/mach-keystone/mon.c +++ b/arch/arm/mach-keystone/mon.c @@ -12,10 +12,31 @@ #include <mach/mon.h> asm(".arch_extension sec\n\t"); +#ifdef CONFIG_TI_SECURE_DEVICE +#define KS2_HS_AUTH_FN_OFFSET 8 +#define KS2_HS_SEC_HEADER_LEN 0x60 +#define KS2_AUTH_CMD "2" +/** + * (*fn_auth)() - Invokes security functions using a + * proprietary TI interface. This binary and source for + * this is available in the secure development package or + * SECDEV. For details on how to access this please refer + * doc/README.ti-secure + * + * @first param: no. of parameters + * @second param: parameter list + * @return non-zero value on success, zero on error + */ +static unsigned int (*fn_auth)(int, char * const []); +#endif + int mon_install(u32 addr, u32 dpsc, u32 freq) { int result; +#ifdef CONFIG_TI_SECURE_DEVICE + fn_auth = (void *)(addr + KS2_HS_AUTH_FN_OFFSET); +#endif __asm__ __volatile__ ( "stmfd r13!, {lr}\n" "mov r0, %1\n" @@ -61,3 +82,37 @@ int mon_power_off(int core_id) : "cc", "r0", "r1", "memory"); return result; } + +#ifdef CONFIG_TI_SECURE_DEVICE +static void k2_hs_auth(void *addr) +{ + char *argv1 = KS2_AUTH_CMD; + char argv2[32]; + char *argv[3] = {NULL, argv1, argv2}; + int ret = 0; + + sprintf(argv2, "0x%08x", (u32)addr); + + if (fn_auth) + ret = fn_auth(3, argv); + + if (ret == 0) + hang(); +} + +void board_fit_image_post_process(void **p_image, size_t *p_size) +{ + void *dst = *p_image; + void *src = dst + KS2_HS_SEC_HEADER_LEN; + + k2_hs_auth(*p_image); + + /* + * Overwrite the image headers after authentication + * and decryption. Update size to relect removal + * of header. + */ + *p_size -= KS2_HS_SEC_HEADER_LEN; + memcpy(dst, src, *p_size); +} +#endif