Hi Trent,
-----Original Message----- From: Trent Piepho tpiepho@impinj.com Sent: Monday, July 16, 2018 10:33 AM To: Henry Beberman Henry.Beberman@microsoft.com; u- boot@lists.denx.de Cc: fabio.estevam@nxp.com Subject: Re: [U-Boot] [PATCH 04/11] spl: imx: Add optional lds to keep SPL entirely in on-chip RAM
On Sat, 2018-07-14 at 00:11 +0000, Henry Beberman wrote:
From: Henry Beberman henry.beberman@microsoft.com
This patch is part of the i.MX Windows 10 IoT Core boot flow.
It adds a modified linker script for SPL to keep all segments in on-chip ram. This is to harden the device against potential leaks of device secrets by keeping them out of DRAM.
Additionally if CONFIG_SYS_SPL_MALLOC_START is defined, it will override the CONFIG_SPL_SYS_MALLOC_SIMPLE and allocate space in
DRAM
instead of on-chip ram. This patch prevents the definition of those values for i.MX6 and i.MX7 SPL if CONFIG_OPTEE_SPL_BOOT is selected.
Is booting SPL from entirely from SRAM only useful in concert with OPTEE?
For instance, if I'm building a device that doesn't use OPTEE and yet want it to be secure, would I want to keep the SPL entirely in SRAM?
We're adding this in anticipation of implementing the Trusted Computing Group's Device Identifier Composition Engine (DICE). The reason we're adding it now is to ensure that the SPL we're building fits within the size limitations imposed by SRAM.
The switch to SRAM is primarily to protect the Unique Device Secret (UDS), which is a device specific identifier that must only be readable by DICE. The UDS must not be visible in DRAM at any point. You can find more information on the DICE requirements in the "Hardware Requirements for a Device Identifier Composition Engine" specification. (https://trustedcomputinggroup.org/resource/hardware-requirements-for-a-devic...)
There's value in other devices keeping SPL entirely in SDRAM as an additional layer of security, but it’s a tradeoff against image size and stack/malloc space.
Thanks, Henry