From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Dubinin Subject: Re: [RFC] Unicore Subproject Proposal Date: Wed, 13 Sep 2017 08:36:53 +0000 Message-ID: References: <3BAA91DD-A37A-43E3-833B-1E7DEE85FB19@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5642706303742631737==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Simon Kuenzer Cc: Felipe Huici , Lars Kurth , Stefano Stabellini , Wei Liu , "julian.chesterfield@onapp.com" , "rshaposhnik@pivotal.io" , "xen-api@lists.xenproject.org" , Saverio Niccolini , "minios-devel@lists.xenproject.org" , "julien.grall@arm.com" , "committers@xenproject.org" , "mirageos-devel@lists.xenproject.org" , "stefano@aporeto.com" , "xen-devel@lists.xenproject.org" , "volodymyr_babchuk@epam.com" List-Id: xen-devel@lists.xenproject.org --===============5642706303742631737== Content-Type: multipart/alternative; boundary="001a1147c470ddba9905590e0fc3" --001a1147c470ddba9905590e0fc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Simon, all, 1. Is this academic project, or it have specific goals and areas of >> application? Would be good to have some practical use-cases and well >> formulated list of problems (we all feel these by guts, but...), it aimi= ng >> to solve. IMHO that will help to prioritize functionality and get usable >> result faster :) >> > > It is kind of both, however we aim a strong focus on real world problems: > IoT, Mobile Edge Computing (MEC), Automotive, Virtual Network Functions > (VNFs), and others. > We have played with many Unikernels (ClickOS, Mirage, Rump, OSv, and > others) and tried to apply them in the several areas. While doing this, w= e > noticed that each area benefits differently from the properties that > Unikernels give - which is great (e.g., instant boot times for MEC, high > performance for NFV, resource efficiency for IoT). However, building and > maintaining new Unikernels (as we did with ClickOS, MiniCache, and > Minipython) is currently painful. > Because of different focuses on properties and ported/implemented > applications, most Unikernel today are bound to their own OS layers (e.g.= , > ClickOS uses a different Mini-OS than Mirage). Each application requires = a > different subset of OS layers but also enables different optimizations of > them. > > In order to solve this, we came up with the Unicore proposal. But I agree > with your suggestion at this point: It helps for the project start to foc= us > on some initial areas. For now, I hope this is driven by the first > contributors, and I have personally IoT in mind. Since the project goal i= s > so ambitious, we should keep the long-term goal in mind from the beginnin= g. Yes, that's exactly what I meant :) And IMHO it would be good to not have very abstract goals - and you named first real one - IoT. Do you have real-life use-case with real-life hardware to implement within this IoT? For example, popular IoT devkit, people can use and join this efforts? And real, useful application for it? My interest here is mostly disaggregation and security - to have minimal, but still functional service domains, built strictly for specific functionality. So far we (team, I working with) are using BuildRoot to create Dom0/stubdoms/driverdoms/etc. based on Linux (yet). In our case (at least, right now) guest systems are heavy VMs(Windows/Linux/*BSD/QNX) with GPU passthrough (And not only GPU, but other controllers, test boards, etc.). Hardware domains most likely to be based on the OS-es, which have proven and stable hardware support base (Linux, *BSD), but there are still need in service domains - like TUI(Text UI) domain, where users are interacting with host, stub-domain, dom0, which starting hardware domains, etc. So, that could be one more goal - minimalistic service domains for x86/64 platform. Another goal would be virtualization in Automated Control Systems area - but it's too early (for me, at least) to talk about it yet. Does anybody have other _specific_ targets for Unicore in mind? >> 2. Does any security subsystem planned? XEN have XSM/FLASK, but IMHO is >> should be supplemented by some security layer in control/stub domains as >> well. So far only known implementation is OpenXT, but it is.... very >> specific. Probably some generalized security layer needed in Unicore to >> supplement FLASK/XSM... Correct me please, if I misunderstanding :) >> > > I agree that many projects (especially embedded, stubdomains, driver > domains, NFV) have a vested interest in security and isolation. In my vie= w, > XSM/FLASK further restricts what a VM can do and sounds kind of orthogona= l > to the functionality of a VM (am I right?). The fact that Unikernels shou= ld > only pick components that are actually required to do the job reduces the > attack surface compared to general purpose OSes. > Do you see further value with FLASK/XSM which requires early > implementation and design decisions for Unicore? As far as I can tell > something like Flask is implemented mostly in the hypervisor and toolstac= k, > not in the guests themselves, is this right? > > Yes, if Unicore is not supposed to be used as Dom0, and if we are considering Unicore domains only as a guests, running in the single security context, that's fine :) But if, eventually, it will be used as a control domain in multi-tenant system, which should manage XSM/FLASK and fill the gap between real users(and their data) and VMs, restricted by FLASK - it's something to think about. Maybe just not now :) Or it's not one of Unicore goals even :) Just dreaming to have absolutely minimal service domains, where every byte is known and needed :) Regards, Alexander > > Thanks, > > Simon > > >> Regards, >> Alexander >> >> On Fri, Sep 8, 2017 at 3:31 PM, Felipe Huici > > wrote: >> >> Hi Wei, Stefano, >> >> Thank you so much for agreeing to be sponsors! I=E2=80=99ll update t= he >> document. >> >> =E2=80=94 Felipe >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Dr. Felipe Huici >> Chief Researcher, Networked Systems and Da >> ta >> Analytics Group >> NEC Laboratories Europe, Network Research Division >> Kurfuerstenanlage 36, D-69115 Heidelberg >> Tel. +49 >> (0)6221 4342-241 >> Fax: +49 >> (0)6221 4342-155 >> >> e-mail: >> felipe.huici@neclab.eu >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> NEC Europe Limited Registered Office: NEC House, 1 >> Victoria Road, London W3 6BL Registered in England 2832014 >> >> >> >> >> On 9/8/17, 1:00 PM, "Lars Kurth" > > wrote: >> >> >@Wei, @Stefano, >> > >> >On 07/09/2017, 22:16, "Stefano Stabellini" > > wrote: >> > >> > Hi all, >> > >> > I would be glad to sponsor this proposal. I think it will be >> of great >> > benefit to the ecosystem. Let me know if I need to do anything >> >specific. >> > >> >Basically, all which is needed is an agreement. Which we have from >> you >> >both. Felipe, can then add your names to the proposal. >> > >> >Looking out for the evolving project and helping (e.g. through >> advice) is >> >not strictly necessary, >> but >> always welcome. >> > >> >Lars >> > >> >> >> >> >> -- >> Regards, >> Alexander Dubinin >> > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Simon Kuenzer > =E3=82=B7=E3=83=A2=E3=83=B3 =E3=82=AF=E3=82=A5=E3=83=B3=E3=83=84=E3=82=A1= =E3=83=BC > Research Scientist, > Networked Systems and Data Analytics Group > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-264 > Fax: +49 (0)6221 4342-5264 > e-mail: simon.kuenzer@neclab.eu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC Europe Ltd | Registered Office: Athene, Odyssey > Business Park, West End Road, London, HA4 6QE, GB > Registered in England 2832014 > --=20 Regards, Alexander Dubinin --001a1147c470ddba9905590e0fc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Simon, all,

