> -----Original Message----- > From: Darwin Rambo [mailto:dra...@broadcom.com] > Sent: Thursday, January 23, 2014 10:35 PM > To: Detlev Zundel; Sharma Bhupesh-B45370 > Cc: 'u-boot@lists.denx.de'; 'Tom Rini' > Subject: Re: [U-Boot] how to get u-boot code with arm64: core support > > > > On 14-01-23 07:58 AM, Detlev Zundel wrote: > > Hi Bhupesh, > > > >>> -----Original Message----- > >>> From: u-boot-boun...@lists.denx.de > >>> [mailto:u-boot-boun...@lists.denx.de] > >>> On Behalf Of drambo > >>> Sent: Thursday, January 23, 2014 12:32 AM > >>> To: u-boot@lists.denx.de > >>> Subject: Re: [U-Boot] how to get u-boot code with arm64: core > >>> support > >>> > >>> Hi Bhupesh, > >>> > >>>> U-boot doesn't have ARM trusted firmware support as of now. U-boot > >>>> for > >>>> ARMv8 starts in EL3, whereas UEFI starts in EL2 as trusted firmware > >>>> itself is working in EL3. > >>> > >>> Since the ATF software doesn't really care whether it is loading > >>> uefi or u-boot and since it wants to load non-secure images as EL2 > >>> or EL1 > >>> (https://github.com/ARM-software/arm-trusted- > >>> firmware/blob/master/docs/user-guide.md > >>> See section "Normal World Software Execution"), why would we want to > >>> assume u-boot starts in EL3 mode by default? > >>> > >>> If we want to support EL3 execution for convenience to those that > >>> don't have ATF setup, that might make sense, but then shouldn't > >>> initial EL3 execution and subsequent switching levels be debug CONFIG > options? > >>> Thanks. > >>> > >> > >> In the past I remember using u-boot as the bare-metal s/w to debug a > >> Silicon without any BootROM/firmware code running before the same on > >> ARM 32-bit architectures. > > > > Many of our customers (in the embedded market) use U-Boot in such a > > way very successfully. > armv8 and ATF bring in a new security model and with that, secure > monitor/dispatch, secure OS support and secure power control. It may not > be good to assume that we can work in a historical way here.
I am not against ATF :) . Like I mentioned below, I personally favor using ATF to boot both u-boot and UEFI, but I have some reservations on the same. More on that below ..... > > > >> The ATF is presently tested only for UEFI and UEFI comes up in EL2 > >> while the ATF itself is running in EL3. > >> > >> I don't know what would be the popular vote on this, but personally I > >> feel that the u-boot for ARMv8 should also be launched by the ATF > >> (similar to UEFI) and should start execution in EL2 so that it can > >> launch a hypervisor (running in EL2) or Linux (running in EL1). But > >> this might hurt the popular premise that u-boot can be used as a > >> bare-metal s/w to debug a silicon without additional firmware > >> components. > >> > >> Perhaps u-boot experts can guide us on this ! > > > > I have to admit that I'm only reading up on the complexities of the > > security model of aarch64, but my gut response (cf. [1] is that "real > > security" stems from "few code" rather than adding layer over layer. > > With this in mind, I'd really like to see that U-Boot with its well > > known and tested code base can still be the "root of trust" in an > > embedded product (i.e. EL3 as far as I understand). > EL3 is the highest level of trust, and the new armv8 security model > treats uefi/u-boot as non-secure firmware. The ATF trusted firmware > needs to run, initialize secure hardware, load trusted images, and > ultimately launch the non-secure OS loader (uefi or u-boot). As such, I > think that running uefi or u-boot at EL3 violates the current arm > security model i.e. u-boot cannot be the "root of trust" in this > architecture since it is non-secure. Having non-secure firmware run at > the same level as the secure dispatcher and secure monitor will fail any > secure audit in my opinion. > > However, if we set up u-boot so that it can wake up at any security > level and migrate to non-secure EL1, that might be a nice compromise. > But having specific EL3 startup assumptions and code that is always > present in u-boot seems like the wrong approach to me. At the very > least, we should wrap the EL3 code in a CONFIG option since this is not > the planned entry state for final deployment. ... You seem to miss a critical detail here, security extensions were also part of the ARMv7 architecture (although optional) and were controlled by the ID_PFR1, Processor Feature Register 1, Security Extensions, bits[7:4]: Permitted values are: 0b0000 Not implemented. 0b0001 Security Extensions implemented. So, there was a likelihood that some ARMv7 SoCs still didn't have security extensions enabled - I have used one and hence can vouch that a u-boot running as bare-metal s/w helped me in early SoC bringup. In ARMv8, we still have the AArch32 state which still has a ID_PFR1_EL1 register, with the same definition for security extension bits. I agree that for AArch64 state, it makes sense that the s/w to be launched at reset (usually a BootROM or ATF) executes in a Secure aware (i.e. is EL3 aware) and then provides control to a bootloader running in EL2 world (the case presently with UEFI). But that binds the bootloader, in this case u-boot, with an ATF being available before the first early bootloader s/w can be used to play-around with the Pre-SoC emulators or even the SoC. A midway solution can be still have u-boot AArch64 EL3 compliant, but under a #ifdef which gets turned-off when u-boot is launched with ATF and turned-on when u-boot is launched as the 1st s/w component on the SoC (and in this case u-boot starts up in secure EL2 and assumes that all boot-time or run-time security settings are taken care of by the ATF and in case any board/platform specific security settings need to be applied the u-boot code can do the same as it is running in secure EL2). I think that should make both the world's happy. I add David Feng in cc here for his views on the same and request others as well to pitch in with their thoughts. > > Note that these are just my opinions above. Any ARM security experts > would be welcome to contribute thoughts here. > > > > > Many of the embedded U-Boot users who excercise full control over the > > whole software stack very likely want to see the same. > The ATF secure software is freely available. > > > > > The interesting question will be if we can reconcile the requirements > of > > "classic embedded U-Boot users" and this "OEM server market" that seems > > to drive much of these new concepts here. But I sincerely hope so. > > After all, in the end we want to boot an OS to get the real work done > ;) > As armv8 goes mobile, we have less of a server market issue and more of > a mobile security issue. [snip..] Regards, Bhupesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
