Andreas pointed out that I should have cc'd Johannes here. Sorry for forgetting that. -- PMM On 22 May 2012 13:22, Peter Maydell <peter.maydell at linaro.org> 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
