public inbox for qemu-devel@nongnu.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Junjie Cao <junjie.cao@intel.com>,
	qemu-devel@nongnu.org, jasowang@redhat.com, mst@redhat.com,
	yuri.benditovich@daynix.com, akihiko.odaki@daynix.com,
	qemu-stable@nongnu.org
Subject: Re: [PATCH] virtio-net: validate RSS indirections_len in post_load
Date: Mon, 23 Mar 2026 14:11:58 +0000	[thread overview]
Message-ID: <acFKLgvFAlP7asIp@redhat.com> (raw)
In-Reply-To: <CAFEAcA88mHqmM8Pmm0Gbbeu4ugBV8snenZh7bvjSSruUtRcywQ@mail.gmail.com>

On Mon, Mar 23, 2026 at 01:53:53PM +0000, Peter Maydell wrote:
> On Mon, 23 Mar 2026 at 13:43, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Mon, Mar 23, 2026 at 09:15:31PM +0800, Junjie Cao wrote:
> > > virtio_net_handle_rss() enforces that indirections_len is a non-zero
> > > power of two no larger than VIRTIO_NET_RSS_MAX_TABLE_LEN, but
> > > virtio_net_rss_post_load() applies none of these checks to values
> > > restored from the migration stream.
> > >
> > > A crafted migration stream can set indirections_len to 0.  Even if it
> >
> > The migration stream originating from the source QEMU is trusted.
> 
> Is it? In https://www.qemu.org/docs/master/system/security.html we say:
> 
> # The following entities are untrusted, meaning that they may be buggy
> # or malicious:
> 
> #  * Guest
> #  * User-facing interfaces (e.g. VNC, SPICE, WebSocket)
> #  * Network protocols (e.g. NBD, live migration)
> #  * User-supplied files (e.g. disk images, kernels, device trees)
> #  * Passthrough devices (e.g. PCI, USB)
> 
> which explicitly lists "live migration" as an untrusted entity.
> 
> I would definitely be extremely cautious about having a threat
> model where I had to distrust inbound migration data, but the
> above does suggest we aim to handle that, and we have I think
> in the past taken patches which add sanity-checking to the
> migration data.

My view of the migration stream is that we authenticate the client
at the point of connection (either explicitly with SASL, or implicitly
with a x509 certificate validation), and protect the data stream
integrity with TLS, or equivalent.

For the vmstate data, we simply expect that to reflect the current
QEMU configuration, and variation of that is liable to lead to
a crash or worse.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



  parent reply	other threads:[~2026-03-23 14:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-23 13:15 [PATCH] virtio-net: validate RSS indirections_len in post_load Junjie Cao
2026-03-23 13:41 ` Daniel P. Berrangé
2026-03-23 13:53   ` Peter Maydell
2026-03-23 13:57     ` Michael S. Tsirkin
2026-03-23 14:56       ` Daniel P. Berrangé
2026-03-23 15:25         ` Peter Maydell
2026-03-23 15:58           ` Daniel P. Berrangé
2026-03-23 16:15             ` Peter Maydell
2026-03-23 16:45               ` Daniel P. Berrangé
2026-03-23 14:11     ` Daniel P. Berrangé [this message]
2026-03-23 15:33       ` Peter Maydell
2026-03-23 13:56 ` Michael S. Tsirkin
2026-03-24  6:04 ` Junjie Cao

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=acFKLgvFAlP7asIp@redhat.com \
    --to=berrange@redhat.com \
    --cc=akihiko.odaki@daynix.com \
    --cc=jasowang@redhat.com \
    --cc=junjie.cao@intel.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=yuri.benditovich@daynix.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