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-shentey@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.

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.maydell@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

Am 8. September 2025 12:50:57 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>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-shentey@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.
>
>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.maydell@linaro.org>

Thanks, Peter, for this proposal. It's nice to see the positive feedback which may eventually make hardware-assisted acceleration accessible to a wider range of the community. Much appreciated!

Best regards,
Bernhard

>---
> 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
> '''''''''''''''''''''''''''
> 

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-shentey@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".

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.



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 :|

Am 8. September 2025 15:09:34 UTC schrieb "Daniel P. Berrangé" <berrange@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-shentey@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".

Yeah, that's exactly the knot this RFC attempts to untangle and which was the motivation for the RFC in the first place.

>
>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 agree that pluggable devices are much more fuzzy. That's why this RFC makes a start in spelling out the machines where certain guarantees are made, and leaves pluggable devices untouched. This should allow for KVM to be usable in more machines, where these guarantees are too much of a burden.

Certainly there is more work to do on pluggable devices. And as you stated above, somebody has to have the time to work on it.

What is missing for your R-b, Daniel?

Best regards,
Bernhard

>
>
>
>With regards,
>Daniel

On Mon, 8 Sept 2025 at 16:09, Daniel P. Berrangé <berrange@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-shentey@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...

> 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).

thanks
-- PMM

Am 8. September 2025 15:15:43 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Mon, 8 Sept 2025 at 16:09, Daniel P. Berrangé <berrange@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-shentey@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?

>
>> 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

On 24/9/25 20:16, Bernhard Beschow wrote:
> Am 8. September 2025 15:15:43 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>> On Mon, 8 Sept 2025 at 16:09, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>
>>> On Mon, Sep 08, 2025 at 01:50:57PM +0100, Peter Maydell wrote:

[...]

>>> 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.

I suppose USB /is/ regularly used by 'virtualization use case' for input.

Also I expect I2C to be mandatory on x86/q35 due to the SMBus
dependency.

Like we list machines here, should we be explicit about devices covered?

> Best regards,
> Bernhard
> 
>>
>> thanks
>> -- PMM

On Wed, 24 Sept 2025 at 19:23, Bernhard Beschow <shentey@gmail.com> wrote:
>
>
>
> Am 8. September 2025 15:15:43 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> >On Mon, 8 Sept 2025 at 16:09, Daniel P. Berrangé <berrange@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-shentey@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

On 8/9/25 17:15, Peter Maydell wrote:
> On Mon, 8 Sept 2025 at 16:09, Daniel P. Berrangé <berrange@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-shentey@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...
> 
>> 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

If the "split-accel" (HW virtualization + SW emulation) effort lands,
we'll have a case of HVF + TCG. Do we want to consider it within our
security support policy? I doubt it (at least at the beginning). However
that would match "use a virtualization accelerator like KVM or HVF" (AND
"use one of the machine types listed below" with the 'virt' machine).

Should we reword? Or explicit "Any SW emulation use case is NOT
covered"?

>>> +- 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).
> 
> thanks
> -- PMM

Am 25. September 2025 00:14:34 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
>On 8/9/25 17:15, Peter Maydell wrote:
>> On Mon, 8 Sept 2025 at 16:09, Daniel P. Berrangé <berrange@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-shentey@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...
>> 
>>> 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
>
>If the "split-accel" (HW virtualization + SW emulation) effort lands,
>we'll have a case of HVF + TCG. Do we want to consider it within our
>security support policy? I doubt it (at least at the beginning). However
>that would match "use a virtualization accelerator like KVM or HVF" (AND
>"use one of the machine types listed below" with the 'virt' machine).
>
>Should we reword? Or explicit "Any SW emulation use case is NOT
>covered"?
>

Good point. Is it clear what SW emulation use case means? I'm struggling with this term since most of our device models are emulated in software and since "use case" seems very unclear. Should we write "Any [CPU] SW emulation [such as TCG] is NOT covered". Alternatively, we could elaborate this when the feature is about to land.

Best regsrds,
Bernhard

>>>> +- 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).
>> 
>> thanks
>> -- PMM
>

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-shentey@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.




> 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.maydell@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

Am 8. September 2025 14:45:40 UTC schrieb "Michael S. Tsirkin" <mst@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-shentey@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

>
>
>
>
>> 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.maydell@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
>

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" <mst@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-shentey@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-berrange@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.maydell@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
> >

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" <mst@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-shentey@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-berrange@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.


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 :|

On Mon, 13 Oct 2025 at 12:47, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 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"

With the suggested changes listed elsewhere in this
thread, my current manually curated list of machines is:

aarch64
  ``virt``
i386, x86_64
  ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35``
s390x
  ``s390-ccw-virtio``
loongarch64:
  ``virt``
ppc64:
  ``pseries``
riscv32, riscv64:
  ``virt``

If we say "versioned machine type", that puts these machines
outside the "supported" boundary:

i386, x86_64
  ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``
loongarch64:
  ``virt``
riscv32, riscv64:
  ``virt``

I can certainly see the argument for loongarch64
and maybe even riscv[*] still being "not supported for
production security-boundary stuff", but do we really
want to say that the Xen machine types and microvm
aren't suitable for VM use ?

[*] Could somebody from riscv or loongarch maintainers
say whether they think these machines should be on the
"security supported" list or not yet ?

thanks
-- PMM

On Tue, Oct 14, 2025 at 01:20:07PM +0100, Peter Maydell wrote:
> On Mon, 13 Oct 2025 at 12:47, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > 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"
> 
> With the suggested changes listed elsewhere in this
> thread, my current manually curated list of machines is:
> 
> aarch64
>   ``virt``
> i386, x86_64
>   ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35``
> s390x
>   ``s390-ccw-virtio``
> loongarch64:
>   ``virt``
> ppc64:
>   ``pseries``
> riscv32, riscv64:
>   ``virt``
> 
> If we say "versioned machine type", that puts these machines
> outside the "supported" boundary:
> 
> i386, x86_64
>   ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``
> loongarch64:
>   ``virt``
> riscv32, riscv64:
>   ``virt``
> 
> I can certainly see the argument for loongarch64
> and maybe even riscv[*] still being "not supported for
> production security-boundary stuff", but do we really
> want to say that the Xen machine types and microvm
> aren't suitable for VM use ?

No, that would be wrong. How about this alternative

  @@ -21,7 +21,9 @@ Virtualization Use Case
   The virtualization use case covers cloud and virtual private server (VPS)
   hosting, as well as traditional data center and desktop virtualization.  These
   use cases rely on hardware virtualization extensions to execute guest code
  -safely on the physical CPU at close-to-native speed.
  +safely on the physical CPU at close-to-native speed.  This use case is limited
  +to the use of versioned machine types, or machine types designed exclusively
  +for virtualization.
 
 The following entities are untrusted, meaning that they may be buggy or
 malicious:

that wording would bring xen* and microvm into the scope, and so match
your manually curated list.


> [*] Could somebody from riscv or loongarch maintainers
> say whether they think these machines should be on the
> "security supported" list or not yet ?

As 'virt' machines even if they're not quite there today, they are heading
in that direction. So it would make sense to consider them in scope for
the virtualization use case security handling. Even with this classification
we still have the flexibility to make bugs public immediately with no embargo
if we consider the real world impact to be low, so the burden is not large.


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 :|

On Tue, 14 Oct 2025 at 14:22, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Oct 14, 2025 at 01:20:07PM +0100, Peter Maydell wrote:
> > On Mon, 13 Oct 2025 at 12:47, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > 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"
> >
> > With the suggested changes listed elsewhere in this
> > thread, my current manually curated list of machines is:
> >
> > aarch64
> >   ``virt``
> > i386, x86_64
> >   ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35``
> > s390x
> >   ``s390-ccw-virtio``
> > loongarch64:
> >   ``virt``
> > ppc64:
> >   ``pseries``
> > riscv32, riscv64:
> >   ``virt``
> >
> > If we say "versioned machine type", that puts these machines
> > outside the "supported" boundary:
> >
> > i386, x86_64
> >   ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``
> > loongarch64:
> >   ``virt``
> > riscv32, riscv64:
> >   ``virt``
> >
> > I can certainly see the argument for loongarch64
> > and maybe even riscv[*] still being "not supported for
> > production security-boundary stuff", but do we really
> > want to say that the Xen machine types and microvm
> > aren't suitable for VM use ?
>
> No, that would be wrong. How about this alternative
>
>   @@ -21,7 +21,9 @@ Virtualization Use Case
>    The virtualization use case covers cloud and virtual private server (VPS)
>    hosting, as well as traditional data center and desktop virtualization.  These
>    use cases rely on hardware virtualization extensions to execute guest code
>   -safely on the physical CPU at close-to-native speed.
>   +safely on the physical CPU at close-to-native speed.  This use case is limited
>   +to the use of versioned machine types, or machine types designed exclusively
>   +for virtualization.
>
>  The following entities are untrusted, meaning that they may be buggy or
>  malicious:
>
> that wording would bring xen* and microvm into the scope, and so match
> your manually curated list.

I think that it's simpler for users if we explicitly list the
machines, rather than making them guess whether a machine
is "designed exclusively for virtualization".

thanks
-- PMM

On 2025/10/14 下午8:20, Peter Maydell wrote:
> On Mon, 13 Oct 2025 at 12:47, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> 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"
> 
> With the suggested changes listed elsewhere in this
> thread, my current manually curated list of machines is:
> 
> aarch64
>    ``virt``
> i386, x86_64
>    ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35``
> s390x
>    ``s390-ccw-virtio``
> loongarch64:
>    ``virt``
> ppc64:
>    ``pseries``
> riscv32, riscv64:
>    ``virt``
> 
> If we say "versioned machine type", that puts these machines
> outside the "supported" boundary:
> 
> i386, x86_64
>    ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``
> loongarch64:
>    ``virt``
> riscv32, riscv64:
>    ``virt``
> 
> I can certainly see the argument for loongarch64
> and maybe even riscv[*] still being "not supported for
> production security-boundary stuff", but do we really
> want to say that the Xen machine types and microvm
> aren't suitable for VM use ?
> 
> [*] Could somebody from riscv or loongarch maintainers
> say whether they think these machines should be on the
> "security supported" list or not yet ?
yes, loongarch virt machine with kvm accel should be security supported. 
Also in next version we consider to add versioned machine type with 
loongarch architecture.

Regards
Bibo Mao
> 
> thanks
> -- PMM
> 

Am 13. Oktober 2025 11:47:38 UTC schrieb "Daniel P. Berrangé" <berrange@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" <mst@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-shentey@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-berrange@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

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" <mst@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-shentey@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-berrange@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.


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 :|

On Mon, Sep 08, 2025 at 10:45:40AM -0400, Michael S. Tsirkin 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-shentey@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.

I would not consider "virtualization use case" to be something we
want to represent in code. It was just a crude hack for the docs
to approximate what we wanted to /initially/ aim to support.

The ideal theoretical end state would be for everything to be
in scope for security fixes, but we'll probably never get that
far. The reality is that we have a granular decision likely at
the level of individaul QOM/QDev types.

If we wanted any flag it would be better expressed as something
like "security-boundary=yes|no', and then each object would need
to have a tri-state property "security-boundary=undefined|yes|no".

Initially everything would be in the 'undefined' category and
over a long series of patches we would then reclassify as much
as possible to "yes" or "no".

.... a mere matter of someone having time to actually do the
work, which is how we ended up with our current fuzzy doc
rather than anything expressed in code.

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 :|

On 8/9/25 17:15, Daniel P. Berrangé wrote:
> On Mon, Sep 08, 2025 at 10:45:40AM -0400, Michael S. Tsirkin 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-shentey@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.
> 
> I would not consider "virtualization use case" to be something we
> want to represent in code. It was just a crude hack for the docs
> to approximate what we wanted to /initially/ aim to support.
> 
> The ideal theoretical end state would be for everything to be
> in scope for security fixes, but we'll probably never get that
> far. The reality is that we have a granular decision likely at
> the level of individaul QOM/QDev types.
> 
> If we wanted any flag it would be better expressed as something
> like "security-boundary=yes|no', and then each object would need
> to have a tri-state property "security-boundary=undefined|yes|no".
> 
> Initially everything would be in the 'undefined' category and
> over a long series of patches we would then reclassify as much
> as possible to "yes" or "no".

I find "yes" to give too much trust and fragile, since it is easy
to introduce (security) bug and discover them later, usually too late.

FTR our previous discussion about taintable runtime API:
https://lore.kernel.org/qemu-devel/YVWRw0ZKq3G6P5YP@redhat.com/

> .... a mere matter of someone having time to actually do the
> work, which is how we ended up with our current fuzzy doc
> rather than anything expressed in code.
> 
> With regards,
> Daniel

On Thu, Sep 25, 2025 at 02:05:17AM +0200, Philippe Mathieu-Daudé wrote:
> On 8/9/25 17:15, Daniel P. Berrangé wrote:
> > On Mon, Sep 08, 2025 at 10:45:40AM -0400, Michael S. Tsirkin 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-shentey@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.
> > 
> > I would not consider "virtualization use case" to be something we
> > want to represent in code. It was just a crude hack for the docs
> > to approximate what we wanted to /initially/ aim to support.
> > 
> > The ideal theoretical end state would be for everything to be
> > in scope for security fixes, but we'll probably never get that
> > far. The reality is that we have a granular decision likely at
> > the level of individaul QOM/QDev types.
> > 
> > If we wanted any flag it would be better expressed as something
> > like "security-boundary=yes|no', and then each object would need
> > to have a tri-state property "security-boundary=undefined|yes|no".
> > 
> > Initially everything would be in the 'undefined' category and
> > over a long series of patches we would then reclassify as much
> > as possible to "yes" or "no".
> 
> I find "yes" to give too much trust and fragile, since it is easy
> to introduce (security) bug and discover them later, usually too late.

This isn't promising that QEMU is free of security bugs - that is
impossible to claim for anything. It is telling the user that this
is a set of features that have been written with a credible attempt
to provide a security boundary, and thus they can rely on them to
confine untrusted workloads.

> FTR our previous discussion about taintable runtime API:
> https://lore.kernel.org/qemu-devel/YVWRw0ZKq3G6P5YP@redhat.com/

I think it is good to treat each piece of information as independent.
ie something can be considered secure, while at the same time also
be deprecated. Or something can be considered suitable for production
usage, while also being insecure. e.g. TCG can be used in production,
but you shouldn't used it with untrusted guests. I'm not sure that
a notion of "production" really makes sense at all, as that is
somewhat dependent on use case and the user's POV.

I'd see three pieces of useful info - deprecation status (bool),
security status (bool),  maintainer status (enum), and each can be
tackled independently, not least to make the work more practical. 

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 :|

On Mon, Sep 08, 2025 at 01:50:57PM +0100, Peter Maydell wrote:
> 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.

Makes sense to me.

Stefan

On 9/8/25 14:50, Peter Maydell wrote:
> architectures where I've made a guess:
> 
> i386, x86_64:
>   -- I have assumed that all machine types except the "experimental"
>      x-remote are supported

Please exclude isapc as well.

> mips, mips64

Probably none.

> riscv32, riscv64

I'd assume "virt" only.

> ppc, ppc64

"pseries" only.

Paolo

On 08/09/2025 15.09, Paolo Bonzini wrote:
> On 9/8/25 14:50, Peter Maydell wrote:
>> architectures where I've made a guess:
>>
>> i386, x86_64:
>>   -- I have assumed that all machine types except the "experimental"
>>      x-remote are supported
> 
> Please exclude isapc as well.

Ack, isapc uses ne2k as NIC for example, so you certainly don't want to have 
this in the list of supported machines.

>> mips, mips64
> 
> Probably none.
> 
>> riscv32, riscv64
> 
> I'd assume "virt" only.
> 
>> ppc, ppc64
> 
> "pseries" only.

Ack, ppc64 should use "pseries". But that's 64-bit only. I don't think we 
want any of the 32-bit machines listed here, though, so I'd simply suggest 
to drop the 32-bit "ppc" word from this section.

  Thomas

On 8/9/25 15:21, Thomas Huth wrote:
> On 08/09/2025 15.09, Paolo Bonzini wrote:
>> On 9/8/25 14:50, Peter Maydell wrote:
>>> architectures where I've made a guess:
>>>
>>> i386, x86_64:
>>>   -- I have assumed that all machine types except the "experimental"
>>>      x-remote are supported
>>
>> Please exclude isapc as well.
> 
> Ack, isapc uses ne2k as NIC for example, so you certainly don't want to 
> have this in the list of supported machines.

Agreed.

> 
>>> mips, mips64
>>
>> Probably none.

Safe bet. MIPS host is being deprecated anyway:
https://lore.kernel.org/qemu-devel/20250924120426.2158655-26-marcandre.lureau@redhat.com/

>>
>>> riscv32, riscv64
>>
>> I'd assume "virt" only.
>>
>>> ppc, ppc64
>>
>> "pseries" only.
> 
> Ack, ppc64 should use "pseries". But that's 64-bit only. I don't think 
> we want any of the 32-bit machines listed here, though, so I'd simply 
> suggest to drop the 32-bit "ppc" word from this section.
> 
>   Thomas
>