On Tue, Aug 23, 2011 at 05:50:10PM +0100, Ian Jackson wrote:
Russell King - ARM Linux writes ("Re: ARM processor mode, kernel startup, Hyp / secure state"):
We already have kernels which boot in both secure and non-secure mode CPUs. There's very little difference between the two from the core ARM support code - except that we have expectations that appropriate hardware work-arounds will have already been initialized by the secure monitor (as there is no way for the kernel to be able to call out to the secure monitor in a platform independent way.)
Right.
So, basically, which side of the secure division the kernel runs on depends highly on the platform itself - and as the secure monitor APIs are highly platform specific, there's no getting away from that.
It seems to me that from the PoV of Linux there are two kind of platform: ones where the kernel is expected to own the secure state, and ones where it is expected to run only in non-secure state.
The distinction is a highly technical one, and it comes from the lack of any kind of secure monitor API, and the fact that the non-secure world is prevented from accessing various registers.
A secure side kernel contains no calls to the secure monitor. Calls to the secure monitor are required to reprogram critical registers such as L2 cache configuration registers and the like. For example, on OMAP, it is impossible to reliably invalidate the contents of the L2 cache without making secure mode calls to reprogram various control registers.
Not having that register reprogrammed means you're running against data corrupting errata bugs.
So, basically, a kernel built for non-secure will only run on the non-secure side. A kernel built for secure will only run reliably on the secure side.
But just because Linux owns the secure state doesn't mean that it should run in that state most of the time. The question is really whether Linux would like to use the secure/non-secure division to provide a more secure facility which other parts of the system can use, or to use it to provide a more constrained/contained environment in which to run less-trusted code.
What you're talking about is using Linux as the secure monitor, and effectively matching the dividing line between Linux and userspace with the secure/non-secure division.
Remember that Linux is not a micro-kernel, so any other partitioning doesn't make sense. (To place the partition elsewhere implies that you have to carve the kernel data structures up and contain them within each world - with separate memory allocators etc.)
If the kernel does not contain the appropriate platform specific secure monitor API then it can't run in non-secure mode (or it can but the functionality will be severely limited - no power management, and in some cases buggy L2 cache.) So you wouldn't _want_ to run such a kernel if you value your data.
So is the secure state used for the same kind of things as SMM is on Intel, then ? Perhaps I haven't understood the usual setups well enough.
You're assuming I have deep knowledge of x86. I don't, sorry.
I think I know what the hyp mode is for and how people will use it :-). But I don't really know what the secure state is for.
Secure state is used to run the secure monitor, which is a chunk of code provided by the SoC manufacturer and normally programmed into ROM on real SoCs.
What is does is up to the SoC manufacturer. What services it provides is up to the SoC manufacturer.
The implication is that once the secure monitor has set things up, it will start execution of things like boot loaders, etc in non-secure mode. Moreover, there's usually no way to get back into secure mode to run your own code (otherwise it wouldn't be secure...)
A SoC manufacturer may provide a secure monitor to deal with storing secret keys, and providing some kind of encryption services. Or it may provide nothing more than a way to access system registers which are only accessible from secure mode.