On 14 November 2012 13:51, James White <james.white.2012@xxxxxxxxxxx> wrote: > I would like to understand the design of the KVM/ARM implementation with > regard to making ARM's TrustZone capabilities available to a VM. > I have read on several mailing lists that Qemu will have some limited > support for TrustZone, so that at least you will be able to run secure > firmware inside a VM. E.g. this will enable to use the smc instruction in a > VM's boot loader, so that secure firmware implementations can be used and > run on Qemu. So the first question is: is that already implemented and > usable when running KVM on ARM? No. At the moment trustzone support for QEMU (in purely emulated mode) is unimplemented. I have some design ideas for a "minimal fake trustzone" setup that would let you implement a qemu-specific fake bootrom for booting guests that assume they run in the non-secure world and use SMC calls for a few operations. We haven't actually started on that yet, though (the current guest OS environment doesn't need it). There's also been some work by Johannes Winter on doing proper emulation of TrustZone, but this is experimental: https://github.com/jowinter/qemu-trustzone The expected major use case for virtualization is that you'll just run a straightforward guest that doesn't care about TrustZone at all. > The second question is: in this design where TrustZone is "emulated" by > Qemu, does KVM play a role in this as well? I assume that it cannot provide > monitor mode in hardware (because it is running in hyp mode), so therefore > it cannot provide any form of acceleration. The virtualization extensions of the ARM architecture don't allow virtualization of code running in monitor mode. You could probably in theory implement a hybrid setup where non-secure world code ran accelerated as usual and code in the secure world and/or monitor mode code was emulated instruction at a time. However that would be a lot of work and I don't think anybody is currently planning to do it. (It might well also require some significant qemu rework to cope with the two separate address spaces, device accesses which differ for S vs NS accesses, etc.) -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
