Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Lars Kurth]

On 18/09/2017, 05:17, "Felipe Huici"  wrote:

Hi Lars, all,

[cc’ing authors of Erlang on Xen, HalVM and Rump].

Thanks everyone for all of the support and useful comments. We’ve
incorporated a number of them into a new version of the document (attached
and pasted at the bottom for convenience) and for those that didn’t make
it we’re keeping track of them.

Lars, FYI, Simon also did a blog post regarding Unicore on unikernel.org
(https://devel.unikernel.org/t/unicore-a-new-unikernel-project/274).

Please let us know what the next steps are.

 I will set up the formal vote next week! It doesn’t need the full distribution 
list
Lars


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

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Felipe Huici]

Hi Lars,

Great news, thanks! We sent v2 to the mailing list on the 18th, 2 days
ago. When you say “post v2 first”, should we be posting it somewhere else
too?

Thanks,

— Felipe


Dr. Felipe Huici
Chief Researcher, Networked Systems and Data
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.hu...@neclab.eu

NEC Europe Limited Registered Office: NEC House, 1
Victoria Road, London W3 6BL Registered in England 2832014




On 9/20/17, 2:20 AM, "Lars Kurth"  wrote:

>Felipe, Simon,
>a quick note to let you know that the Advisory Board in today’s AB
>meeting decided to endorse your proposal.
>Let me know how you proceed: from my perspective, we can kick off a
>formal vote before you make modifications to the proposal, but I think it
>is better to post v2 first.
>Lars
>
>On 07/09/2017, 05:26, "Felipe Huici"  wrote:
>
>Dear all,
>
>Following up on discussions that Simon Kuenzer had with several of
>you at
>the last Xen summit, we’re now submitting a Xen subproject proposal
>based
>on our Unicore work. Could you please review it?
>
>Thanks,
>
>Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.
>
>
>PROPOSAL: Unicore
>=
>
>Roles
>-
>Project Leads: Simon Kuenzer  (main lead)
>   Felipe Huici  (co-lead)
>   Florian Schmidt  (co-lead)
>Project Mentor:  Lars Kurth 
>Project Sponsor: -To be found-
>
>Background
>--
>In recent years, several papers and projects dedicated to unikernels
>have
>shown the immense potential for performance gains that these have. By
>leveraging specialization and the use of minimalistic OSes,
>unikernels are
>able to yield impressive numbers, including fast instantiation times
>(tens
>of milliseconds or less), tiny memory footprints (a few MBs or even
>KBs),
>high network throughput (10-40 Gb/s), and high consolidation (e.g.,
>being
>able to run thousands of instances on a single commodity server), not
>to
>mention a reduced attack surface and the potential for easier
>certification. Unikernel projects worthy of mention include MirageOS,
>ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
>
>The fundamental drawback of unikernels is that they require that
>applications be manually ported to the underlying minimalistic OS
>(e.g.
>having to port nginx, snort, mysql or memcached to MiniOS or OSv);
>this
>requires both expert work and often considerable amount of time. In
>essence, we need to pick between either high performance with
>unikernels,
>or no porting effort but decreased performance and decreased
>efficiency
>with standard OS/VM images. The goal of this proposal is to change
>this
>status quo by providing a highly configurable unikernel code base; we
>call
>this base Unicore.
>
>This project also aims to concentrate the various efforts currently
>going
>on in the Xen community regarding minimalistic OSes (essentially
>different
>variants of MiniOS). We think that splitting the community across
>these
>variants is counter-productive and hope that Unicore will provide a
>common
>place for all or most improvements and customizations of minimalistic
>OSes. The long term goal is to replace something like MiniOS with a
>tool
>that can automatically build such a minimalistic OS.
>
>Unicore - The "Unikernel Core"
>-
>The high level goal of Unicore is to be able to build unikernels
>targeted
>at specific applications without requiring the time-consuming, expert
>work
>that building such a unikernel requires today. An additional goal (or
>hope) of Unicore is that all developers interested in unikernel
>development would contribute by supplying libraries rather than
>working on
>independent projects with different code bases as it is done now. The
>main
>idea behind Unicore is depicted in Figure 1 and consists of two basic
>components:
> 
>
>[Attachment: unicore-oneslider.pdf]
>
>
>Figure 1. Unicore architecture.
>
> 
>Library pools would contain libraries that the user of Unicore can
>select
>from to create the unikernel. From the bottom up, library pools are
>organized into (1) the architecture library tool, containing libraries
>specific to a computer architecture (e.g., x86_64, ARM32 or MIPS);
>(2) the
>platform tool, where target platforms can be Xen, KVM, bare metal
>(i.e. no
>virtualization) 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Stefano Stabellini]

