Re: Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

From: George Dunlap <george.dunlap@citrix.com>
To: Volodymyr Babchuk <vlad.babchuk@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Andrii Anisov <andrii_anisov@epam.com>,
	Artem Mygaiev <joculator@gmail.com>
Subject: Re: Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))
Date: Mon, 15 May 2017 12:21:48 +0100	[thread overview]
Message-ID: <CAFLBxZbux+4pusm8XtJDRdO5=jR3d5gGbbFo-EL-tDinXCSFxg@mail.gmail.com> (raw)
In-Reply-To: <CAOcqxo0x1fzTaNrMJGGTbBNE==fV5aJF3puDtm6BE_QvHoSjmA@mail.gmail.com>

[Reducing CC list now that we're off the topic of modules]

On Fri, May 12, 2017 at 8:04 PM, Volodymyr Babchuk
<vlad.babchuk@gmail.com> wrote:
> Stefano,
>
> On 12 May 2017 at 21:43, Stefano Stabellini <sstabellini@kernel.org> 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.

Xen is different than Linux in that it attempts to take a "practical
microkernel" approach.  "Microkernel" meaning that we prefer to do as
much *outside* of the hypervisor as possible.  "Practical" meaning, if
running it outside the hypervisor causes too much complexity or too
much performance overhead, then we don't stand on ideology but allow
things to run inside of Xen.

With the exception of SMCs (which I don't know anything about), device
models (e.g., QEMU) already have  of this functionality on x86,
running from dom0 or from a stubdomain.

Do OP-TEE mediators require a lot of performance?  I.e., do the
operations happen very frequently and/or are they particularly
latency-sensitive?  If not then it might be worth implementing it as a
dom0 device model first, and then exploring higher-performing options
if that turns out to be too slow.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel