[Qemu-devel] ARM QEMU/KVM and TrustZone

[Peter Maydell]

Historically for QEMU we haven't implemented TrustZone support even
though we claim to emulate CPUs that provide it. Instead we provide a
CPU which mostly looks like a variant of the real thing without the
TrustZone feature. We then bolt on a few extra cp15 registers (eg the
SCR) as a pragmatic move to get Linux guests to run. Now we're also
dealing with KVM on ARM I'd like to define things a bit more solidly
so KVM and TCG agree on what the CPU model they present is.

There are several possible environments we could provide
to a guest:
 (1) a CPU with full TrustZone support
 (2) a CPU without TrustZone at all
 (3) a TZ CPU running in NonSecure PL0/PL1
 (4) a TZ CPU running in Secure PL0/PL1

In some ways (1) is the "purist" solution -- emulate exactly what the
hardware does. However:

 * on TCG it would require a lot of work, including new functionality
   in core QEMU (to support having different CPU cores being able to
   see different views of memory, and having the S/NS attribute
   attached to memory transactions)

 * it isn't possible in KVM, because the ARM Virtualization Extensions
   don't allow you to fake the CPSR a guest sees, and so you can't
   make the guest believe it is in Monitor mode

Option (2) is architecturally sanctioned (ie TrustZone is an optional
feature, not mandatory), but it doesn't correspond to real CPUs, in
that the hardware Cortex-A8/A9/A15 always have TrustZone. So we're
modelling something that doesn't really exist.

Options (3) and (4) correspond to the environment an OS guest
typically actually uses on hardware. For ARM's devboards (versatile
express etc) Linux runs in the Secure world but it doesn't actually
use any of the TrustZone functionality, it's just a "give me full
access to everything" setup. For just about every other ARM system,
the boot rom or equivalent keeps Secure world to itself, and the OS
kernel runs in the NonSecure world. (This typically means that the
boot rom provides a set of board-specific entry points via the Secure
Monitor Call (SMC) instruction for doing operations like "invalidate
whole L2 cache" which require secure privileges.)

Proposal:

My suggestion is that we present the guest with a view that looks like
a sort of superset of (2) (3) and (4), ie sufficient that a guest
expecting any of those environments can run. In particular:

 * no cp15 registers have secure/nonsecure banking
 * there is only one memory space visible
 * secure-access-only permissions are not enforced
 * the handful of only-in-trustzone registers are implemented
   (eg VBAR, MVBAR)
 * we implement a "fake monitor mode"

The aim of the "fake monitor mode" is to allow us to provide fake
qemu-specific bootroms which implement whatever the board's SMC
interface is, without having to write specific KVM kernel code for
each board. So we don't have to run arbitrary secure-world guest code.
The rules are:
 * on an SMC instruction we enter the guest at the SMC vector
   as defined by the MVBAR (monitor vector base address register)
 * we actually run with the same access permissions as above
   (and under KVM if you look at CPSR.M it will tell you you're
   in Supervisor mode)
 * return from the SMC is via a standard exception return insn
 * we don't implement the separate memory space for the secure
   world. (This implies that you need to find space in the
   non-secure world's physical memory map for the bootrom shim;
   not a big deal I think since we already have a requirement
   for some space to put QEMU's arm_boot trivial bootloader.)

The code written for this fake monitor mode environment is likely to
be able to work OK if we ever implement full TrustZone support in TCG
QEMU.

Work required:

* Documentation: the general principles as listed above
* TCG: make sure we have implementations of all the TZ registers
* TCG: implement the SMC and fake-monitor-mode
  (I already have patches from Nokia in the qemu-linaro
  stack which can be cleaned up and used here)
* KVM: implement emulation of MVBAR
* KVM: set the config bit so SMC is trapped to the hypervisor
  and causes guest restart at the right entrypoint
* KVM: if there turns out to be anything that fake-monitor-mode
  needs to do that requires Hyp privilege we'd need a hypercall
  ABI, but I can't currently think of anything

I think that's basically a fairly small set of work to formalise
the approach we're already taking in practice, and make it a little
more flexible.

Opinions?

-- PMM