Am 8. September 2025 12:50:57 UTC schrieb Peter Maydell
<peter.mayd...@linaro.org>:
>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>
Thanks, Peter, for this proposal. It's nice to see the positive feedback which
may eventually make hardware-assisted acceleration accessible to a wider range
of the community. Much appreciated!
Best regards,
Bernhard
>---
> 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
> '''''''''''''''''''''''''''
>
