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.