[Qemu-devel] [RFC] Device sandboxing

[Corey Bryant]

A group of us are starting to work on sandboxing QEMU device emulation
code.  We're just getting started investigating various approaches, and
want to engage the community to gather input.

Following are the design points that we are currently considering:

* Decompose QEMU into multiple processes:

    * This could be done such that QEMU devices execute in separate
      processes based on device type, e.g. all block devices in one
      process and all network devices in a second process.  Another
      alternative is executing a separate process per device.

    * Decomposition would not only afford a level of security inherent
      in process separation, it would also allow development of stricter
      sVirt/SELinux policy for the decomposed QEMU processes (e.g. a
      block device specific policy).  This would enable a true sandbox
      with layers of defense.

* Decompose the device emulation process further into an untrusted and
  trusted thread:

    * The untrusted thread would be restricted by seccomp mode 1 and
      would contain the device emulation code.

    * The trusted helper thread would run beside the untrusted thread,
      enabling the untrusted thread to make syscalls beyond read(),
      write(), exit(), and sigreturn().

* IPC communication mechanisms:

    * An IPC mechanism will be required to enable communication between
      untrusted and trusted threads.

    * An IPC mechanism will also be required to enable communication
      between the main QEMU process and device processes.

    * The communication mechanisms must provide secure communication,
      be low overhead (easy to generate, parse, and validate), and must
      play well with sVirt/LSMs.

    * Some thoughts for IPC mechanisms are Unix sockets, pipes, virtio,
      Google Native Client's IMC, and shared memory.

* If seccomp mode 2 support becomes available, decomposition of device
  emulation into untrusted/trusted threads may not be necessary.  This
  could result in improved performance (no IPC overhead between trusted
  and untrusted thread) and reduced complexity (no need for trusted
  helper thread).

* Execution of QEMU with the sandboxed device support should be an
  optional run-time specification.

* We will be focusing on legacy devices first, both for performance and
  risk reasons.

Once we settle on a direction, we will develop a proof of concept to
share with the community.

We appreciate your input.

Regards,

Ashley Lai
Corey Bryant
Eduardo Otubo
Michael Halcrow
Paul Moore
Richa Marwaha