On Wed, 15 Oct 2014 15:39:32 +0100 Mark Rutland <mark.rutl...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
