...
- If the platform implements virtual networking, it shall also use the virtio-net required interface between drivers and Hypervisor.
- If the platform implements vsock, it shall also use the virtio-vsock required API between drivers and Hypervisor.
- Virtual network interfaces shall be exposed as the operating system's standard network interface concept, i.e. they should show up as a normal network device.
- The hypervisor/equivalent shall provide the ability to dedicate and expose any hardware network interface to one virtual machine.
- The hypervisor/equivalent shall(?) be able to configure virtual inter-vm networking interfaces.
- Implementations of virtio-net shall support the VIRTIO_NET_F_MTU feature flag
- Implementations of virtio-net shall support the VIRTIO_NET_F_MAC feature flag
- Implementations of virtio-net shall support the VIRTIO_NET_F_CTRL_MAC_ADDR feature flag
Move vsock part to separate (sub)chapter. Maybe common chapter name should be Communication? Inter-VM communication might not be searched within the networking chapter.
Discussion:
Virtual network interfaces ought to be exposed to user space code in the guest OS as standard network interfaces. This minimizes custom code appearing because of the usage of virtualization is minimized.
...
3.3.2 GPU Device in 3D Mode
3D mode will offload rendering operations to the host gpu and therefore requires a gpu with 3D support on the host machine. The guest side requires additional software in order to convert OpenGL commands to the raw graphics stack state (Gallium state) and channel them through virtio-gpu to the host. Currently the 'mesa' library is used for this purpose. The backend then receives the raw graphics stack state and interprets it using the virglrenderer library from the raw state into an OpenGL form, which can be executed as entirely normal OpenGL on the host machine. The host also translates shaders from the TGSI format used by Gallium into the GLSL format used by OpenGL.
Changes expected
These requirements are likely to change as VIRTIO-VULKAN is introduced. We expect the virtual platform interface to be VULKAN based without relation to OpenGL (which will exist only in the layers above).
...
---------- > CHECK IF CHAPTER NUMBERS ARE VALID FOR VIRTIO 1.1
Virtqueues.
REQ-2: The virtqueues MUST be set up according to the requirement in chapter 5.7.2 in [VIRTIO-GPU].
...
Random number generation is typically created by a combination of a true-random and pseudo-random implementations. A pseudo-random generation algorithm is implemented in software. "True" random values may be acquired by a hardware-assisted device, or a hardware (noise) device may be used to acquire a random seed which is then further used by a pseudo-random algorithm.
Requirement:
- The virtual platform SHALL provide VMs with access to a hardware-assisted high quality random number generator through the operating system's preferred interface.
(/dev/random device on Linux) - TODO, improve this:
The virtual platform should describe a security analysis of how to avoid any type of side-band analysis of the random number generation.
* The Hypervisor MUST offer at least one good entropy source accessible from the guest
* The entropy source SHOULD be implement using virtio-entropy * The Hypervisor MUST offer at least one good entropy source accessible from the guest
* The entropy source SHOULD be implement using virtio-entropy according to VIRTIO TBD
* To be specific, it is required that what is received from the implementation of virtio-entropy must contain only entropy and never the result of a pseudo random generator.
Discussion:
Crypt device has been added to VIRTIO (crypto accelerator for ciphers, hashes, MACs, AEAD)
Sharing of crypto accelerators. On ARM they are often they are only accessible from TrustZone, and also stateful as opposed to stateless. Both of these things make sharing difficult.
Usable for filesystem encryption? Although CPU might be just as performant.
virtio-entropy (called virtio-rng inside Linux implementation) is preferred because it's a simple and cross-platform interface to deal with.
Some hardware implements only one RNG in the system and it is in TrustZone. It is inconvenient to call APIs into TrustZone in order to get a value that could just be read from the hardware but on those platforms it is the only choice. While it would possible to implement virtio-entropy via this workaround, it is more convenient to make direct calls to TrustZone.
TEE access
Discussion:
The virtual platform is generally expected to provide access to a hardware-assisted high quality random number generator through the operating system's preferred interface (/dev/random device on Linux)
The virtual platform should describe a security analysis of how to avoid any type of side-band analysis of the random number generation.
TEE access
Discussion:
Access to TrustZone and equivalent functions SHOULD work in the exact same way as for a native system using the standard access methods (Access to TrustZone and equivalent functions SHOULD work in the exact same way as for a native system using the standard access methods (SMC
calls on ARM, equivalent on Intel). Another option used on some Intel systems is to run OPTEE instances, one per guest. The rationale for this is that implementations that have been carefully crafted for security (e.g. Multimedi DRM) are unlikely to be rewritten only to support virtualization.
Requirement:
* Access to TrustZone and equivalent functions MUST work in the exact same way as for a native system using the standard access methods (SMC calls on ARM, equivalent on Intel).
RPMB
Changes expected
Discussion
Note: Virtual rpmb recently proposed on VIRTIO mailing list (from Intel)
Different guests need their own unique Strictly Monotonic Counters. It's not expected for counters to increase by more than one, which could happen if more than one guest share the same mechanism.
RequirementsPotential future requirements (still pending) :
* If a system requires replay protection, it MUST be implement according to virtio-rpmb as specified in [VIRTIO-future]
...
Requirement
* If the hardware platform implements crypto acceleration, then the virtual platform MUST implement virtio-crypto as specified in chapter 5.9 in [VIRTIO]
TODO: Please consider if this should be a MUST or a weaker requirement.
Discussion
The implementation consideration is analogous to the discussion on RNGs. On some hardware these are offered only within TrustZone and in addition the hardware implementation is stateful. It ought to be possible to implement virtio-crypto also by delegation into TrustZone and therefore we require it also on such platforms .
N.B. Some guest implementations may still choose to access these features via calling into TrustZone implementations directly.however it should be understood that parallell access to this feature may not be possible, meaning that this device can be occupied when a guest requests it. This must be considered in the complete system design.
To be reviewed one more time with MattiTODO: Please consider if this should be a MUST or a weaker requirement.
6. Supplemental Virtual Device categories
...
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 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.
- For security reasons, text consoles MUST be possible to shut off entirely in the configuration of a production system.
This configuration SHALL NOT be modifiable from within any guest operating system
...