On Wed, 20 Sep 2017, Lars Kurth wrote:
> Felipe, Simon,
> a quick note to let you know that the Advisory Board in today’s AB meeting 
> decided to endorse your proposal.
> Let me know how you proceed: from my perspective, we can kick off a formal 
> vote before you make modifications to the proposal, but I think it is better 
> to post v2 first.

Congratulations!


 
> On 07/09/2017, 05:26, "Felipe Huici"  wrote:
> 
> Dear all,
> 
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’re now submitting a Xen subproject proposal based
> on our Unicore work. Could you please review it?
> 
> Thanks,
> 
> Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.
> 
> 
> PROPOSAL: Unicore
> =
> 
> Roles
> -
> Project Leads: Simon Kuenzer  (main lead)
>Felipe Huici  (co-lead)
>Florian Schmidt  (co-lead)
> Project Mentor:  Lars Kurth 
> Project Sponsor: -To be found-
> 
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
> 
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
> 
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.
> 
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:
>  
> 
> [Attachment: unicore-oneslider.pdf]
> 
> 
> Figure 1. Unicore architecture.
> 
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux; and (3) the main library pool,
> containing a rich set of functionality to build the unikernel from. This
> last library includes drivers (both virtual such as netback/netfront and
> physical such as ixgbe), filesystems, memory allocators, schedulers,
> network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
> Python interpreter and debugging and profiling tools. These pools of
> libraries constitute a code base for creating unikernels. As shown, a
> library can be relatively large (e.g libc) or quite small (a scheduler),
> which should allow for a 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Lars Kurth]

Felipe, Simon,
a quick note to let you know that the Advisory Board in today’s AB meeting 
decided to endorse your proposal.
Let me know how you proceed: from my perspective, we can kick off a formal vote 
before you make modifications to the proposal, but I think it is better to post 
v2 first.
Lars

On 07/09/2017, 05:26, "Felipe Huici"  wrote:

Dear all,

Following up on discussions that Simon Kuenzer had with several of you at
the last Xen summit, we’re now submitting a Xen subproject proposal based
on our Unicore work. Could you please review it?

Thanks,

Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.


PROPOSAL: Unicore
=

Roles
-
Project Leads: Simon Kuenzer  (main lead)
   Felipe Huici  (co-lead)
   Florian Schmidt  (co-lead)
Project Mentor:  Lars Kurth 
Project Sponsor: -To be found-

