ARM processor mode, kernel startup, Hyp / secure state

[Ian Jackson]

Catalin Marinas writes ("Re: ARM processor mode, kernel startup, Hyp / secure state"):
> (I'll be on holiday from tomorrow, so not able to follow up until September).

Right.  Let's try to be quick :-).

> We had some discussions both with ARM partners and Christoffer and it
> is not clear how we go about initialising the Hyp mode. Most SoC
> vendors would probably just run Linux in non-secure SVC mode and would
> not touch the Hyp mode at all. Linux would issue an SMC to set the
> HVBAR (could do HVC but I expect that there is no secure monitor
> code). Once this is set, assuming that the Hyp MMU is disabled, Linux
> can invoke an HVC and initialise the Hyp mode.

Well, yes.  Do SoC vendors all expect to own the secure state ?

If so then the answer is perhaps simply that they should boot Linux in
Hyp mode (and expect Linux to drop to ordinary svc mode).

> The problem is that the SMC API is specific to a secure monitor
> implementation. An alternative would be to ask the vendors to get some
> simple Hyp code which would trap access to HVBAR for example and set
> it with that value.

That's seems to be extending the range of ways in which the firmware
can make things go wrong, and broadening the interface to the
firmware.

> From the above, I would just allow (iii). As Dave pointed out, we
> don't have the ELF information at this point.

If we had a more functional bootloader setup (which AIUI is definitely
planned) we could do.

> >   (b) If started in Hyp mode:
> >       * Install a trivial hypervisor vector which unconditionally
> >         copies r0 to HVBAR and returns
> >   (c) Rest of startup.
> 
> Maybe we could allow (b) if SoC vendors don't provide a different API
> to set the HVBAR. But it means that kernels not aware of this feature
> would fail.

It turns out that at least your kernel boots just fine if started in
Hyp mode :-).

Ian.