27a413a59a
Add a new `devices` command to start one or several jailed vhost-user
devices.
`devices` improves upon `device` in the following ways:
* Several devices can be created in one command,
* Devices can be configured with the same arguments as the `run` command,
* The created devices are jailed similarly to the `run` command.
This CL does not enable any device to be started yet, it only does the
plumbing to allow it. Follow-up CLs will start adding devices to this
command.
With the following CL, the serial device can be tested as follows:
$ ./crosvm devices --serial hardware=virtio-console,console,stdin,type=stdout,earlycon,vhost=/tmp/vu-serial
The parameters of the `serial` argument are the same as with `crosvm
run`, with the exception that the `vhost` parameter needs to be provided
to inform where the listener should await its front-end connection.
`vhost` can either take a PCI device address, in which case VVU will be
used, or a socket path for regular vhost-user.
Using the example above, a VMM can connect to /tmp/vu-serial and use it
as a console device.
BUG=b:218223240
TEST=./crosvm devices --serial hardware=virtio-console,console,stdin,type=stdout,earlycon,vhost=/tmp/vu-serial
gives us a working vhost-user serial device.
TEST=Same command as above ran inside a VVU device VM with vhost=<PCI address of VVU device>
gives us a working VVU serial device.
Change-Id: I07d17dca2d02bd180b1667810ef92516ee026839
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3762974
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
|
||
|---|---|---|
| .. | ||
| aarch64 | ||
| arm | ||
| x86_64 | ||
| README.md | ||
Policy files for crosvm
This folder holds the seccomp policies for crosvm devices, organized by architecture.
Each crosvm device can run within its owned jailed process. A jailed process is only able to perform the system calls specified in the seccomp policy file the jail has been created with, which improves security as a rogue process cannot perform any system call it wants.
Each device can run from different contexts, which require a different set of authorized system calls. This file explains how the policy files are named in order to allow these various scenario.
Naming conventions
Since Minijail only allows for one level of policy inclusion, we need to be a little bit creative in order to minimize policy duplication.
common_device.policycontains a set of syscalls that are common to all devices, and is never loaded directly - only included from other policy files.foo.policycontains the set of syscalls that devicefoois susceptible to use, regardless of the underlying virtio transport. This policy is also never loaded directly.foo_device.policyis the policy that is loaded when devicefoois used as an in-VMM (i.e. regular virtio) device. It will generally simply includecommon_device.policyas well asfoo.policy.
When using vhost-user, the virtio protocol needs to be sent over a different medium, e.g. a Unix socket. Supporting this transport requires some extra system calls after the device is jailed, and thus dedicated policies:
vhost_user.policycontains the set of syscalls required by the regular (i.e. socket-based) vhost-user listener. It is never loaded directly.vvu.policycontains the set of syscalls required by the VFIO-based vhost-user (aka Virtio-Vhost-User) listener. It is also never loaded directly.foo_device_vhost_user.policyis the policy that is loaded when devicefoois used as a regular vhost-user device. It will generally includecommon_device.policy,vhost_user.policyandfoo.policy.foo_device_vvu.policyis the policy that is loaded when devicefoois used as a VVU device. It will generally includecommon_device.policy,vvu.policyandfoo.policy.