Am 8. September 2025 15:15:43 UTC schrieb Peter Maydell
<[email protected]>:
>On Mon, 8 Sept 2025 at 16:09, Daniel P. Berrangé <[email protected]> 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/[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 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?
>
>> Case in point - the "isapc" machine type can use KVM but I would
>> not consider that to be a virtualization use case, and would likely
>> reject a security report if it /only/ affected isapc, and not 'pc'
>> / 'q35'.
>>
>> We didn't want to undertake the work to annotate every QOM/QDev
>> impl in QEMU with info about whether we considered it in scope
>> for security fixes or not, which is what we really ought to do
>> at some point. The main challenge is someone having the time
>> to do the audit & annotation work.
>>
>> > 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
>>
>> Currently 'virtualization use case' is reasonably vague such that we can
>> bend its scope as we desire, at the time it is questioned in a possible
>> security report.
>>
>> Machine types are only one aspect of this. Devices are the other, and
>> the area where it gets significantly more fuzzy and difficult because
>> essentially any device can be used with KVM, and where we draw the
>> line is fairly arbitrary.
>
>I think that being vague like this is a disservice to our users.
>If I'm a user of QEMU, I'd like to know whether I'm inside the
>line or outside of it before I put my config into production,
>not later on when it turns out there was an exploitable bug
>that wasn't classified as a security issue...
>
>Most devices can't in fact be used with KVM, because they're
>sysbus devices that aren't used in the machines that you can
>use with KVM. Pluggable devices are rarer (and yes, under
>our current policy random PCI devices are effectively
>in-scope).
From the top of my head: Various USB and I²C devices can be used as well.
Best regards,
Bernhard
>
>thanks
>-- PMM