=
1. Is this academic project, or it have specific goals and areas of applica= tion? Would be good to have some practical use-cases and well formulated li= st of problems (we all feel these by guts, but...), it aiming to solve. IMH= O that will help to prioritize functionality and get usable result faster := )

It is kind of both, however we aim a strong focus on real world problems: I= oT, Mobile Edge Computing (MEC), Automotive, Virtual Network Functions (VNF= s), and others.
We have played with many Unikernels (ClickOS, Mirage, Rump, OSv, and others= ) and tried to apply them in the several areas. While doing this, we notice= d that each area benefits differently from the properties that Unikernels g= ive - which is great (e.g., instant boot times for MEC, high performance fo= r NFV, resource efficiency for IoT). However, building and maintaining new = Unikernels (as we did with ClickOS, MiniCache, and Minipython) is currently= painful.
Because of different focuses on properties and ported/implemented applicati= ons, most Unikernel today are bound to their own OS layers (e.g., ClickOS u= ses a different Mini-OS than Mirage). Each application requires a different= subset of OS layers but also enables different optimizations of them.

In order to solve this, we came up with the Unicore proposal. But I agree w= ith your suggestion at this point: It helps for the project start to focus = on some initial areas. For now, I hope this is driven by the first contribu= tors, and I have personally IoT in mind. Since the project goal is so ambit= ious, we should keep the long-term goal in mind from the beginning.Yes, that's exactly what I meant :)
And IMHO it would be good to not have very abstract=C2=A0goals - and you = named first real one - IoT.
Do you have rea= l-life use-case with real-life hardware to implement within this IoT?
=
For example, popular IoT devkit, people can use = and join this efforts? And real, useful application for it?

