vm-superio provides emulation for legacy devices. For now, it offers this
support only for the
Linux serial console, a minimal
i8042 PS/2 Controller and
an
ARM PL031 Real Time Clock.
To enable snapshot use cases, such as live migration, it also provides support
for saving and restoring the state, and for persisting it.
In order to achieve this, and to keep a clear separation of concerns,
vm-superio is a
workspace,
containing the following crates:
vm-superio- which keeps the state of the component;vm-superio-ser- which mirrors the state structure fromvm-superioand adds the required version constraints on it, and derives/implements the required (de)serialization traits (i.e.serde'sSerializeandDeserialize;Versionize).
The console emulation is done by emulating a simple UART 16550A serial port with a 64-byte FIFO. This UART is an improvement of the original UART 8250 serial port, mostly because of the FIFO buffers that allow storing more than one byte at a time, which, in virtualized environments, is essential.
For a VMM to be able to use this device, besides the emulation part which is covered in this crate, the VMM needs to do the following operations:
- add the serial port to the Bus (either PIO or MMIO)
- define the serial backend
- event handling (optional)
The following UART registers are emulated via the
Serial structure: DLL, IER, DLH, IIR, LCR,
LSR, MCR, MSR and SR (a brief, but nice presentation about these,
here).
The Fifo Control Register (FCR) is not emulated; there is no support yet for
directly controlling the FIFOs (which, in this implementation, are always
enabled). The serial console implements only the RX FIFO (and its
corresponding RBR register). The RX buffer helps in testing the UART when
running in loopback mode and for sending more bytes to the guest in one shot.
The TX FIFO is trivially implemented by immediately writing a byte coming from
the driver to an io::Write object (out), which can be, for example,
io::Stdout or io::Sink. This object has to be provided when
initializing the serial console.
A Trigger object is the currently used mechanism for notifying the driver
about in/out events that need to be handled.
Trusted actors:
- host kernel
Untrusted actors:
- guest kernel
- guest drivers
The untrusted actors can change the state of the device through reads and writes on the Bus at the address where the device resides.
| #NR | Threat | Mitigation |
|---|---|---|
| 1 | A malicious guest generates large memory allocations by flooding the serial console input. CVE-2020-27173 | The serial console limits the number of elements in the FIFO corresponding to the serial console input to FIFO_SIZE (=64), returning a FIFO Full error when the limit is reached. This error MUST be handled by the crate customer. When the serial console input is connected to an event loop, the customer MUST ensure that the loop is not flooded with events coming from untrusted sources when no space is available in the FIFO. |
| 2 | A malicious guest can fill up the host disk by generating a high amount of data to be written to the serial output. | Mitigation is not possible at the emulation layer because we are not controlling the output (Writer). This needs to be mitigated at the VMM level by adding a rate limiting mechanism. We recommend using as output a resource that has a fixed size (e.g. ring buffer or a named pipe). |
The interaction between the serial console and its driver, at the emulation
level, is done by the two read and write specific methods, which handle
one byte accesses. For sending more input, enqueue_raw_bytes can be used.
The i8042 PS/2 controller emulates, at this point, only the CPU reset command which is needed for announcing the VMM about the guest's shutdown.
This module emulates the ARM PrimeCell Real Time Clock (RTC) PL031. The PL031 provides a long time base counter with a 1HZ counter signal and a configurable offset.
This implementation emulates all control, peripheral ID, and PrimeCell ID registers; however, the interrupt based on the value of the Match Register (RTCMR) is not currently implemented (i.e., setting the Match Register has no effect).
For a VMM to be able to use this device, the VMM needs to do the following:
- add the RTC to the Bus (either PIO or MMIO)
- provide a structure that implements RTCEvents to track the occurrence of significant events (optional)
Note that because the Match Register is the only possible source of an event, and the Match Register is not currently implemented, no event handling is required.
Trusted actors:
- host kernel
Untrusted actors:
- guest kernel
- guest drivers
The untrusted actors can change the state of the device through reads and writes on the Bus at the address where the device resides.
| #NR | Threat | Mitigation |
|---|---|---|
| 1 | A malicious guest writes invalid values in the Load Register to cause overflows on subsequent reads of the Data Register. | The arithmetic operations in the RTC are checked for overflows. When such a situation occurs, the state of the device is reset. |
| 2 | A malicious guest performs reads and writes from invalid offsets (that do not correspond to the RTC registers) to cause crashes or to get access to data. | Reads and writes of invalid offsets are denied by the emulation, and an invalid_read/write event is called. These events can be implemented by VMMs, and extend them to generate alarms (and for example stop the execution of the malicious guest). |
This support is offered for the Rtc and the Serial devices by the following
abstractions:
<Device>State-> which keeps the hardware state of the<Device>;<Device>StateSer-> which can be used by customers who need a<Device>Statethat is also(De)Serializeand/orVersionize. If the customers want a different state than the upstream one, then they can implementFrom(or similar mechanisms) in their products to convert the upstream state to the desired product state.
A detailed design document for the save/restore state support in rust-vmm can be found here.
Each time there's a change in a state from vm-superio, that change needs to
be propagated in the corresponding state from vm-superio-ser. To keep the
compatibility between the release versions of these two crates, once we have a
new release of vm-superio that implied a change in vm-superio-ser, we need
to have a new release of vm-superio-ser as well.
Therefore, the vm-superio-ser crate has an exact version of vm-superio as
dependency.
This project is licensed under either of
- Apache License, Version 2.0
- BSD-3-Clause License