Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

Hi Volodymyr, On 02/11/17 20:07, Volodymyr Babchuk wrote: On Thu, Nov 02, 2017 at 05:49:12PM +, Julien Grall wrote: On 02/11/17 16:53, Volodymyr Babchuk wrote: On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote: On 24/10/17 20:02, Volodymyr Babchuk wrote: But parameters are

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On Thu, Nov 02, 2017 at 05:49:12PM +, Julien Grall wrote: Hi Julien, > On 02/11/17 16:53, Volodymyr Babchuk wrote: > >On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote: > >>On 24/10/17 20:02, Volodymyr Babchuk wrote: > If it is not safe, this means you have a whitelist

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

Hi Volodymyr, On 02/11/17 16:53, Volodymyr Babchuk wrote: On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote: On 24/10/17 20:02, Volodymyr Babchuk wrote: If it is not safe, this means you have a whitelist solution and therefore tie Xen to a specific OP-TEE version. So if you need to

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On Thu, Nov 02, 2017 at 01:17:26PM +, Julien Grall wrote: Hi Julien, > On 24/10/17 20:02, Volodymyr Babchuk wrote: > >>If it is not safe, this means you have a whitelist solution and > >>therefore > >>tie Xen to a specific OP-TEE version. So if you need to use a new >

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

Hi Volodymyr, On 24/10/17 20:02, Volodymyr Babchuk wrote: If it is not safe, this means you have a whitelist solution and therefore tie Xen to a specific OP-TEE version. So if you need to use a new function you would need to upgrade Xen making the code of using new version potentially high.

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On 27 Oct 2017 20:59, "Stefano Stabellini" wrote: On Fri, 27 Oct 2017, Julien Grall wrote: > Hi, > > Just answering to dom0 been 1:1 domain. > > On 24/10/17 22:33, Stefano Stabellini wrote: > > On Tue, 24 Oct 2017, Volodymyr Babchuk wrote: > > > > For this series, I think

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On Fri, 27 Oct 2017, Julien Grall wrote: > Hi, > > Just answering to dom0 been 1:1 domain. > > On 24/10/17 22:33, Stefano Stabellini wrote: > > On Tue, 24 Oct 2017, Volodymyr Babchuk wrote: > > > > For this series, I think we need a way to specify which domains can talk > > > > to TEE, so that

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

Hi, Just answering to dom0 been 1:1 domain. On 24/10/17 22:33, Stefano Stabellini wrote: On Tue, 24 Oct 2017, Volodymyr Babchuk wrote: For this series, I think we need a way to specify which domains can talk to TEE, so that we can only allow it for a specific subset of DomUs. I would probably

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On Tue, 24 Oct 2017, Volodymyr Babchuk wrote: > > > > >Approach in this RFC is much simpler. Few hooks in arch code + > > > > >additional > > > > >subsystem, which can be easily turned off. > > > > > > > > Stefano do you have any opinion on this discussion? > > > > We need to start somewhere,

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

Hi Julien, Jens, I'm looped in Jens Wiklander. He is one of OP-TEE maintainers. He also maintains TEE subsytem in Linux kernel. I CC'ed him in 4/4 patch, because only it concerned OP-TEE. But looks like discussion in this thread revolves primarily over OP-TEE, so I'm adding him there. Jens, if

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

Hi, On 23/10/17 21:11, Volodymyr Babchuk wrote: On Mon, Oct 23, 2017 at 05:59:44PM +0100, Julien Grall wrote: Hi Volodymyr, Hi Julien, Let me begin the e-mail with I am not totally adversed to putting the TEE mediator in Xen. At the moment, I am trying to understand the whole picture.

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

Hello Stefano On Mon, Oct 23, 2017 at 02:26:56PM -0700, Stefano Stabellini wrote: > > > >This is a lot of a work. It requires changes in generic parts of XEN. > > > >I fear it will be very hard to upstream such changes, because no one > > > >sees an immediate value in them. How do you think,

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On Mon, 23 Oct 2017, Volodymyr Babchuk wrote: > > >This is a lot of a work. It requires changes in generic parts of XEN. > > >I fear it will be very hard to upstream such changes, because no one > > >sees an immediate value in them. How do you think, what are my chances > > >to upstream this? > >

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On Mon, Oct 23, 2017 at 05:59:44PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, > Let me begin the e-mail with I am not totally adversed to putting the TEE > mediator in Xen. At the moment, I am trying to understand the whole picture. Thanks for clarification. This is really reassuring

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

Hi Volodymyr, Let me begin the e-mail with I am not totally adversed to putting the TEE mediator in Xen. At the moment, I am trying to understand the whole picture. On 20/10/17 18:37, Volodymyr Babchuk wrote: On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote: On 17/10/17 16:59,

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On 20.10.17 19:57, Tamas K Lengyel wrote: Hello Tamas, In previous discussion we considered only two variants: in XEN or outside XEN. Stubdomain approach looks more secure, but I'm not sure that it is true. Such stubdomain will need access to all guests memory. If you managed to gain control

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote: > Hi Volodymyr, Hi Julien, > On 17/10/17 16:59, Volodymyr Babchuk wrote: > >On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: > >> > >> > >>On 11/10/17 20:01, Volodymyr Babchuk wrote: > >>>Hello all, > >> > >>Hi Volodymyr,

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

>> In previous discussion we considered only two variants: in XEN or outside >> XEN. Stubdomain approach looks more secure, but I'm not sure that it is >> true. >> Such stubdomain will need access to all guests memory. If you managed to >> gain control on mediator stubdomain, you can do anything

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

Hi Volodymyr, On 17/10/17 16:59, Volodymyr Babchuk wrote: On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: On 11/10/17 20:01, Volodymyr Babchuk wrote: Hello all, Hi Volodymyr, Hi Julien I want to present TEE mediator, that was discussed earlier ([1]). I selected design

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote: > > > On 11/10/17 20:01, Volodymyr Babchuk wrote: > >Hello all, > > Hi Volodymyr, Hi Julien > > > > >I want to present TEE mediator, that was discussed earlier ([1]). > > > >I selected design with built-in mediators. This is easiest

Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

On 11/10/17 20:01, Volodymyr Babchuk wrote: Hello all, Hi Volodymyr, I want to present TEE mediator, that was discussed earlier ([1]). I selected design with built-in mediators. This is easiest way, it removes many questions, it is easy to implement and maintain (at least I hope so).