Re: [Xen-API] [MirageOS-devel] ViryaOS: proposal for a new Xen Project sub-project

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

Thank you, Lars.

On Fri, 18 May 2018, Lars Kurth wrote:
> Hi Stefano,
> what we also need for the project proposal are
> 
> Sponsor: A sponsor can be a member of the project leadership team of a mature 
> project, a member of the advisory board or the
> community manager. This ensures that a distinguished community member 
> supports the idea behind the project.
> I would suggest that maybe someone from ARM (e.g. Thomas - member of the AB, 
> or Julien - leadership team member) sponsors the
> project. There is no work involved.
> 
> Mentor: I am happy to pick this up
> 
> Regards
> Lars
> 
> 
>       On 17 May 2018, at 23:31, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
> wrote:
> 
> Hi all,
> 
> Following up from previous conversations with the committers, I am
> appending a proposal for a new Xen Project sub-project aimed at embedded
> and IoT. Let me know if you have questions or suggestions. Also,
> sponsors are very welcome! :-)
> 
> 
> What do you mean by sponsors in this context? A sponsor as required by the 
> process, or a show of hand as to who would be
> interested in participating in the effort? Or something else?
> 
> 
>       FYI, I also have a presentation on ViryaOS at Xen Developer Summit, I am
>       looking forward to it!
> 
>       Cheers,
> 
>       Stefano
> 
>       ---
> 
> 
>       # ViryaOS
> 
>       ## Mission
> 
>       To create and support open source Xen based tools that help users build
>       end-to-end secure embedded systems.
> 
> 
>       ## The Problem
> 
>       Xen enables highly secure, flexible architectures, suitable for widely
>       different embedded use-cases, from industrial to IoT and cloud. However,
>       putting a Xen based system together is still a complex endeavor. It is
>       even harder to configure it to be as secure as possible. In the Xen
>       ecosystem, we lack a unifying effort to help with the integration
>       challenges that anybody building Xen-based systems is facing. Setting up
>       a Xen based system takes too long and it is too hard for both users and
>       developers.
> 
>       Today, many of us are spending time, effort and money to maintain their
>       own build systems and techniques for generating VM configurations,
>       resulting in significant duplication of efforts. These scripts and tools
>       could be more powerful if we worked on them together. It would cost
>       less to maintain them as a shared project, and eventually, they would be
>       more flexible and of better quality.
> 
> 
>       ## The Solution
> 
>       The solution is to unify our efforts behind a single open source
>       project, that will focus our collective development efforts on a shared
>       set of components.
> 
>       The new project is ViryaOS, a multi-vendor open source collaborative
>       effort. ViryaOS will create a highly secure easy-to-use development
>       platform for Xen based systems aimed at IoT and embedded environments.
>       It will make it easier for engineers to develop secure Xen-based
>       platforms. In addition, ViryaOS will produce ready-to-use binary images
>       to help users and system integrators get started with Xen
>       on embedded systems.
> 
>       ViryaOS will provide the space for us and others to collaborate. As a
>       unified group, it will be easier to approach hardware vendors and
>       partners to discuss support for ViryaOS.
> 
>       Users will be able to build and deploy Xen-based disaggregated
>       architectures quickly and easily on x86 and ARM SoCs. ViryaOS will 
> support
>       as many hardware platforms as possible, as many guest operating systems
>       as possible (including RTOSes and proprietary OSes), and highly
>       heterogeneous environments. ViryaOS will meet low power consumption
>       requirements.
> 
>       ViryaOS will be secure out of the box. Unlike traditional operating
>       system designs based on a monolithic kernel, ViryaOS takes a microkernel
>       approach. ViryaOS will come with driver and service domains. The
>       security and manageability of the platform are achieved through security
>       by compartmentalization and privilege separation to minimize the attack
>       surface of the "supervisor" component (the part of the system capable of
>       unconstrained access to the underlying hardware).
> 
>       All workloads will be supported. Virtual machines, containers, baremetal
>       applications and unikernels will all be first-class "applications"
>       running on ViryaOS. ViryaOS will support running containers natively and
>       securely by transparently spawning Xen virtual machines for isolation.
> 
> 
>       ## Build and Output
> 
>       ViryaOS will come with the tools to build Xen, Dom0, multiple VMs (with
>       or without device assignement) and assemble the complete system. The
>       build will rely on containers to shorten the build time and to make it
>       easier to reuse any single component. The output will include the
>       following binaries:
> 
>       * Xen
>       * the Dom0 kernel (Linux)
>       * the Dom0 filesystem
>       * a disaggregated set of Service Domains, including their kernels,
>        disk images and configurations (Service Domains include drivers
>        domains and management VMs)
>       * any number of user-provided containers and VMs
> 
>       The result will be a ready-to-use system image with all the pieces
>       already included. The image will be small, suitable for embedded systems
>       and IoT.
> 
>       Users will be able to select different components and configurations at
>       build time, resulting in different outputs. Cross-compilation will be
>       supported.
> 
>       ViryaOS will be able to use Yocto and/or existing distros such as Alpine
>       Linux to build some, or all, of its components. Anything could be used
>       as long as it can be built inside a container and the output follows a
>       specified format.
> 
>       As the key enabler for Service Domains, device assignment will be
>       supported on both ARM and x86 to the best of the capabilities of the
>       hardware. The image will contain all the necessary configurations
>       (device tree manipulations, Xen command line arguments, etc) to make
>       device assignment work out of the box.
> 
> 
>       ## Security
> 
>       Security is one of ViryaOS's key attributes. The hardware capabilities
>       can differ for different boards, with some having TPM support and other
>       TEE (trusted execution environment) support. When the hardware supports
>       it, ViryaOS will use secure/measured boot on Intel and ARM, using the
>       best technologies available in hardware (such as Intel TXT and ARM
>       TrustZone).
> 
> 
>       ## Hardware Support
> 
>       ViryaOS will support as many hardware platforms as possible, x86 and ARM
>       (ARMv8). Given that TPM and VT-d are (almost) ubiquitous on Intel
>       platform, they can be requirements for ViryaOS. On the ARM side, many
>       SoCs don't have equivalent functionalities yet (SMMU and TEE). ViryaOS
>       will support running on them, although with limited functionalities.
> 
>       ### x86 Requirements
>       * Intel VT-x or AMD-V
>       * 1G RAM
>       * Intel VT-d or AMD-Vi
>       * Intel TPM
>       * 1 serial port for development
> 
>       ### ARM Requirements
>       #### Hard Requirements
>       * ARMv8 (Xen 64-bit)
>       * 1G RAM or better
>       * 1 network interface
> 
>       #### Soft Requirements
>       * SMMU and a Xen driver, for device assignment (today only ARM
>        SMMUv1 and SMMUv2 are supported in Xen)
>       * TPM-like functionalities for secure key storage and secure boot
>       * 1 serial port for development
>       * Device Tree for firmware tables
> 
> 
>       ## Open Source
> 
>       ViryaOS is a multi-vendor collaborative open source project. ViryaOS
>       will consume other upstream projects, such as the Linux kernel, Xen
>       Project, Alpine Linux, and Yocto. For convenience, ViryaOS might use
>       private clones of these repositories, but ViryaOS will not diverge from
>       upstream in any meaningful way. Changes to ViryaOS's private clones of
>       upstream repositories will only be temporary, small-scoped and
>       inconsequential.  ViryaOS will remain as close as possible to upstream
>       Xen and Linux.
> 
> 
>       ## Certifications
> 
>       For many ViryaOS use-cases safety certifications are critical. As an
>       open source project, ViryaOS will attempt at producing an easily
>       certifiable software stack.
> 
> 
>       ## License
> 
>       A permissive license is the best fit for this project. Apache 2.0 is the
>       option of choice because of the clause covering patents.
> 
> 
>       ## Roles
> 
>       Project Lead: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> 
>       _______________________________________________
>       MirageOS-devel mailing list
>       MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>       https://lists.xenproject.org/mailman/listinfo/mirageos-devel
> 
> 
> 
>

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-api