From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Subject: [PULL 03/38] docs/system/security: Restrict "virtualization use case" to specific machines
Date: Fri, 31 Oct 2025 18:32:35 +0000 [thread overview]
Message-ID: <20251031183310.3778349-4-peter.maydell@linaro.org> (raw)
In-Reply-To: <20251031183310.3778349-1-peter.maydell@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-shentey@gmail.com/
This patch updates the security policy to explicitly list the
machine types we consider to be useful for the "virtualization
use case".
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Reviewed-by: Bernhard Beschow <shentey@gmail.com>
Message-id: 20251016131159.750480-1-peter.maydell@linaro.org
Acked-by: Markus Armbruster <armbru@redhat.com>
---
docs/system/security.rst | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/docs/system/security.rst b/docs/system/security.rst
index f2092c8768b..53992048e65 100644
--- a/docs/system/security.rst
+++ b/docs/system/security.rst
@@ -35,6 +35,32 @@ 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``
+s390x
+ ``s390-ccw-virtio``
+loongarch64:
+ ``virt``
+ppc64:
+ ``pseries``
+riscv32, riscv64:
+ ``virt``
+
Non-virtualization Use Case
'''''''''''''''''''''''''''
--
2.43.0
next prev parent reply other threads:[~2025-10-31 18:34 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 18:32 [PULL 00/38] target-arm queue Peter Maydell
2025-10-31 18:32 ` [PULL 01/38] hw/gpio/pl061: Declare pullups/pulldowns as 8-bit types Peter Maydell
2025-10-31 18:32 ` [PULL 02/38] docs/system/arm/virt: Document user-creatable SMMUv3 Peter Maydell
2025-10-31 18:32 ` Peter Maydell [this message]
2025-10-31 18:32 ` [PULL 04/38] target/arm: Add assert to arm_to_core_mmu_idx() Peter Maydell
2025-10-31 18:32 ` [PULL 05/38] hw/arm/virt: Remove deprecated virt-4.1 machine Peter Maydell
2025-10-31 18:32 ` [PULL 06/38] hw/arm/virt: Remove VirtMachineClass::no_ged field Peter Maydell
2025-10-31 18:32 ` [PULL 07/38] hw/arm/virt: Remove deprecated virt-4.2 machine Peter Maydell
2025-10-31 18:32 ` [PULL 08/38] hw/arm/virt: Remove VirtMachineClass::kvm_no_adjvtime field Peter Maydell
2025-10-31 18:32 ` [PULL 09/38] target/arm/hvf: Release memory allocated by hv_vcpu_config_create() Peter Maydell
2025-10-31 18:32 ` [PULL 10/38] target/arm/hvf: Trace vCPU KICK events Peter Maydell
2025-10-31 18:32 ` [PULL 11/38] target/arm/hvf: Check hv_vcpus_exit() returned value Peter Maydell
2025-10-31 18:32 ` [PULL 12/38] target/arm/hvf: Check hv_vcpu_set_vtimer_mask() " Peter Maydell
2025-10-31 18:32 ` [PULL 13/38] accel/hvf: Rename hvf_vcpu_exec() -> hvf_arch_vcpu_exec() Peter Maydell
2025-10-31 18:32 ` [PULL 14/38] accel/hvf: Rename hvf_put|get_registers -> hvf_arch_put|get_registers Peter Maydell
2025-10-31 18:32 ` [PULL 15/38] target/arm/hvf: Mention flush_cpu_state() must run on vCPU thread Peter Maydell
2025-10-31 18:32 ` [PULL 16/38] accel/hvf: Mention hvf_arch_init_vcpu() " Peter Maydell
2025-10-31 18:32 ` [PULL 17/38] target/arm/hvf: Mention hvf_sync_vtimer() " Peter Maydell
2025-10-31 18:32 ` [PULL 18/38] target/arm/hvf: Mention hvf_arch_set_traps() " Peter Maydell
2025-10-31 18:32 ` [PULL 19/38] accel/hvf: Mention hvf_arch_update_guest_debug() must run on vCPU Peter Maydell
2025-10-31 18:32 ` [PULL 20/38] target/arm/hvf: Mention hvf_inject_interrupts() must run on vCPU thread Peter Maydell
2025-10-31 18:32 ` [PULL 21/38] accel/hvf: Implement hvf_arch_vcpu_destroy() Peter Maydell
2025-10-31 18:32 ` [PULL 22/38] target/arm/hvf: Hardcode Apple MIDR Peter Maydell
2025-10-31 18:32 ` [PULL 23/38] target/arm/hvf: Simplify hvf_arm_get_host_cpu_features() Peter Maydell
2025-10-31 18:32 ` [PULL 24/38] target/arm/hvf: switch hvf_arm_get_host_cpu_features to not create a vCPU Peter Maydell
2025-10-31 18:32 ` [PULL 25/38] target/arm/hvf: Factor hvf_handle_exception() out Peter Maydell
2025-10-31 18:32 ` [PULL 26/38] target/i386/hvf: Factor hvf_handle_vmexit() out Peter Maydell
2025-10-31 18:32 ` [PULL 27/38] target/arm/hvf: " Peter Maydell
2025-10-31 18:33 ` [PULL 28/38] target/arm/hvf: Keep calling hv_vcpu_run() in loop Peter Maydell
2025-10-31 18:33 ` [PULL 29/38] cpus: Trace cpu_exec_start() and cpu_exec_end() calls Peter Maydell
2025-10-31 18:33 ` [PULL 30/38] accel/hvf: Guard hv_vcpu_run() between cpu_exec_start/end() calls Peter Maydell
2025-10-31 18:33 ` [PULL 31/38] target/arm: Call aarch64_add_pauth_properties() once in host_initfn() Peter Maydell
2025-10-31 18:33 ` [PULL 32/38] accel/hvf: Restrict ARM specific fields of AccelCPUState Peter Maydell
2025-10-31 18:33 ` [PULL 33/38] target/arm: Rename init_cpreg_list() -> arm_init_cpreg_list() Peter Maydell
2025-10-31 18:33 ` [PULL 34/38] target/arm/hvf: Rename 'vgic' -> 'emu_reginfo' in trace events Peter Maydell
2025-10-31 18:33 ` [PULL 35/38] target/arm: Re-use arm_is_psci_call() in HVF Peter Maydell
2025-10-31 18:33 ` [PULL 36/38] target/arm: Share ARM_PSCI_CALL trace event between TCG and HVF Peter Maydell
2025-10-31 18:33 ` [PULL 37/38] target/arm/hvf/hvf: Document $pc adjustment in HVF & SMC Peter Maydell
2025-10-31 18:33 ` [PULL 38/38] accel/hvf: Trace prefetch abort Peter Maydell
2025-11-01 11:11 ` [PULL 00/38] target-arm queue Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251031183310.3778349-4-peter.maydell@linaro.org \
--to=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).