[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.