ARM processor mode, kernel startup, Hyp / secure state

[Dave Martin]

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