From mboxrd@z Thu Jan 1 00:00:00 1970 From: Srinivas, Madan Date: Thu, 8 Sep 2016 11:29:56 -0400 Subject: [U-Boot] [PATCH v2 2/7] arm: mach-keystone: Implements FIT post-processing call for keystone SoCs In-Reply-To: <20160906133449.GJ4990@bill-the-cat> References: <1472706282-6772-1-git-send-email-madans@ti.com> <1472706282-6772-3-git-send-email-madans@ti.com> <20160906133449.GJ4990@bill-the-cat> Message-ID: <57D183F4.9040401@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >> >> 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 >> Signed-off-by: Madan Srinivas >> >> Cc: Lokesh Vutla >> Cc: Dan Murphy > > 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