Hi Ian,
On Tue, Aug 23, 2011 at 06:23:32PM +0100, Ian Jackson wrote:
> 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 :-).
Ha, you've got enough people interested now that there's no need to rush!
> > 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).
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.
> 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.
>From discussions that I've been having with the technical architects at ARM
and various bootloader people, it looks like we have two scenarios [this is
reiterating a lot of what you've said but I think it's important]:
After the system has taken care of whatever secure initialisation was
required, it moves into HYP mode. At this point there are two things that
can happen:
1.0: HYP mode boot loader (uboot, UEFI) runs and installs Linux at the
same privilege level
1.1: Raw Linux boots, and detects HYP mode
1.2: Sets up basic init, with HVC trampoline for installing KVM/Xen later
1.3: Switch to SVC mode
1.4: Continue booting Linux as normal
Or:
2.0: HYP layer installed as part of system firmware
2.1: Hypervisor system init, HVC handlers installed
2.2: Switch to SVC mode
2.3: SVC mode boot loader (uboot, UEFI) runs and installs Linux
2.4: Linux boots as normal
Obviously, as kernel developers, we prefer the first approach because it
gives us control over the HYP interface. In practice, I expect to see
some platforms that take the second approach and I think that we have to
support it. The best we can hope for in this case is that the HVC layer
has an API for installing another hypervisor. If that API is standardised,
then even better.
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.
Will
