ARM processor mode, kernel startup, Hyp / secure state

[Ian Jackson]

Russell King - ARM Linux writes ("Re: ARM processor mode, kernel startup, Hyp / secure state"):
> 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.

It's not clear to me from reading the ARM ARM that a kernel written
for the non-secure side couldn't make the same monitor calls, but I
haven't seen any of the OMAP manuals and I haven't read any of the
errata (which you obviously have).

If there are kernels intended to run on the secure side, a difficulty
arises: if KVM wants to use Hyp mode and the associated features, how
is that to be done ?

> > 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.

Well, yes, that would be one way of looking at it.  I'm not sure why
you would want to do that, but it was just one of the two options if
Linux is trying to own the secure/non-secure distinction.

On the other hand if Linux wants to own that boundary and to use it to
provide a /more/ privileged facility, that would involve some Linux
kernel module hoisting a pile of its code (or, more likely, code
provided from userspace) into secure state, which code then pulled the
ladder up after itself.  The resulting thing wouldn't look much like a
user process and wouldn't (afterwards) be subject to unwanted
interference.  But I don't think anyone is doing anything like this ?

> > 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.

Fair enough.  (My own x86 knowledge is pretty shallow too TBH.)

> 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.

If this is always (or generally) the case then Linux needs to run on
only one side of the secure/non-secure barrier.  Since Linux might
want to run kvm, which requires Hyp mode, which is only on the
non-secure side, that means it needs to run on the non-secure side.

What have I missed ?

Ian.