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

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

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

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