Our docs/system/security.rst file loosely classifies code into that
applicable for 'virtualization' vs 'non-virtualization' use cases.
Only code relevant to the former group is eligible for security
bug handling. It is difficult for any contributors to know what
devices are in scope for 'virtualization' when reporting bugs,
and even maintainers can have a hard time agreeing.
It is well overdue to declare this information the code and present
it to end users at runtime. This series starts the effort by defining
the internal infrastructure, command line args and QMP extensions to
handle the security status recording and reporting.
A previous posting included classifications for many devices. That
is dropped this v3 series so we can focus on getting the core infra
included. Device classifications will follow afterwards in a separate
series.
The base concept is that the QOM TypeInfo struct gains a new field
"bool secure". This enables querying any ObjectClass to ask whether
or not it is declared secure.
By only using a single boolean flag, at runtime we are unable to
distinguish between "marked insecure" and "no decision, implicitly
insecure". As such, all our existing code is initially considered
insecure, once this series is applied. Code we want to provide a
security boundary for will explicitly opt-in with '.secure = true'.
Previously it was intended to add '.secure = false' to each file
too as it gets evaluated, however, this is now considered to be
overkill. It is easy enough to build a list of everything that
should be treated as secure by perusing "-device help" output.
Classification for non-user creatable types can be left to a 2nd
phase of work.
In terms of user interface, the "-compat" argument gains a new
parameter
* insecure-types=accept|reject|warn
The default 'accept' preserves historical behaviour of
anything being permissible. The other two options both
identify use of types that are not explicitly marked
as secure.
The code annotations are useful immediately, but the -compat
-compat switch is unusable unless a minimum viable set of
secure devices are defined in a follow series. Some conceptual
examples though...
Example: TCG is explicitly insecure, KVM is explicitly secure:
$ qemu-system-x86_64 -display none -compat insecure-types=reject -accel tcg
qemu-system-x86_64: -accel tcg: Type 'tcg-accel' does not provide a security
boundary to protect against untrusted workloads
$ qemu-system-x86_64 -display none -compat insecure-types=reject -accel kvm
^C
Example: isapc machine type is explicitly insecure
$ qemu-system-x86_64 -display none -compat insecure-types=reject -machine
isapc
qemu-system-x86_64: Type 'isapc-machine' does not provide a security boundary
to protect against untrusted workloads
Example: checks also apply in HMP, ne2k_pci is insecure
$ ./build/qemu-system-x86_64 -display none -compat insecure-types=reject
-monitor stdio -accel kvm
QEMU 10.1.50 monitor - type 'help' for more information
(qemu) device_add ne2k_pci
Error: Type 'ne2k_pci' does not provide a security boundary to protect
against untrusted workloads
Example: checks also apply in QMP:
$ ./scripts/qmp/qmp-shell-wrap qemu-system-x86_64 -display none -compat
insecure-types=reject -accel kvm
Welcome to the QMP low-level shell!
Connected
(QEMU) device_add driver=ne2k_oci
{"error": {"class": "GenericError", "desc": "Type 'ne2k_pci' does not provide
a security boundary to protect against untrusted workloads"}}
(QEMU) device_add driver=virtio-net
{"return": {}}
This series is available at
https://gitlab.com/berrange/qemu/-/commits/docs-security-status
The WIP patches that add tagging of devices (which I will post separately
in future) are at
https://gitlab.com/berrange/qemu/-/commits/docs-security-devices
Changes in v3:
* Dropped all device classification, to be re-posted as
a separate series
* Reworded the docs based on previous feedback
* Improved commit messages
* Reformatted QAPI docs per feedback
* Split commit adding QMP device list filtering
into two
* Make CompatPolicy parameters 'const'
* Add helper APIs in QOM for querying security
status to reduce duplicate code pattern
* Fix placement of security check for accelerator
types
Changes in v2:
* Report security status in qom-list-types
* Allow qom-list-types to filter on secure types
* Remove 'bool insecure' on TypeInfo, assume that no specified
data is equivalent to '.secure = false'
* Annotate a massive number of object types
Daniel P. Berrangé (14):
qom: add tracking of security state of object types
qapi: add 'insecure-types' option for -compat argument
qom: add helper APIs for checking object security policy compliance
system: check security for accelerator types
system: report acclerator security status in help output
system: check security for machine types
system: report machine security status in help output
system: check security of device types
system: report device security status in help output
hw/core: report security status in query-machines
qom: refactor data passing for QOM list filtering
qom: report & filter on security status in qom-list-types
docs: expand security docs with info about security status
machine: add helpers for declaring secure/insecure machine types
docs/system/security.rst | 36 +++++++++++++++++++++++++++++++++
hw/arm/bananapi_m2u.c | 2 +-
hw/arm/cubieboard.c | 2 +-
hw/arm/imx8mm-evk.c | 2 +-
hw/arm/integratorcp.c | 2 +-
hw/arm/mcimx7d-sabre.c | 2 +-
hw/arm/orangepi.c | 2 +-
hw/core/machine-qmp-cmds.c | 1 +
hw/ppc/pegasos.c | 3 ++-
include/hw/core/boards.h | 25 ++++++++++++++++++-----
include/hw/i386/pc.h | 11 +++++++++-
include/qapi/compat-policy.h | 5 +++++
include/qom/object.h | 39 ++++++++++++++++++++++++++++++++++++
qapi/compat.json | 23 ++++++++++++++++++++-
qapi/machine.json | 8 +++++++-
qapi/qapi-util.c | 30 +++++++++++++++++++++++++++
qapi/qom.json | 13 ++++++++++--
qom/object.c | 22 ++++++++++++++++++++
qom/qom-qmp-cmds.c | 30 +++++++++++++++++++++------
system/qdev-monitor.c | 7 +++++++
system/vl.c | 30 ++++++++++++++++++++++-----
21 files changed, 267 insertions(+), 28 deletions(-)
--
2.55.0
