On Mon, Oct 13, 2025 at 12:47:38PM +0100, Daniel P. Berrangé wrote: > On Mon, Oct 13, 2025 at 07:12:31AM -0400, Michael S. Tsirkin wrote: > > 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" > > > <[email protected]>: > > > >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/[email protected]/ > > > >> > > > >> 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/[email protected] > > > > if there's anything missing there, add it. > > I don't think that its desirable to rebase on top of that series, > as it is liable to unduly delay Bernhard's work.
Yea I'm all for not delaying imx8mp-evk work. Let's just find a way without enumerating all machine types since your patchset does it. This is what I meant, really. > With a very minimal wording tweak our current defined policy could > avoid being a blocker for enabling KVM in imx8mp-evk. In > > https://www.qemu.org/docs/master/system/security.html > > where it describes the "virtualization use case", we could simply > tweak it to always require a versioned machine type > > Change > > "These use cases rely on hardware virtualization extensions > to execute guest code safely on the physical CPU at close- > to-native speed." > > To say > > "These use cases apply to versioned machine types when used > in combination with hardware virtualization extensions > to execute guest code safely on the physical CPU at close- > to-native speed" > > Since imx8mp-evk won't be a versioned machine type, it is thus > trivially excluded, without us having to enumerate all machine > types int he docs. Sounds good. > > With regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