Background
--
In recent years, several papers and projects dedicated to unikernels have
shown the immense potential for performance gains that these have. By
leveraging specialization and the use of minimalistic OSes, unikernels are
able to yield impressive numbers, including fast instantiation times (tens
of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
high network throughput (10-40 Gb/s), and high consolidation (e.g., being
able to run thousands of instances on a single commodity server), not to
mention a reduced attack surface and the potential for easier
certification. Unikernel projects worthy of mention include MirageOS,
ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.

The fundamental drawback of unikernels is that they require that
applications be manually ported to the underlying minimalistic OS (e.g.
having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
requires both expert work and often considerable amount of time. In
essence, we need to pick between either high performance with unikernels,
or no porting effort but decreased performance and decreased efficiency
with standard OS/VM images. The goal of this proposal is to change this
status quo by providing a highly configurable unikernel code base; we call
this base Unicore.

This project also aims to concentrate the various efforts currently going
on in the Xen community regarding minimalistic OSes (essentially different
variants of MiniOS). We think that splitting the community across these
variants is counter-productive and hope that Unicore will provide a common
place for all or most improvements and customizations of minimalistic
OSes. The long term goal is to replace something like MiniOS with a tool
that can automatically build such a minimalistic OS.

Unicore - The "Unikernel Core"
-
The high level goal of Unicore is to be able to build unikernels targeted
at specific applications without requiring the time-consuming, expert work
that building such a unikernel requires today. An additional goal (or
hope) of Unicore is that all developers interested in unikernel
development would contribute by supplying libraries rather than working on
independent projects with different code bases as it is done now. The main
idea behind Unicore is depicted in Figure 1 and consists of two basic
components:
 

[Attachment: unicore-oneslider.pdf]


Figure 1. Unicore architecture.

 
Library pools would contain libraries that the user of Unicore can select
from to create the unikernel. From the bottom up, library pools are
organized into (1) the architecture library tool, containing libraries
specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
virtualization) and user-space Linux; and (3) the main library pool,
containing a rich set of functionality to build the unikernel from. This
last library includes drivers (both virtual such as netback/netfront and
physical such as ixgbe), filesystems, memory allocators, schedulers,
network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
Python interpreter and debugging and profiling tools. These pools of
libraries constitute a code base for creating unikernels. As shown, a
library can be relatively large (e.g libc) or quite small (a scheduler),
which should allow for a fair amount of customization for the unikernel.
 

The Unicore build tool is in charge of compiling the application and the
selected libraries together to create a binary for a specific platform and
architecture (e.g., Xen 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Stefano Stabellini]

On Mon, 18 Sep 2017, Felipe Huici wrote:
> Hi Lars, all,
> 
> [cc’ing authors of Erlang on Xen, HalVM and Rump].
> 
> Thanks everyone for all of the support and useful comments. We’ve
> incorporated a number of them into a new version of the document (attached
> and pasted at the bottom for convenience) and for those that didn’t make
> it we’re keeping track of them.
> 
> Lars, FYI, Simon also did a blog post regarding Unicore on unikernel.org
> (https://devel.unikernel.org/t/unicore-a-new-unikernel-project/274).
> 
> Please let us know what the next steps are.

The proposal looks good to me.


> Thanks,
> 
> — Felipe
> 
> 
> PROPOSAL: Unicore
> =
> 
> Roles
> -
> Project Leads:Simon Kuenzer  
>  (co-lead)Felipe Huici   
>  (co-lead)Florian Schmidt
> Project Mentor:   Lars Kurth 
> Project Sponsors: Stefano Stabellini 
>   Wei Liu
> 
> Background
> --
> In recent years, several papers and projects dedicated to unikernels
> have shown the immense potential for performance gains that these
> have. By leveraging specialization and the use of minimalistic OSes,
> unikernels are able to yield impressive numbers, including fast
> instantiation times (tens of milliseconds or less), tiny memory
> footprints (a few MBs or even KBs), high network throughput (10-40
> Gb/s), and high consolidation (e.g., being able to run thousands of
> instances on a single commodity server), not to mention a reduced
> attack surface and the potential for easier certification. Unikernel
> projects worthy of mention include MirageOS, ClickOS, Erlang on Xen,
> OSv, HALVM, and Minicache, Rump, among others.
> 
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance
> with unikernels, or no porting effort but decreased performance
> and decreased efficiency with standard OS/VM images.
> The goal of this proposal is to change this status quo by providing
> a highly configurable unikernel code base; we call this base Unicore.
> 
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.
> 
> 
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:
>  
> 
> [Attachment: unicore-oneslider.pdf]
> 
> Figure 1. Unicore Architecture.
> 
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux; and (3) the main library pool,
> containing a rich set of functionality to build the unikernel from. This
> last library includes drivers (both virtual such as netback/netfront and
> physical such as ixgbe), filesystems, memory allocators, schedulers,
> network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
> Python interpreter and debugging and profiling tools. These pools of
> libraries constitute a code base for creating unikernels. As shown, a
> library can be relatively large (e.g libc) or quite small (a scheduler),
> which should allow for a fair amount of customization for the unikernel.
>  
> The Unicore build tool is in charge of compiling the application and the
> selected libraries together to create a binary for a specific platform and
> architecture (e.g., Xen on x86_64). The tool is currently inspired by
> Linux’s kconfig system and consists of a set of Makefiles. It allows users

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Simon Kuenzer]

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 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Simon Kuenzer]

