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

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
changes v1->v2: updated the list:
 * remove isapc
 * remove ppc, mips, mips64 (no machines supported)
 * list pseries as only supported ppc64 machine
 * list virt as only supported riscv32, riscv64 machine

I believe the list to now be correct, and I think we generally
had some consensus about the idea on the v1 patch discussion, so
this one is a non-RFC patch.

---
 docs/system/security.rst | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/docs/system/security.rst b/docs/system/security.rst
index f2092c8768b..53992048e65 100644
--- a/docs/system/security.rst
+++ b/docs/system/security.rst
@@ -35,6 +35,32 @@ 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``
+s390x
+  ``s390-ccw-virtio``
+loongarch64:
+  ``virt``
+ppc64:
+  ``pseries``
+riscv32, riscv64:
+  ``virt``
+
 Non-virtualization Use Case
 '''''''''''''''''''''''''''
 
-- 
2.43.0

Peter Maydell <peter.maydell@linaro.org> writes:

> 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".
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> changes v1->v2: updated the list:
>  * remove isapc
>  * remove ppc, mips, mips64 (no machines supported)
>  * list pseries as only supported ppc64 machine
>  * list virt as only supported riscv32, riscv64 machine
>
> I believe the list to now be correct, and I think we generally
> had some consensus about the idea on the v1 patch discussion, so
> this one is a non-RFC patch.
>
> ---
>  docs/system/security.rst | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
>
> diff --git a/docs/system/security.rst b/docs/system/security.rst
> index f2092c8768b..53992048e65 100644
> --- a/docs/system/security.rst
> +++ b/docs/system/security.rst
> @@ -35,6 +35,32 @@ 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".

"Virtualization use case" becomes a bit of a misnomer.

> +
> +Supported machine types for the virtualization use case, by target architecture:
> +
> +aarch64
> +  ``virt``
> +i386, x86_64
> +  ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35``
> +s390x
> +  ``s390-ccw-virtio``
> +loongarch64:
> +  ``virt``
> +ppc64:
> +  ``pseries``
> +riscv32, riscv64:
> +  ``virt``
> +
>  Non-virtualization Use Case
>  '''''''''''''''''''''''''''

Regardless
Acked-by: Markus Armbruster <armbru@redhat.com>

On Thu, 16 Oct 2025 at 14:12, Peter Maydell <peter.maydell@linaro.org> 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".
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> changes v1->v2: updated the list:
>  * remove isapc
>  * remove ppc, mips, mips64 (no machines supported)
>  * list pseries as only supported ppc64 machine
>  * list virt as only supported riscv32, riscv64 machine
>
> I believe the list to now be correct, and I think we generally
> had some consensus about the idea on the v1 patch discussion, so
> this one is a non-RFC patch.

This has now had various reviews and acks, and no
suggestions for further revision. I propose to take
this via target-arm.next, unless anybody has any
objections.

thanks
-- PMM

Am 27. Oktober 2025 12:48:29 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Thu, 16 Oct 2025 at 14:12, Peter Maydell <peter.maydell@linaro.org> 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".
>>
>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>> ---
>> changes v1->v2: updated the list:
>>  * remove isapc
>>  * remove ppc, mips, mips64 (no machines supported)
>>  * list pseries as only supported ppc64 machine
>>  * list virt as only supported riscv32, riscv64 machine
>>
>> I believe the list to now be correct, and I think we generally
>> had some consensus about the idea on the v1 patch discussion, so
>> this one is a non-RFC patch.
>
>This has now had various reviews and acks, and no
>suggestions for further revision. I propose to take
>this via target-arm.next, unless anybody has any
>objections.

Sounds good, I'm looking forward to it.

Maybe we could then also merge https://lore.kernel.org/qemu-devel/20250629204851.1778-3-shentey@gmail.com/ which had some technical comments and no follow-up.

Best regards,
Bernhard

>
>thanks
>-- PMM

Am 16. Oktober 2025 13:11:59 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".
>
>Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
>---
>changes v1->v2: updated the list:
> * remove isapc
> * remove ppc, mips, mips64 (no machines supported)
> * list pseries as only supported ppc64 machine
> * list virt as only supported riscv32, riscv64 machine
>
>I believe the list to now be correct, and I think we generally
>had some consensus about the idea on the v1 patch discussion, so
>this one is a non-RFC patch.

