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.
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.
In the latter case Linux would want to run in secure state all of the time. In the former it would want to run mostly in non-secure state. But it is difficult to choose between these later than boot time because switching a running system from the secure to non-secure state is so complex.
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.
Given all that, there's not much point to publishing whether a kernel is built for secure side or not. It's tied extremely closely to the platform itself, which is where most of the secure API calls already live.
The point of my proposed ELF flag isn't to advertise that a kernel is capable of running in the secure state. As you say, where this is possible, we don't need to advertise it.
The point of my ELF flag is to advertise that the kernel would like to _know_ that it has control of the secure state; the kernel is told this by the fact that it enters in _monitor mode_ rather than kernel mode. Obviously you shouldn't enter an unconsenting kernel in monitor mode.
If the kernel is to have control of the secure state it needs to know this, and to have a way of making use of it. It looked to me like the easiest way of doing this was entering it in monitor mode. (Since a kernel entered in kernel mode can't tell easily whether it's in secure or non-secure state.)
Likewise, if the kernel is to have control of the hyp mode, it needs to know that and have a way to use it. So entering the kernel in hyp mode seemed to me the easiest way.
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.
Thanks, Ian.