Hey Lars,

On 13.09.2017 18:55, Lars Kurth wrote:

Simon,

It looks to me as if there is some feedback: so it may make some sense to 
incorporate some of it and send out a version 2. We may also want to CC some 
reps from other unikernel projects but Mirage OS. Or you could point them to 
this thread in a separate mail through respective channels or a hub like 
unikernel.org. Whatever you think may work best. It’s your call.


Sounds good. I am going try the unikernel.org hub and contact some 
people individually.




And then have a formal vote, a week after v2 of the proposal. Does this work?


Yes, this will work. I am updating the proposal and will send it out to 
this mailing list, right?


Thanks,

Simon



Lars

On 11/09/2017, 05:08, "Simon Kuenzer"  wrote:

 Hi Alexander,
 
 thanks a lot for your review.
 
 On 10.09.2017 22:48, Alexander Dubinin wrote:

 > Hi Felipe, all,
 >
 > Great that it's going to start :) Looking forward to join :)
 
 I am looking forward to your contributions. ;)
 
 >

 > Just my 2 cents:
 >
 > 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.
 
 >

 > 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?
 
 
 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’ll update the 
document.
 >
 > — Felipe
 >
 > 
 > Dr. Felipe Huici
 > Chief Researcher, Networked Systems and Data
 > 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.hu...@neclab.eu 
 > 
 > NEC Europe Limited Registered Office: NEC 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Lars Kurth]

Simon,

It looks to me as if there is some feedback: so it may make some sense to 
incorporate some of it and send out a version 2. We may also want to CC some 
reps from other unikernel projects but Mirage OS. Or you could point them to 
this thread in a separate mail through respective channels or a hub like 
unikernel.org. Whatever you think may work best. It’s your call.

And then have a formal vote, a week after v2 of the proposal. Does this work?

Lars

On 11/09/2017, 05:08, "Simon Kuenzer"  wrote:

Hi Alexander,

thanks a lot for your review.

On 10.09.2017 22:48, Alexander Dubinin wrote:
> Hi Felipe, all,
> 
> Great that it's going to start :) Looking forward to join :)

I am looking forward to your contributions. ;)

> 
> Just my 2 cents:
> 
> 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.

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


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’ll update the 
document.
> 
> — Felipe
> 
> 
> Dr. Felipe Huici
> Chief Researcher, Networked Systems and Data
> 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.hu...@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"  > wrote:
> 
>  >@Wei, @Stefano,
>  >
>  >On 07/09/2017, 22:16, "Stefano 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Alexander Dubinin]

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?

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 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 :)

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’ll update the
>> document.
>>
>> — Felipe
>>
>> 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Simon Kuenzer]

Hi Alexander,

thanks a lot for your review.

On 10.09.2017 22:48, Alexander Dubinin wrote:

Hi Felipe, all,

Great that it's going to start :) Looking forward to join :)


I am looking forward to your contributions. ;)



Just my 2 cents:

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.




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?



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’ll update the document.

— Felipe


Dr. Felipe Huici
Chief Researcher, Networked Systems and Data
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.hu...@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" > 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


--

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.kuen...@neclab.eu

