Am 13. Oktober 2025 11:47:38 UTC schrieb "Daniel P. Berrangé"
<berra...@redhat.com>:
>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"
>> > <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.
>
>I don't think that its desirable to rebase on top of that series,
>as it is liable to unduly delay Bernhard's work.
>
>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.
Yeah, requiring the machine type to be versioned makes a lot of sense to me.
Peter, what do you think?
Best regards,
Bernhard
>
>
>With regards,
>Daniel