My interest here is m= ostly disaggregation and security - to have minimal, but still functional s= ervice domains, built strictly for specific functionality.
So far we (team, I working with) are using BuildRoot to cr= eate Dom0/stubdoms/driverdoms/etc. based on Linux (yet).
In our case (at least, right now) guest systems are heavy VMs= (Windows/Linux/*BSD/QNX) with GPU passthrough (And not only GPU, but other = controllers, test boards, etc.).

=
Hardware domains most likely to be based on the = OS-es, which have proven and stable hardware support base (Linux, *BSD), bu= t there are still need in service domains - like TUI(Text UI) domain, where= users are interacting with host, stub-domain, dom0, which starting hardwar= e domains, etc.

So, that could be one more goal - minimalistic service domains fo= r x86/64 platform.

Another goal would be virtualization in Automated Control Syst= ems area - but it's too early (for me, at least) to talk about it yet.<= /div>

Does a= nybody have other _specific_ targets for Unicore in mind?



2. Does any security subsystem planned? XEN have XSM/FLASK, but IMHO is sho= uld be supplemented by some security layer in control/stub domains as well.= So far only known implementation is OpenXT, but it is.... very specific. P= robably some generalized security layer needed in Unicore to supplement FLA= SK/XSM... Correct me please, if I misunderstanding :)

 I agree that many projects (especially embedded, stubdomains, driver domain= s, NFV) have a vested interest in security and isolation. In my view, XSM/F= LASK further restricts what a VM can do and sounds kind of orthogonal to th= e functionality of a VM (am I right?). The fact that Unikernels should only= pick components that are actually required to do the job reduces the attac= k surface compared to general purpose OSes.
Do you see further value with FLASK/XSM which requires early implementation= and design decisions for Unicore? As far as I can tell something like Flas= k is implemented mostly in the hypervisor and toolstack, not in the guests = themselves, is this right?

Yes, if =C2=A0Unicore is not supposed to be used as D= om0, and if we are considering Unicore domains only as a guests, running in= the single security context, that's fine :)
But if, eventual= ly, it will be used as a control domain in multi-tenant system, which shoul= d manage XSM/FLASK and fill the gap between real users(and their data) and = VMs, restricted by FLASK - it's something to think about. Maybe just no= t now :) Or it's not one of Unicore goals even :)

<= div>Just dreaming to have absolutely minimal service domains, where every b= yte is known and needed :)

Regards,
=C2= =A0 Alexander
=C2=A0

Thanks,

Simon


Regards,
=C2=A0 =C2=A0Alexander

On Fri, Sep 8, 2017 at 3:31 PM, Felipe Huici <Felipe.Huici@neclab.eu <mailto:Felipe.Huici@necla= b.eu>> wrote:

=C2=A0 =C2=A0 Hi Wei, Stefano,

=C2=A0 =C2=A0 Thank you so much for agreeing to be sponsors! I=E2=80=99ll u= pdate the document.

=C2=A0 =C2=A0 =E2=80=94 Felipe

=C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 Dr. Felipe Huici
=C2=A0 =C2=A0 Chief Researcher, Networked Systems and= Data
=C2=A0 =C2=A0 Analytics Group
=C2=A0 =C2=A0 NEC Laboratories Europe, Network Research Division
=C2=A0 =C2=A0 Kurfuerstenanlage 36, D-69115 Heidelberg
=C2=A0 =C2=A0 Tel.=C2=A0 =C2=A0 =C2=A0+49
=C2=A0 =C2=A0 (0)6221 4342-241
=C2=A0 =C2=A0 Fax:=C2=A0 =C2=A0 =C2=A0+49
=C2=A0 =C2=A0 (0)6221 4342-155

=C2=A0 =C2=A0 e-mail:
 =C2=A0 =C2=A0 f= elipe.huici@neclab.eu <mailto:felipe.huici@neclab.eu>
=C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 NEC Europe Limited Registered Office: NEC House, 1
=C2=A0 =C2=A0 Victoria Road, London W3 6BL Registered in England 2832014



=C2=A0 =C2=A0 On 9/8/17, 1:00 PM, "Lars Kurth" <lars.kurth@citrix.com
<= /span> =C2=A0 =C2=A0 <mailto:lars.kurth@citrix.com>> wrote:

=C2=A0 =C2=A0 =C2=A0>@Wei, @Stefano,
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>On 07/09/2017, 22:16, "Stefano Stabellini"= ; <sstabelli= ni@kernel.org
 =C2=A0 =C2=A0 <mailto:sstabellini@kernel.org>> wrote:
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Hi all,
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 I would be glad to sponsor this propo= sal. I think it will be
=C2=A0 =C2=A0 of great
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 benefit to the ecosystem. Let me know= if I need to do anything
=C2=A0 =C2=A0 =C2=A0>specific.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>Basically, all which is needed is an agreement. Whi= ch we have from you
=C2=A0 =C2=A0 =C2=A0>both. Felipe, can then add your names to the propos= al.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>Looking out for the evolving project and helping (e= .g. through
=C2=A0 =C2=A0 advice) is
=C2=A0 =C2=A0 =C2=A0>not strictly necessary, but = always welcome.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0>Lars
=C2=A0 =C2=A0 =C2=A0>




--
Regards,
=C2=A0 =C2=A0Alexander Dubinin

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Simon Kuenzer
=E3=82=B7=E3=83=A2=E3=83=B3 =E3=82=AF=E3=82=A5=E3=83=B3=E3=83=84=E3=82=A1= =E3=83=BC
Research Scientist,
 Networked Systems and Data Analytics Group
NEC Laboratories Europe, Network Research Division
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.=C2=A0 =C2=A0 =C2=A0+49 (0)6221 4342-264
Fax:=C2=A0 =C2=A0 =C2=A0+49 (0)6221 4342-5264
e-mail:=C2=A0 = simon.kuenzer@neclab.eu
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
NEC Europe Ltd | Registered Office: Athene, Odyssey
Business Park, West End Road, London, HA4 6QE, GB
Registered in England 2832014



--
=
Regards,
=C2=A0 Alexander Dubinin
--001a1147c470ddba9905590e0fc3-- --===============5642706303742631737== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5642706303742631737==--