NEC Europe Ltd | Registered 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Alexander Dubinin]

Hi Felipe, all,

Great that it's going to start :) Looking forward to join :)

Just my 2 cents:

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 :)

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 :)

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’ll update the document.
>
> — Felipe
>
> 
> Dr. Felipe Huici
> Chief Researcher, Networked Systems and Data
> 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.hu...@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"  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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Felipe Huici]

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 Data
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.hu...@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"  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
>

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

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Lars Kurth]

@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

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

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Wei Liu]

Hi Felipe

This is an awesome idea and I'm fully in support of this project. I'm
happy to be a project sponsor alongside Stefano.

Let me know if there is anything I need to do.

Wei.

On Thu, Sep 07, 2017 at 10:25:27AM +, Felipe Huici wrote:
> Dear all,
> 
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’re now submitting a Xen subproject proposal based
> on our Unicore work. Could you please review it?
> 
> Thanks,
> 
> Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.
> 
> 
> PROPOSAL: Unicore
> =
> 
> Roles
> -
> Project Leads: Simon Kuenzer  (main lead)
>Felipe Huici  (co-lead)
>Florian Schmidt  (co-lead)
> Project Mentor:  Lars Kurth 
> Project Sponsor: -To be found-
> 
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
> 
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
> 
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.
> 
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:
>  
> 
> [Attachment: unicore-oneslider.pdf]
> 
> 
> Figure 1. Unicore architecture.
> 
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux; and (3) the main library pool,
> containing a rich set of functionality to build the unikernel from. This
> last library includes drivers (both virtual such as netback/netfront and
> physical such as ixgbe), filesystems, memory allocators, schedulers,
> network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
> Python interpreter and debugging and profiling tools. These pools of
> libraries constitute a code base for creating unikernels. As shown, a
> library can be relatively large (e.g libc) or quite small (a scheduler),
> which should allow for a fair amount of customization for the unikernel.
>  
> 
> The Unicore build tool is in charge of compiling the application and the
> selected libraries together to create a binary for a specific platform and
> architecture (e.g., Xen on x86_64). The tool is currently inspired by
> Linux’s kconfig system and consists of a set of Makefiles. It allows users
> to select libraries, to configure them, and to warn them when library
> dependencies are not met. In addition, the tool can also simultaneously
> generate binaries for multiple 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Felipe Huici]

Hi Stefano,


>>Incubation
>> --
>> The reason behind making Unicore a Xen sub-project project is to (1)
>>bring
>> the existence of Unicore to the attention of the Xen community
>> and to outside world; (2) to attempt to harness interest and potentially
>> development cycles from people and companies interested in
>> unikernels; and (3) to concentrate maintenance resources from people
>> interested in unikernels within the community.
>
>Also (4) to have a legal entity behind the project.

Good point, thanks.

>
>> License
>> ---
>> The main license of the run-time components of Unicore will be a
>>3-clause
>> BSD license, unless there is a good reason not to use it (e.g. we may
>> import 2-clause BSD licensed code from Mini-OS, which we would *not*
>> anticipate to change). The Makefile system would be licensed under GPL
>>v2
>> or later as we want to be able to use KConfig functionality from
>> Buildroot/Linux.
>
>This is genuine question, I am not trying to be provocative: why
>3-clause instead of 2-clause like MiniOS? You might want to add a note
>to explain the reason for this choice.

Ok, we will, thanks. Basically NEC is fairly protective of its name and
logo and we’re forced to use the 3-clause license to make sure that the
name doesn’t for instance get attached to a “bad” product.

Thanks for the feedback!

— Felipe

>> 
>> 
>> 

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

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Roman Shaposhnik]

At a first glance it this appears to be an awesome proposal! I'll give
it a more thorough read over the weekend.

Thanks,
Roman.

