On Wed, 24 Sept 2025 at 19:23, Bernhard Beschow <shen...@gmail.com> wrote: > > > > Am 8. September 2025 15:15:43 UTC schrieb Peter Maydell > <peter.mayd...@linaro.org>: > >On Mon, 8 Sept 2025 at 16:09, Daniel P. Berrangé <berra...@redhat.com> wrote: > >> > >> On Mon, Sep 08, 2025 at 01:50:57PM +0100, Peter Maydell wrote: > >> > 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. > >> > >> The split of "virtualization" vs "non-virtualization" use case > >> in the docs was always as rather a crude hack. > >> > >> "Virtualization uses cases" was more or less a code phrase to > >> mean "the subset of QEMU that we traditionally shipped in RHEL" > >> as that is approximately what we have reasonable confidence > >> about. > >> > >> Personally I wouldn't assign strict equivalence between "machine > >> can use KVM" and "virtualization use case". > > > >I agree, but this is effectively what our docs are currently doing, > >and what I'm trying to decouple with this patch... > > Ping > > Anything left to discuss?
This got derailed by proposals to encode the security status of devices etc actually in code. Personally I would prefer us to just update the documentation as a start, rather than blocking this on designing and implementing the code-based approach. -- PMM
