On Wed, Aug 24, 2011 at 6:09 PM, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote: > On Wed, Aug 24, 2011 at 02:51:09PM +0100, Will Deacon wrote: >> I think it's important to separate the problems of secure boot with the >> problems of installing a hypervisor. Whatever happens in secure world, we can >> expect to be dropped at either HYP mode or non-secure SVC mode. Sure, on a dev >> board you might run directly in the secure world so there's a bit of extra >> work to do to get out of that but then we can just drop into HVC mode and >> forget about it. > > I think you're painting a very simple picture there. > > If the kernel has been handed over to while in secure mode, that's > probably because there is no secure monitor implemented. ?If there's > no secure monitor implemented, there's no code in place to handle > SMC instructions. ?To make things worse, if we drop out into non-secure > mode, due to the lack of working SMC instructions, we have no way to > access the various registers we need to. > > So, if the kernel is booted in secure mode and wants to drop into non- > secure mode, we need a separate blob of code to install as our own > secure monitor to provide these services. > >> Unlike the fragmented secure monitor API that currently exists across >> different platforms, it's really in the interests of the vendor to >> standardise on the HYP interface and provide calls to install code, otherwise >> they run the risk of producing what is essentially a closed system. > > On the other hand, I'm sure vendors are already thinking along those > lines - the precident has been set by the secure monitor API mess, so > if it can be made to "work" there... A few thoughts from my end... The kernel potentially has a lot of work to do if it is to support virtualisation when booted in the Secure World, because the kernel needs to switch to the Normal World -- security controllers on the bus will need to be reprogrammed etc., and the kernel would also need to retain some Secure memory somewhere for handling SMC -- i.e., per-SoC code and configuration which just doesn't exist in the kernel yet. The kernel does not need a "real" monitor in this scenario, but it will still need to get back into the Secure World to do certain low-level operations as we observe on e.g. OMAP. This is not trivial since SMC causes a change of memory space as well as privilege. This potentially gets quite complex and messy, and the kernel doesn't really care; my gut feeling is that we probably don't want to go there -- it's a fair amount of extra code from which we don't really get much benefit. So, it could be reasonable to _require_ linux to be started in the Normal World if linux will install its own hypervisor, with suitable (possibly minimal) SMC and HVC handlers/stubs provided by the bootloader or (more probably) firmware. Hopefully, those SMC/HVC interfaces will get reasonably standardised, but in the meantime a bit of SoC-specific code in linux should be adequate to smooth any differences. Vendors likely have a strong incentive to provide adequate and working functionality at these interfaces because failure to do so could be a significant market disadvantage. Cheers ---Dave
