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

[Siarhei Siamashka <siarhei.siamashka@gmail.com>]

On Wed, 15 Oct 2014 15:39:32 +0100
Mark Rutland <mark.rutland@arm.com> wrote:

> [...]
> 
> > 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.

OK, it's good to know that this change does not increase the attack
surface.

> > > > 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.

Indeed. The patch from Hans primarily targets sunxi hardware, but
clearly has a broader scope than just this.

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

True, but in some cases we are the ones who can control and/or predict
the evolution of both the OS and the u-boot development. I believe
that's exactly the case with the community maintained legacy sunxi-3.4
kernel.

> > 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.

Sounds like this may be a hell to maintain and keep working nicely
together

> > 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.

Thanks for the explanations.

-- 
Best regards,
Siarhei Siamashka