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