[U-Boot] [PATCH 1/5] ti: omap5: Add Kconfig options for secure EMIF reservations

Allred, Daniel
2016-09-07T04:17:28Z

On 9/6/2016 3:23 PM, Andrew F. Davis wrote:
> On 09/02/2016 12:40 AM, Daniel Allred wrote:
>> Adds start address and size config options for setting aside
>> a portion of the EMIF memory space for usage by security software
>> (like a secure OS/TEE). There are two sizes, a total size and a
>> protected size. The region is divided into protected (secure) and
>> unprotected (public) regions, that are contiguous and start at the
>> start address given. If the start address is zero, the intention
>> is that the region will be automatically placed at the end of the
>> available external DRAM space.
>>
>> Signed-off-by: Daniel Allred <d-allred@ti.com>
>> ---
>> arch/arm/cpu/armv7/omap5/Kconfig | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv7/omap5/Kconfig b/arch/arm/cpu/armv7/omap5/Kconfig
>> index a8600b1..25474ed 100644
>> --- a/arch/arm/cpu/armv7/omap5/Kconfig
>> +++ b/arch/arm/cpu/armv7/omap5/Kconfig
>> @@ -24,6 +24,32 @@ endchoice
>> config SYS_SOC
>> default "omap5"
>>
>> +config TI_SECURE_EMIF_REGION_START
>> + hex "Reserved EMIF region start address"
>> + depends on TI_SECURE_DEVICE
>> + default 0x0
>> + help
>> + Reserved EMIF region start address. Set to "0" to auto-select
>> + to be at the end of the external memory region.
>
> The secure image that is placed in this location (OPTEE OS for now) will
> probably not be relocatable, what happens when we add RAM to a board
> (some boards take regular ram sticks), will our secure world suddenly
> break? What do we gain from having the location auto-selected?
See the answer I provided to the other patch about PRAM. Auto-selection isn't the key, but putting it at the end out of the way of all potential conflicts is. If the secure OS/TEE is not PIC, then re-linking will be required if the RAM size changes. But I personally see a change in RAM size as a new platform/board, so I don't think rebuilding some of the SW for that platform is completely unreasonable. Ultimately, it will depend on the secure OS/TEE.
>
>> +
>> +config TI_SECURE_EMIF_TOTAL_REGION_SIZE
>
> Instead of having the total combined size of both the protected and
> non-protected secure region then subtracting out the protected below to
> get the non-protected, why not have:
>
> TI_SECURE_EMIF_PUBLIC_REGION_SIZE
> TI_SECURE_EMIF_PROTECTED_REGION_SIZE
>
> then add the two to get the total region size? This would also remove
> some checks to make sure the total isn't smaller than one part, plus it
> removes the need for any mental math in figuring the size of the public
> region.
We had it this way previously, but the code ended up more complicated (though maybe the preprocessor checks were simpler). Having seen it both ways, I think it is a wash.

Daniel
>
>> + hex "Reserved EMIF region size"
>> + depends on TI_SECURE_DEVICE
>> + default 0x0
>> + help
>> + Total reserved EMIF region size. Default is 0, which means no reserved EMIF
>> + region on secure devices.
>> +
>> +config TI_SECURE_EMIF_PROTECTED_REGION_SIZE
>> + hex "Size of protected region within reserved EMIF region"
>> + depends on TI_SECURE_DEVICE
>> + default 0x0
>> + help
>> + This config option is used to specify the size of the portion of the total
>> + reserved EMIF region set aside for secure OS needs that will be protected
>> + using hardware memory firewalls. This value must be smaller than the
>> + TI_SECURE_EMIF_TOTAL_REGION_SIZE value.
>> +
>> source "board/compulab/cm_t54/Kconfig"
>> source "board/ti/omap5_uevm/Kconfig"
>> source "board/ti/dra7xx/Kconfig"
>>