| Message ID | 1438199278-29247-1-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Accepted |
| Delegated to: | Tom Warren |
| Headers | show |
On Wed, Jul 29, 2015 at 01:47:58PM -0600, Stephen Warren wrote: > From: Stephen Warren <swarren@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! Thierry ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
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@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.
Hi, On 30 July 2015 at 09:43, Stephen Warren <swarren@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@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? Regards, Simon
On 07/30/2015 09:52 AM, Simon Glass wrote: > Hi, > > On 30 July 2015 at 09:43, Stephen Warren <swarren@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@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.
Hi Stephen, On 30 July 2015 at 12:47, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/30/2015 09:52 AM, Simon Glass wrote: >> >> Hi, >> >> On 30 July 2015 at 09:43, Stephen Warren <swarren@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@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
On 07/30/2015 01:00 PM, Simon Glass wrote: > Hi Stephen, > > On 30 July 2015 at 12:47, Stephen Warren <swarren@wwwdotorg.org> wrote: ... >> 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! Well, at least PSCI is required by the ARM64 kernel now I believe, and there's plenty of push for ACPI in some environments too, so I expect the complexity will indeed converge!
On 07/29/2015 01:47 PM, Stephen Warren wrote: > From: Stephen Warren <swarren@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). TomW, what are your thoughts on applying this given the discussion thread? Thanks.
On 08/05/2015 01:22 PM, Tom Warren wrote: >> -----Original Message----- >> From: Stephen Warren [mailto:swarren@wwwdotorg.org] >> Sent: Wednesday, August 05, 2015 11:33 AM >> To: Tom Warren >> Cc: u-boot@lists.denx.de; Simon Glass; Stephen Warren; Thierry Reding >> Subject: Re: [U-Boot] [PATCH] ARM: tegra: restrict usable RAM size further >> >> On 07/29/2015 01:47 PM, Stephen Warren wrote: >>> From: Stephen Warren <swarren@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). >> >> TomW, what are your thoughts on applying this given the discussion thread? >> Thanks. > > I think this patch is fine. I have not set up any TZ/other carveouts (NVDEC,VPR,GPU,TSEC, etc.) yet in U-Boot, but I have in coreboot, and right now we're using approx. 153MB (0xf66c0000 - 0x100000000). So 512MB here seems large but OK, given that we'll still have tons of SDRAM left on most any modern board. > > I can take this in on the next pass, if no one objects. Adding Marcel for Colibri T20/T30, since this'll affect those boards, too. Thanks. This should only affect Tegra210 boards, since the function I modified is under #ifdef CONFIG_ARM64.
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c index 36bcfb04c021..7842caaa5afb 100644 --- a/arch/arm/mach-tegra/board2.c +++ b/arch/arm/mach-tegra/board2.c @@ -287,11 +287,20 @@ void pad_init_mmc(struct mmc_host *host) * 32-bits of the physical address space. Cap the maximum usable RAM area * at 4 GiB to avoid DMA buffers from being allocated beyond the 32-bit * boundary that most devices can address. + * + * 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). */ ulong board_get_usable_ram_top(ulong total_size) { - if (gd->ram_top > 0x100000000) - return 0x100000000; + if (gd->ram_top > 0xe0000000) + return 0xe0000000; return gd->ram_top; }