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