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@kernel.org> 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@kernel.org>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/mirageos-devel
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@kernel.org> 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@kernel.org>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/mirageos-devel