Currently our security policy defines a "virtualization use case"
where we consider bugs to be security issues, and a
"non-virtualization use case" where we do not make any security
guarantees and don't consider bugs to be security issues.

The rationale for this split is that much code in QEMU is older and
was not written with malicious guests in mind, and we don't have the
resources to audit, fix and defend it.  So instead we inform users
about what the can in practice rely on as a security barrier, and
what they can't.

We don't currently restrict the "virtualization use case" to any
particular set of machine types.  This means that we have effectively
barred ourselves from adding KVM support to any machine type that we
don't want to put into the "bugs are security issues" category, even
if it would be useful for users to be able to get better performance
with a trusted guest by enabling KVM. This seems an unnecessary
restriction, and in practice the set of machine types it makes
sense to use for untrusted-guest virtualization is quite small.

Specifically, we would like to be able to enable the use of
KVM with the imx8 development board machine types, but we don't
want to commit ourselves to having to support those SoC models
and device models as part of QEMU's security boundary:
https://lore.kernel.org/qemu-devel/20250629204851.1778-3-shen...@gmail.com/

This patch updates the security policy to explicitly list the
machine types we consider to be useful for the "virtualization
use case".

This is an RFC partly to see if we have consensus that this change
makes sense, and partly because I was only able to identify the
machine types we want to cover for some of our target architectures.
If maintainers for the other architectures could clarify which
machine types work with KVM that would be helpful.

Notes on the listed machine types:

architectures I'm pretty sure about:

aarch64:
 -- virt is definitely the only supported one
s390x:
 -- s390-ccw-virtio is the only machine type for this architecture
loongarch64:
 -- virt is the only machine type for this architecture

architectures where I've made a guess:

i386, x86_64:
 -- I have assumed that all machine types except the "experimental"
    x-remote are supported

architectures I don't know:

mips, mips64
riscv32, riscv64
ppc, ppc64

Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
---
 docs/system/security.rst | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/docs/system/security.rst b/docs/system/security.rst
index f2092c8768b..395c2d7fb88 100644
--- a/docs/system/security.rst
+++ b/docs/system/security.rst
@@ -35,6 +35,34 @@ malicious:
 Bugs affecting these entities are evaluated on whether they can cause damage in
 real-world use cases and treated as security bugs if this is the case.
 
+To be covered by this security support policy you must:
+
+- use a virtualization accelerator like KVM or HVF
+- use one of the machine types listed below
+
+It may be possible to use other machine types with a virtualization
+accelerator to provide improved performance with a trusted guest
+workload, but any machine type not listed here should not be
+considered to be providing guest isolation or security guarantees,
+and falls under the "non-virtualization use case".
+
+Supported machine types for the virtualization use case, by target 
architecture:
+
+aarch64
+  ``virt``
+i386, x86_64
+  ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35``, ``isapc``
+s390x
+  ``s390-ccw-virtio``
+loongarch64:
+  ``virt``
+ppc, ppc64:
+  TODO
+mips, mips64:
+  TODO
+riscv32, riscv64:
+  TODO
+
 Non-virtualization Use Case
 '''''''''''''''''''''''''''
 
-- 
2.43.0


Reply via email to