Limit types that can be read from guest memory

Not all types are safe to read from guest memory.  Any type with a
reference or pointer will be initialized to random bits that don't refer
to a valid address.  This can cause dangling pointer and general
unsafe behavior.

To fix this, limit types that can be read with read_obj to those that
implement the unsafe trait `DataInit`.  Provide implementations of
`DataInit` for intrinsic types that are obviously safe to initialize
with random data.

Implement the needed traits for bootparam types as they are read from
the kernel image directly.

Change-Id: I1040f5bc1b2fc4c58c87d8a2ce3f618edcf6f9b1
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/540750
Reviewed-by: Zach Reizner <zachr@chromium.org>
6 files changed
tree: 0180ba9aaec5211b367b2656775a82dac2fe736f
  1. data_model/
  2. io_jail/
  3. kernel_loader/
  4. kvm/
  5. kvm_sys/
  6. src/
  7. sys_util/
  8. syscall_defines/
  9. x86_64/
  10. .gitignore
  11. LICENSE
  12. README.md
README.md

Chrome OS KVM

This component, known as crosvm, runs untrusted operating systems along with virtualized devices. No actual hardware is emulated. This only runs VMs through the Linux's KVM interface. What makes crosvm unique is a focus on safety within the programming language and a sandbox around the virtual devices to protect the kernel from attack in case of an exploit in the devices.

Overview

The crosvm source code is organized into crates, each with their own unit tests. These crates are:

  • kvm-sys low-level (mostly) auto-generated structures and constants for using KVM
  • kvm unsafe, low-level wrapper code for using kvm-sys
  • crosvm the top-level binary front-end for using crosvm

Usage

Currently there is no front-end, so the best you can do is run cargo test in each crate.