qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Bernhard Beschow" <shentey@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Alistair Francis" <Alistair.Francis@wdc.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	qemu-riscv@nongnu.org, qemu-ppc@nongnu.org,
	"Huacai Chen" <chenhuacai@kernel.org>,
	qemu-s390x@nongnu.org, "Halil Pasic" <pasic@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Song Gao" <gaosong@loongson.cn>,
	"Bibo Mao" <maobibo@loongson.cn>
Subject: Re: [PATCH v2] docs/system/security: Restrict "virtualization use case" to specific machines
Date: Fri, 17 Oct 2025 09:06:51 +0200	[thread overview]
Message-ID: <ccb41d4e-c6e7-49c1-b3db-c09034f95d61@redhat.com> (raw)
In-Reply-To: <20251016131159.750480-1-peter.maydell@linaro.org>

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>



  parent reply	other threads:[~2025-10-17  7:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16 13:11 [PATCH v2] docs/system/security: Restrict "virtualization use case" to specific machines Peter Maydell
2025-10-16 19:55 ` Christian Borntraeger
2025-10-17  2:31 ` Bibo Mao
2025-10-17  7:06 ` Thomas Huth [this message]
2025-10-17  9:15 ` Harsh Prateek Bora
2025-10-17 11:42 ` Bernhard Beschow
2025-10-27 12:48 ` Peter Maydell
2025-10-28  8:48   ` Bernhard Beschow
2025-10-27 13:29 ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ccb41d4e-c6e7-49c1-b3db-c09034f95d61@redhat.com \
    --to=thuth@redhat.com \
    --cc=Alistair.Francis@wdc.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=chenhuacai@kernel.org \
    --cc=gaosong@loongson.cn \
    --cc=jiaxun.yang@flygoat.com \
    --cc=maobibo@loongson.cn \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=shentey@gmail.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).