Page History

...

5. Supplemental Virtual Device categories

5.x  Text Console

Discussion

While they may be rarely an appropriate interface for the normal operation of the automotive system, text consoles are expected to be present for development purposes.It is expected that the   The  virtual interface of the console is adequately defined by [VIRTIO] and this specification specifies to follow that standard, in so far as it fits with the chosen guest operating system:

Requirements:

Text consoles are often connected to a shell capable of running commmands.  For security reasons, text consoles need to be possible to shut off entirely in the configuration of a production system. 

Requirements:

• The  virtual interface of the console MUST be implemented according to chapter 5.3 in [VIRTIO] 

• To not impede efficient development, text consoles shall further be integrated according to the operating systems' normal standards so that they can be connected to any normal development flow.
• Text consoles are often connected to a shell capable of running commmands.  For security reasons, text consoles MUST be possible to shut off entirely in the configuration of a production system. 
  This configuration MUST SHALL NOT be not modifiable from within any guest operating system.

It is also recommended that

...

technical and/or process related countermeasures which ensure there is no way to forget to disable these consoles

...

, are introduced and documented during the development phase.

5.1 HostFilesystem virtualization

Discussion

This chapter discusses two different features, one being  host-to-vm filesystem sharing Rationaleand the other being VM-to-VM sharing, which can be facilitated by Hypervisor functionality.

The function of providing disk access in the form of a "shared folder" or full disk passthrough is a function that seems more used for desktop virtualization than in the embedded systems that this document is for.  In desktop virtualisation, for example the user wants to run Microsoft Windows in combination with a MacOS host, or to run Linux in a virtual machine on a Windows-based corporate workstation, or bespoke Linux systems run in KVM/QEMU on Linux host for development of embedded systems.  Host-to-VM filsystem sharing might also serve some purpose also in certain server virtualization setups. With this background, we consider Host-to-VM filesharing an optional feature and cover it only briefly here.

...

9pfs is a minimalistic network file-system protocol that our working group figures is appropriate for the task. Other network protocols like NFS, could be used for simple HV-to-VM exposure of file system, where performance is not critical. Other network protocols like NFS, SMB/SAMBA etc. would be too heavy to implement in the HV-VM boundary, but are still an option between VMs.  9pfs has known performance problems however but running 9pfs over vsock could be an optimization option.   9pfs feels a bit esoteric, and while "reinventing" is usually unnecessary there might be an appropriate opportunity to do that here, with a new modern protocol plus, a reference open-source implementation. It ought to take a closer look particularly at a seems lacking in a flexible and reliable security model, which seem somewhat glossed over in the 9pfs description:  It briefly references only "fixed user" or "pass-through" for mapping ownership on files in guest/host.

Requirements:

...

The recently introduced virtio-fs uses the FUSE protocol over VIRTIO.  Using FUSE means reusing a proven and stable interface.  It furthermore guarantees expected POSIX filesystem semantics also when multiple VMs operate on the same file system (which file-sharing approaches like 9pfs may either not guarantee or implement in a very inefficient way).    Optimizations of VM-to-VM sharing will be possible by using shared memory as being defined in VIRTIO 1.2.  File system operations on data that is cached in memory will then be very fast also between VMs.

It is uncertain if file system sharing is truly a desired feature in typical automotive end products but the new capabilities might open up a desire to use this to solve use-cases that were previously not considering shared filesystem as the mechanism.   Software update use-cases might have the Hypervisor in charge of actually modifying critical software sections (boot, etc. but could include the VM software as well).   For this use case, download of software could be delegated to a VM which has advanced capabilities for networking and other operations, but the HV is still in charge of checking software authenticity (after locking VM access to the data) and then doing the actual update.    In the end, using filesystem sharing is an open design choice since the data exchange between VM and HV could alternatively be handled by some other network protocol.

Links: Virtio 1.0 spec : {PCI-9P, 9P device type}.
Kernel support: Xen/Linux 4.12+ FE driver Xen implementation details

Some found 9pfs references includedinclude:
(Links are not provided since we cannot at the moment evaluate the completeness, or if these should be considered official specification).

• A set of man pages that seem to be the definition of P9.  
• QEMU instruction how to set up a VirtFS (P9).  
• Example/info how to natively mount a 9P network filesystem.
• Source code for 9pfs FUSE driver

Requirements:

• If filesystem virtualization is implemented then virtio-fs, implemented according to XXX, MUST be one of the supported choices.

3. References

    [RFC 2119] https://www.ietf.org/rfc/rfc2119.txt

...