Thanks for clarifying this.

FWIW:
Reviewed-by: Bernhard Beschow <shentey@gmail.com>

>
>---
> docs/system/security.rst | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
>diff --git a/docs/system/security.rst b/docs/system/security.rst
>index f2092c8768b..53992048e65 100644
>--- a/docs/system/security.rst
>+++ b/docs/system/security.rst
>@@ -35,6 +35,32 @@ 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``
>+s390x
>+  ``s390-ccw-virtio``
>+loongarch64:
>+  ``virt``
>+ppc64:
>+  ``pseries``
>+riscv32, riscv64:
>+  ``virt``
>+
> Non-virtualization Use Case
> '''''''''''''''''''''''''''
> 

On 10/16/25 18:41, 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".
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> changes v1->v2: updated the list:
>   * remove isapc
>   * remove ppc, mips, mips64 (no machines supported)
>   * list pseries as only supported ppc64 machine
>   * list virt as only supported riscv32, riscv64 machine
> 
> I believe the list to now be correct, and I think we generally
> had some consensus about the idea on the v1 patch discussion, so
> this one is a non-RFC patch.
> 
> ---
>   docs/system/security.rst | 26 ++++++++++++++++++++++++++
>   1 file changed, 26 insertions(+)
> 
> diff --git a/docs/system/security.rst b/docs/system/security.rst
> index f2092c8768b..53992048e65 100644
> --- a/docs/system/security.rst
> +++ b/docs/system/security.rst
> @@ -35,6 +35,32 @@ 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``
> +s390x
> +  ``s390-ccw-virtio``
> +loongarch64:
> +  ``virt``
> +ppc64:
> +  ``pseries``

LGTM.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>

> +riscv32, riscv64:
> +  ``virt``
> +
>   Non-virtualization Use Case
>   '''''''''''''''''''''''''''
>

On 16/10/2025 15.11, 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/

(FWIW, I think this was already a ambiguous on ppc where some of the other 
old machine types like mac99 or ppce500 could be used with KVM, too, so it's 
good that we finally get some proper wording here)

> This patch updates the security policy to explicitly list the
> machine types we consider to be useful for the "virtualization
> use case".
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> changes v1->v2: updated the list:
>   * remove isapc
>   * remove ppc, mips, mips64 (no machines supported)
>   * list pseries as only supported ppc64 machine
>   * list virt as only supported riscv32, riscv64 machine
> 
> I believe the list to now be correct, and I think we generally
> had some consensus about the idea on the v1 patch discussion, so
> this one is a non-RFC patch.

Looks good to me now, thanks for tackling this!

Reviewed-by: Thomas Huth <thuth@redhat.com>

On 2025/10/16 下午9:11, 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".
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> changes v1->v2: updated the list:
>   * remove isapc
>   * remove ppc, mips, mips64 (no machines supported)
>   * list pseries as only supported ppc64 machine
>   * list virt as only supported riscv32, riscv64 machine
> 
> I believe the list to now be correct, and I think we generally
> had some consensus about the idea on the v1 patch discussion, so
> this one is a non-RFC patch.
> 
> ---
>   docs/system/security.rst | 26 ++++++++++++++++++++++++++
>   1 file changed, 26 insertions(+)
> 
> diff --git a/docs/system/security.rst b/docs/system/security.rst
> index f2092c8768b..53992048e65 100644
> --- a/docs/system/security.rst
> +++ b/docs/system/security.rst
> @@ -35,6 +35,32 @@ 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``
> +s390x
> +  ``s390-ccw-virtio``
> +loongarch64:
> +  ``virt``

With loongarch64 part.
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
> +ppc64:
> +  ``pseries``
> +riscv32, riscv64:
> +  ``virt``
> +
>   Non-virtualization Use Case
>   '''''''''''''''''''''''''''
>   
> 

Am 16.10.25 um 15:11 schrieb Peter Maydell:
[...]
> +Supported machine types for the virtualization use case, by target architecture:
> +
> +aarch64
> +  ``virt``
> +i386, x86_64
> +  ``microvm``, ``xenfv``, ``xenpv``, ``xenpvh``, ``pc``, ``q35``
> +s390x
> +  ``s390-ccw-virtio``

Makes sense for the s390x case.
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>