[U-Boot] how to get u-boot code with arm64: core support

[bhupesh.sharma at freescale.com]

> -----Original Message-----
> From: Darwin Rambo [mailto:drambo at broadcom.com]
> Sent: Thursday, January 23, 2014 10:35 PM
> To: Detlev Zundel; Sharma Bhupesh-B45370
> Cc: 'u-boot at 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-bounces at lists.denx.de
> >>> [mailto:u-boot-bounces at lists.denx.de]
> >>> On Behalf Of drambo
> >>> Sent: Thursday, January 23, 2014 12:32 AM
> >>> To: u-boot at 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