Re: [RFC] Unicore Subproject Proposal

[Simon Kuenzer <simon.kuenzer@neclab.eu>]

Hey Alexander,

On 13.09.2017 10:36, Alexander Dubinin wrote:
> 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 aiming 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, we 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 focus 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 is so ambitious, 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 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?
> 

This is a good question. No, we haven't settled on a particular IoT 
devkit yet. Do you have something in mind?
For now, we did some research prototypes for IoT by using a Cubieboard 
and Unikernels that process some sensor data.

> 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.

Yes, sure.

> 
> 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?

I am also interested in answers.

> 
> 
> 
>         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 view, XSM/FLASK further restricts what a VM can do and sounds
>     kind of orthogonal to the 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 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 toolstack, 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 :)

I got it. Yes, I think this could be considered as a goal for an 
extension library to the Xen platform libraries. It could be seen as 
"control domain" extension. Why not? ;-)

> 
> Just dreaming to have absolutely minimal service domains, where every 
> byte is known and needed :)

I think there are use cases for this. I think this starts with 
automotive, but it could be also important for projects, like OpenXT.

> 
> Regards,
>    Alexander
> 
> 
>     Thanks,
> 
>     Simon
> 
> 
>         Regards,
>             Alexander
> 
>         On Fri, Sep 8, 2017 at 3:31 PM, Felipe Huici
>         <Felipe.Huici@neclab.eu <mailto:Felipe.Huici@neclab.eu>
>         <mailto:Felipe.Huici@neclab.eu <mailto:Felipe.Huici@neclab.eu>>>
>         wrote:
> 
>              Hi Wei, Stefano,
> 
>              Thank you so much for agreeing to be sponsors! I’ll update
>         the document.
> 
>              — Felipe
> 
>              ============================================================
>              Dr. Felipe Huici
>              Chief Researcher, Networked Systems and Da
>         <https://maps.google.com/?q=orked+Systems+and+Da&entry=gmail&source=g>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 <mailto:felipe.huici@neclab.eu>
>         <mailto:felipe.huici@neclab.eu <mailto:felipe.huici@neclab.eu>>
>              ============================================================
>              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" <lars.kurth@citrix.com
>         <mailto:lars.kurth@citrix.com>
>              <mailto:lars.kurth@citrix.com
>         <mailto:lars.kurth@citrix.com>>> wrote:
> 
>               >@Wei, @Stefano,
>               >
>               >On 07/09/2017, 22:16, "Stefano Stabellini"
>         <sstabellini@kernel.org <mailto:sstabellini@kernel.org>
>              <mailto:sstabellini@kernel.org
>         <mailto:sstabellini@kernel.org>>> 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,
>         <https://maps.google.com/?q=strictly+necessary,&entry=gmail&source=g>but
>         always welcome.
>               >
>               >Lars
>               >
> 
> 
> 
> 
>         -- 
>         Regards,
>             Alexander Dubinin
> 
> 
>     -- 
>     ============================================================
>     Simon Kuenzer
>     シモン クゥンツァー
>     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 <mailto:simon.kuenzer@neclab.eu>
>     ============================================================
>     NEC Europe Ltd | Registered Office: Athene, Odyssey
>     Business Park, West End Road, London, HA4 6QE, GB
>     Registered in England 2832014
> 
> 
> 
> 
> -- 
> Regards,
>    Alexander Dubinin

Thanks,

Simon

-- 
============================================================
Simon Kuenzer
シモン クゥンツァー
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
============================================================
NEC Europe Ltd | Registered Office: Athene, Odyssey
Business Park, West End Road, London, HA4 6QE, GB
Registered in England 2832014

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