Browse Source
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>pull/307/head
1 changed files with 26 additions and 0 deletions
Loading…
Reference in new issue