On Mon, Oct 13, 2025 at 10:40:36AM +0000, Bernhard Beschow wrote: > > > Am 8. September 2025 14:45:40 UTC schrieb "Michael S. Tsirkin" > <m...@redhat.com>: > >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 use-case sounds reasonable to me. I also imagine that > >some machines can get fixed down the road perhaps to > >the point where they enter the "virtualization use case". > > > >However, since we are > >getting this elaborate, would my old idea of a runtime flag > >make sense now? > > > >To recap, the idea was to add a "-virt" flag that will > >block any machines, devices and so on not considered > >part of the "virtualization use case". > > > >We could also create a mechanism for downstreams to > >tweak this as they see fit. > > Hi Michael, > > Thanks for confirming that the use case seems reasonable. > > For now, we'd like to sharpen the term "virtualization use case" to allow for > KVM to be usable in machines that aren't inside the security boundary and > where maintenance commitment is unrealistic. The current approach is to > adjust the policy and to spell out the machines where these commitments are > made. > > The trigger for this RFC was to be able to add KVM support to the imx8mp-evk > machine. I have it working but can't currently upstream it due to our policy. > It asks for unreasonable work and commitment which adds an unjustifyable > burden on the maintainers. > > I do see a need for further enhancements on the broader topic like adding a > -virt switch etc. Maybe we should come up with a different term than > "virtualization use case" which appears to leave a lot of room for > interpretation. I propose these topics to be addressed separately. > > What is missing for your R-b? > > Thanks, > Bernhard
rebase on top of this: https://lore.kernel.org/all/20250926140144.1998694-1-berra...@redhat.com if there's anything missing there, add it. > > > > > > > > > >> 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 > >
