[U-Boot] [PATCH] ARM: bootm: Allow booting in secure mode on hyp capable systems

[Mark Rutland <mark.rutland@arm.com>]

[...]

> Other than this, are you really happy about granting the users full
> rights to allow booting the kernel in the secure mode via a simple
> environment variables tweak? Can't it potentially become a security
> breach in some scenarios?

U-Boot must be running in secure mode in order to boot a kernel in
secure mode. If U-Boot has been placed in secure mode with such an
option, there is obviously nothing in the secure world to protect. As
the user is in charge of booting the kernel, there is nothing in the
normal world to protect.

There is no security breach here.

> > > Or are you saying that it is really impossible to distinguish your
> > > use case of having the appended DT without resorting to the use of the
> > > environment config options?
> > 
> > Think of it. How do you find out about what the kernel wants? This is
> > just a blob...
> 
> The FDT blob has a header with an easily recognisable signature. So we
> can see the difference between the FDT and FEX blobs if the blob is
> provided to u-boot. And if no blob is provided at all, then we are sure
> that it can't be booted by the sunxi-3.4 kernel.

FEX vs DT is specific to sunxi, whereas an explcit boot mode option is
more generally useful. It is possible to have a kernel which can boot in
either mode, where the security state the kernel runs in is a user
choice, regardless of the presence or absence of a DTB.

Trying to guess how an OS will react and working around that is only
going to cause problems when that OS changes over time.

> I can see only one theoretically problematic scenario, where u-boot is
> provided with the non-FDT and non-FEX blob, but loads a kernel, which
> has FDT statically compiled in. How does this actually play with PSCI?

It would be completely orthogonal, just as the presence or absence of a
DTB is orthogonal to the presence or absence of PSCI

> And what about the new device drivers model, which is going to depend
> on FDT information itself? Are we really happy allowing to use different
> FDT blobs for the u-boot and the kernel in the same system?

There are already differences between what U-Boot needs to know and the
kernel needs to know, e.g. secure peripherals if the kernel is booted in
a non-secure mode. So in general you might need separate DTBs; the
physical address spaces are different.

> Or have I missed something?
> 
> Either way, following the least surprise principle, IMHO u-boot should
> log the reason for making a decision about whether it is switching to
> the non-secure mode or not. This is useful for troubleshooting.

Printing a message would make sense regardless of how the mode is
selected.

Thanks,
Mark.