[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))
Stefano, On 12 May 2017 at 21:43, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote: > On the topic of the technical reasons for being out of the hypervisor > (EL0 app or stubdom), I'll spend a couple of words on security. > > How large are these components? If they increase the hypervisor code > size too much, it's best if they are run elsewhere. I'm talking about OP-TEE now. "Large" as "large code base"? I have shared my PoC driver. Here it is [1]. My expectation: 1,000-2,000 lines of code for mediator + some OP-TEE headers. > What is their guest-exposed attack surface? If it's large it's best to > run them out of the hypervisor. OP-TEE mediator will trap SMC calls and parse parameter buffers according to OP-TEE ABI specification. ABI is very simple, so I can't say that there will be attack surface. > My gut feeling is that both these points might be a problem. The real problem, that is needs the same privileges, as hypervisor itself. I wrote this in parallel thread: it needs to pin guest pages (to ensure that page will be not transferred to another domain, while OP-TEE uses it), it needs to map guest page so it can do IPA->PA translation in a command buffer, it needs to execute SMCs (but we can limit it there, thanks to SMCCC), probably it will need to inject vIRQ to guest to wake it up. [1] https://github.com/lorc/xen/tree/staging-4.7/xen/arch/arm/optee -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babchuk@xxxxxxxxx _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |