[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxx <mailto:Felipe.Huici@xxxxxxxxx>
        <mailto:Felipe.Huici@xxxxxxxxx <mailto:Felipe.Huici@xxxxxxxxx>>>
        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@xxxxxxxxx <mailto:felipe.huici@xxxxxxxxx>
        <mailto:felipe.huici@xxxxxxxxx <mailto:felipe.huici@xxxxxxxxx>>
             ============================================================
             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@xxxxxxxxxx
        <mailto:lars.kurth@xxxxxxxxxx>
             <mailto:lars.kurth@xxxxxxxxxx
        <mailto:lars.kurth@xxxxxxxxxx>>> wrote:

              >@Wei, @Stefano,
              >
              >On 07/09/2017, 22:16, "Stefano Stabellini"
        <sstabellini@xxxxxxxxxx <mailto:sstabellini@xxxxxxxxxx>
             <mailto:sstabellini@xxxxxxxxxx
        <mailto:sstabellini@xxxxxxxxxx>>> 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@xxxxxxxxx <mailto:simon.kuenzer@xxxxxxxxx>
    ============================================================
    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@xxxxxxxxx
============================================================
NEC Europe Ltd | Registered Office: Athene, Odyssey
Business Park, West End Road, London, HA4 6QE, GB
Registered in England 2832014

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.