[U-Boot] [PATCH] ARM: tegra: restrict usable RAM size further

[Simon Glass]

Hi Stephen,

On 30 July 2015 at 12:47, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 07/30/2015 09:52 AM, Simon Glass wrote:
>>
>> Hi,
>>
>> On 30 July 2015 at 09:43, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>
>>>
>>> On 07/30/2015 05:04 AM, Thierry Reding wrote:
>>>>
>>>>
>>>> On Wed, Jul 29, 2015 at 01:47:58PM -0600, Stephen Warren wrote:
>>>>>
>>>>>
>>>>> From: Stephen Warren <swarren at nvidia.com>
>>>>>
>>>>> Additionally, ARM64 devices typically run a secure monitor in EL3 and
>>>>> U-Boot in EL2, and set up some secure RAM carve-outs to contain the EL3
>>>>> code and data. These carve-outs are located at the top of 32-bit
>>>>> address
>>>>> space. Restrict U-Boot's RAM usage to well below the location of those
>>>>> carve-outs. Ideally, we would the secure monitor would inform U-Boot of
>>>>> exactly which RAM it could use at run-time. However, I'm not sure how
>>>>> to
>>>>> do that at present (and even if such a mechanism does exist, it would
>>>>> likely not be generic across all forms of secure monitor).
>>>>
>>>>
>>>>
>>>> 0xe0000000-0xffffffff is 512 MiB, surely a secure monitor can live with
>>>> less than that!
>>>
>>>
>>>
>>> I'm sure it does. However, it's a nice round number and leaves plenty of
>>> space for arbitrary expansion of the secure monitor, secure OS, other
>>> security-related carve-outs, (video regions, LP0 resume firmware, etc.)
>>> There's still plenty of space left for U-Boot after that.
>>
>>
>> I'd really hope that these can be in U-Boot's remit. except perhaps
>> the secure OS. Should we figure out how to build the secure monitor
>> within the U-Boot environment? Is creating a bootable image going to
>> become really complicated? Why would video regions and resume firmware
>> not be set up by U-Boot?
>
>
> The secure OS may (depending on exactly which applications it hosts I guess)
> use some of these regions itself. So, everything needs to be set up before
> the secure OS runs IIUC.
>
> I can imagine a secure OS wanting to do display output (e.g. in an overlay
> plane at least). The same goes for pretty much any feature of the system
> really; it's up to the SW stack builder to decide which functions to
> partition into their secure vs non-secure SW.
>
> The system should be able to suspend/resume under the control of the secure
> OS (taking requests from whatever non-secure SW stack may be running and
> interacting with the user, or autonomously if more system level control is
> implemented in the secure OS). Hence, all the system level SW needs to be
> set up early.
>
> At least initially, we're targeting booting the system with the same
> bootloader that L4T and Android use for unification. U-Boot runs after the
> base security/... environment is set up to provide a flexible user
> experience for untrusted OS loading. Hopefully this won't make flashing a
> system too much more complex, but there will inevitably be some differences.
> Hopefully it'll get mostly hidden by tegra-uboot-flasher or some other tool.
>
> At some point I hope we'll be able to get U-Boot to act as the first stage
> bootloader rather than just the non-secure bootloader. However, that
> requires a lot more work so certainly isn't something that's in the first
> round of Tegra210 support.

Thanks for the explanation. Booting ARM devices might get as hard as
x86 if we try really hard. Maybe we can add some run-time services as
well...good luck!

Regards,
Simon