Re: [Qemu-devel] ARM QEMU/KVM and TrustZone

[Peter Maydell]

Andreas pointed out that I should have cc'd Johannes here. Sorry
for forgetting that.

-- PMM

On 22 May 2012 13:22, Peter Maydell <address@hidden> wrote:
> 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



-- 
12345678901234567890123456789012345678901234567890123456789012345678901234567890
         1         2         3         4         5         6         7         8