On Thu, Sep 7, 2017 at 3:25 AM, Felipe Huici  wrote:
> Dear all,
>
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’re now submitting a Xen subproject proposal based
> on our Unicore work. Could you please review it?
>
> Thanks,
>
> Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.
>
>
> PROPOSAL: Unicore
> =
>
> Roles
> -
> Project Leads: Simon Kuenzer  (main lead)
>Felipe Huici  (co-lead)
>Florian Schmidt  (co-lead)
> Project Mentor:  Lars Kurth 
> Project Sponsor: -To be found-
>
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
>
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
>
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.
>
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:
>
>
> [Attachment: unicore-oneslider.pdf]
>
>
> Figure 1. Unicore architecture.
>
>
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux; and (3) the main library pool,
> containing a rich set of functionality to build the unikernel from. This
> last library includes drivers (both virtual such as netback/netfront and
> physical such as ixgbe), filesystems, memory allocators, schedulers,
> network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
> Python interpreter and debugging and profiling tools. These pools of
> libraries constitute a code base for creating unikernels. As shown, a
> library can be relatively large (e.g libc) or quite small (a scheduler),
> which should allow for a fair amount of customization for the unikernel.
>
>
> The Unicore build tool is in charge of compiling the application and the
> selected libraries together to create a binary for a specific platform and
> architecture (e.g., Xen on x86_64). The tool is currently inspired by
> Linux’s kconfig system and consists of a set of Makefiles. It allows users
> to select libraries, to configure them, and to warn them when library
> dependencies are not met. In addition, the tool can also simultaneously
> generate binaries for multiple platforms.
>
>
> As an example, imagine a user wanting to generate 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Stefano Stabellini]

On Thu, 7 Sep 2017, Felipe Huici wrote:
> Dear all,
> 
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’re now submitting a Xen subproject proposal based
> on our Unicore work. Could you please review it?

Only a couple of comments. I think this proposal is awesome, I want it
yesterday :)


> Thanks,
> 
> Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.
> 
> 
> PROPOSAL: Unicore
> =
> 
> Roles
> -
> Project Leads: Simon Kuenzer  (main lead)
>Felipe Huici  (co-lead)
>Florian Schmidt  (co-lead)
> Project Mentor:  Lars Kurth 
> Project Sponsor: -To be found-
> 
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
> 
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
> 
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.
> 
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:
>  
> 
> [Attachment: unicore-oneslider.pdf]
> 
> 
> Figure 1. Unicore architecture.
> 
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux; and (3) the main library pool,
> containing a rich set of functionality to build the unikernel from. This
> last library includes drivers (both virtual such as netback/netfront and
> physical such as ixgbe), filesystems, memory allocators, schedulers,
> network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
> Python interpreter and debugging and profiling tools. These pools of
> libraries constitute a code base for creating unikernels. As shown, a
> library can be relatively large (e.g libc) or quite small (a scheduler),
> which should allow for a fair amount of customization for the unikernel.
>  
> 
> The Unicore build tool is in charge of compiling the application and the
> selected libraries together to create a binary for a specific platform and
> architecture (e.g., Xen on x86_64). The tool is currently inspired by
> Linux’s kconfig system and consists of a set of Makefiles. It allows users
> to select libraries, to configure them, and to warn them when library
> dependencies are not met. In addition, the tool can also simultaneously
> generate binaries for multiple platforms.
> 
>  
> As an example, imagine a user wanting to generate a network driver domain
> unikernel. In this case, we 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Stefano Stabellini]

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.

Cheers,

Stefano

On Thu, 7 Sep 2017, Lars Kurth wrote:
> Hi all,
> 
> there is a technical issue which still needs resolving: we need a Sponsor. I 
> am thinking of Wei – he would qualify as a Hypervisor Leadership team member 
> and it would have the benefit of making sure that the MiniOS angle is 
> covered. I asked Wei, and he will get back to us once he read the proposal.
> 
> I also want to highlight this proposal at the next AB board meeting, Sept 
> 19th. It would be good, if most feedback could be given in the next week, 
> such that a) we have time to make mods, b) I have a good baseline to share 
> with the AB. I would need to share an updated proposal on the 18th at the 
> latest.
> 
> Technically, the subproject does not need AB approval, as there is no 
> financial impact, but it is always good to have it. 
> 
> Regards
> Lars
> 
> On 07/09/2017, 11:26, "Felipe Huici"  wrote:
> 
> Dear all,
> 
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’re now submitting a Xen subproject proposal based
> on our Unicore work. Could you please review it?
> 
> Thanks,
> 
> Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.
> 
> 
> PROPOSAL: Unicore
> =
> 
> Roles
> -
> Project Leads: Simon Kuenzer  (main lead)
>Felipe Huici  (co-lead)
>Florian Schmidt  (co-lead)
> Project Mentor:  Lars Kurth 
> Project Sponsor: -To be found-
> 
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
> 
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
> 
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.
> 
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:
>  
> 
> [Attachment: unicore-oneslider.pdf]
> 
> 
> Figure 1. Unicore architecture.
> 
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Lars Kurth]

On 07/09/2017, 14:24, "Andrew Cooper"  wrote:
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:

Have you encountered the netbsd rumpkernel project?  I don't it
referenced in your text (apologies if I've missed it).


http://events.linuxfoundation.org/sites/events/files/slides/xdps15-talk-final_0.pdf
is a presentation on from a previous Xen Developer Summit, and

One particular need build solution there was to not alter the build
system of the individual apps, and pass in the rest of the microkernel
as a cross-compile environment.  It's not entirely clear how you plan to
do this part of the building, but anything which involves modifying the
end applications is going to cause a non-trivial maintenance burden.

I don’t think we have to answer design questions up-front. Although it may make 
sense, to track some key open design and architectural decisions in a section 
at the end of the document, such that they are not forgotten.

> [Attachment: unicore-oneslider.pdf]
>
>
> Figure 1. Unicore architecture.
>
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux;

On the x86 Xen side of things, you should treat PV and HVM guests as
different platforms, and their tradeoffs are quite different.

The one semi-supported microkernel in the Xen world is stub-qemu, and in
principle this does give better isolation than qemu running in dom0, but
it also exposes other attack surfaces.  If you assume an HVM guest has
compromised its stub-qemu, it means that security issues exposed only to
PV guests are within the reach of an HVM guest.  In this circumstance,
having an HVM stub qemu would give the system a reduced attack surface
compared to a PV stub qemu.

I think this question could also be treated like an open design/architecture 
decision which should be recorded.

Lars

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

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Lars Kurth]

Hi all,

there is a technical issue which still needs resolving: we need a Sponsor. I am 
thinking of Wei – he would qualify as a Hypervisor Leadership team member and 
it would have the benefit of making sure that the MiniOS angle is covered. I 
asked Wei, and he will get back to us once he read the proposal.

I also want to highlight this proposal at the next AB board meeting, Sept 19th. 
It would be good, if most feedback could be given in the next week, such that 
a) we have time to make mods, b) I have a good baseline to share with the AB. I 
would need to share an updated proposal on the 18th at the latest.

Technically, the subproject does not need AB approval, as there is no financial 
impact, but it is always good to have it. 

Regards
Lars

On 07/09/2017, 11:26, "Felipe Huici"  wrote:

Dear all,

Following up on discussions that Simon Kuenzer had with several of you at
the last Xen summit, we’re now submitting a Xen subproject proposal based
on our Unicore work. Could you please review it?

Thanks,

Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.


PROPOSAL: Unicore
=

Roles
-
Project Leads: Simon Kuenzer  (main lead)
   Felipe Huici  (co-lead)
   Florian Schmidt  (co-lead)
Project Mentor:  Lars Kurth 
Project Sponsor: -To be found-

Background
--
In recent years, several papers and projects dedicated to unikernels have
shown the immense potential for performance gains that these have. By
leveraging specialization and the use of minimalistic OSes, unikernels are
able to yield impressive numbers, including fast instantiation times (tens
of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
high network throughput (10-40 Gb/s), and high consolidation (e.g., being
able to run thousands of instances on a single commodity server), not to
mention a reduced attack surface and the potential for easier
certification. Unikernel projects worthy of mention include MirageOS,
ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.

The fundamental drawback of unikernels is that they require that
applications be manually ported to the underlying minimalistic OS (e.g.
having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
requires both expert work and often considerable amount of time. In
essence, we need to pick between either high performance with unikernels,
or no porting effort but decreased performance and decreased efficiency
with standard OS/VM images. The goal of this proposal is to change this
status quo by providing a highly configurable unikernel code base; we call
this base Unicore.

This project also aims to concentrate the various efforts currently going
on in the Xen community regarding minimalistic OSes (essentially different
variants of MiniOS). We think that splitting the community across these
variants is counter-productive and hope that Unicore will provide a common
place for all or most improvements and customizations of minimalistic
OSes. The long term goal is to replace something like MiniOS with a tool
that can automatically build such a minimalistic OS.

Unicore - The "Unikernel Core"
-
The high level goal of Unicore is to be able to build unikernels targeted
at specific applications without requiring the time-consuming, expert work
that building such a unikernel requires today. An additional goal (or
hope) of Unicore is that all developers interested in unikernel
development would contribute by supplying libraries rather than working on
independent projects with different code bases as it is done now. The main
idea behind Unicore is depicted in Figure 1 and consists of two basic
components:
 

[Attachment: unicore-oneslider.pdf]


Figure 1. Unicore architecture.

 
Library pools would contain libraries that the user of Unicore can select
from to create the unikernel. From the bottom up, library pools are
organized into (1) the architecture library tool, containing libraries
specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
virtualization) and user-space Linux; and (3) the main library pool,
containing a rich set of functionality to build the unikernel from. This
last library includes drivers (both virtual such as netback/netfront and
physical such as ixgbe), filesystems, memory allocators, schedulers,
network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
Python interpreter and debugging 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Andrew Cooper]

On 07/09/17 11:25, Felipe Huici wrote:
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
>
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
>
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.

I thoroughly approve of a project along these lines.  Microkernels have
huge potential to offer, but they are sufficiently complicated to work
with that very few people can.

>
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:

Have you encountered the netbsd rumpkernel project?  I don't it
referenced in your text (apologies if I've missed it).

http://events.linuxfoundation.org/sites/events/files/slides/xdps15-talk-final_0.pdf
is a presentation on from a previous Xen Developer Summit, and

One particular need build solution there was to not alter the build
system of the individual apps, and pass in the rest of the microkernel
as a cross-compile environment.  It's not entirely clear how you plan to
do this part of the building, but anything which involves modifying the
end applications is going to cause a non-trivial maintenance burden.

>  
>
> [Attachment: unicore-oneslider.pdf]
>
>
> Figure 1. Unicore architecture.
>
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux;

On the x86 Xen side of things, you should treat PV and HVM guests as
different platforms, and their tradeoffs are quite different.

The one semi-supported microkernel in the Xen world is stub-qemu, and in
principle this does give better isolation than qemu running in dom0, but
it also exposes other attack surfaces.  If you assume an HVM guest has
compromised its stub-qemu, it means that security issues exposed only to
PV guests are within the reach of an HVM guest.  In this circumstance,
having an HVM stub qemu would give the system a reduced attack surface
compared to a PV stub qemu.

>  and (3) the main library pool,
> containing a rich set of functionality to build the unikernel from. This
> last library includes drivers (both virtual such as netback/netfront and
> physical such as ixgbe), filesystems, memory allocators, schedulers,
> network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
> Python interpreter and debugging and profiling tools. These pools of
> libraries constitute a code base for creating unikernels. As shown, a
> library can be relatively large (e.g libc) or quite small (a scheduler),
> which should allow for a fair amount