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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 07/09/2017, 14:24, "Andrew Cooper" <Andrew.Cooper3@xxxxxxxxxx> 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-api mailing list
Xen-api@xxxxxxxxxxxxx
https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api