Lib.rs

› Hardware support › vm-superio
#serialization #versioning #deserialize #superio

vm-superio-ser

Serialization for legacy device states

Owned by Andreea Florescu, Jonathan Woollett-Light, rust-vmm, Laura Loghin, roypat.

4 releases (breaking)

0.4.0 Apr 25, 2024
0.3.0 Nov 11, 2022
0.2.0 Apr 15, 2022
0.1.0 Oct 26, 2021

#485 in Hardware support

Apache-2.0 OR BSD-3-Clause

120KB
1.5K SLoC

vm-superio

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 from vm-superio and adds the required version constraints on it, and derives/implements the required (de)serialization traits (i.e. serde's Serialize and Deserialize; Versionize).

Serial Console

Design

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.

Threat model

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).

Usage

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.

i8042 PS/2 Controller

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.

ARM PL031 Real Time Clock

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.

Threat model

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).

Save/restore state support

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>State that is also (De)Serialize and/or Versionize. If the customers want a different state than the upstream one, then they can implement From (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.

Compatibility between vm-superio and vm-superio-ser versions

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.

License

This project is licensed under either of

Dependencies

~1–1.6MB
~35K SLoC