On Wed, Jul 29, 2026 at 06:08:27PM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 29, 2026 at 03:27:01PM -0400, Peter Xu wrote:
> > On Wed, Jul 29, 2026 at 02:57:57PM -0400, Michael S. Tsirkin wrote:
> > > On Wed, Jul 29, 2026 at 01:48:25PM -0400, Peter Xu wrote:
> > > > So to me, it's much simpler we say migration stream must be
> > > > trusted, and I expect dest QEMU can allocate any buffer it needs, until
> > > > it
> > > > eats the whole system memory. I really don't see much real risk..
> > >
> > > It's not risk due to migration, specifically. But making qemu
> > > drink up terabytes from the guest would be problematic, right?
> > >
> > > Putting qemu in a cgroup with restricted total memory
> > > would be one way to prevent this class of security issue,
> > > and a robust one.
> > >
> > > But that, in turn, is impossible if qemu insists on allocating
> > > unlimited memory at the drop of a hat.
> >
> > Just to clarify at least one thing.. we have two attack surfaces here and
> > they're very different IMHO:
> >
> > (1) guest behavior caused memory allocation, or,
> >
> > (2) migration stream caused memory allocation.
> >
> > AFAIU, (1) is more severe. All my points only apply to (2).
>
>
> Absolutely. Yet without fixing 2 we can't mitigate 1 with OS level
> protections.
Nowadays most of issues around migration stream can cause allocations are
about what we have already persisted internally to QEMU to maintain guest
states.
Takeing a GTree as example.
In guest context, one concrete example is GTree can contain unlimited
number of elements for a vIOMMU device to keep the mappings, before
migration we should better make sure the mapping isn't too much to eat all
host memory and get QEMU OOM killed.
In case of migration, it's about when migrating a GTree we will migrate
exactly whatever it is there already on src to dest, then a malicious
stream may cause unlimited allocations. That's one of the security
reports, we have similar ones for qlist, etc.
IOW, I think yes if we stick with "migration stream trusted" all issues
should be non-issue, and we should not worry about (2) too much, because we
really should majorly need to worry (1).. which is real, since guest is
never trusted..
Meanwhile, migration should still make sure it won't allocate anything else
than what has already been there for source QEMU. If we need such temp
allocation for migration only, that's the real part where a migration
security issue may reside, but so far none of the reports is about
that... I also can't think of a lot that migration does allocation on its
own for things that can occupy a lot of memory, some might be relevant I
can still think of is bitmaps all over, that's unfortunate, we need them
for various reasons, either on src/dst.. say, kvm also has bitmaps of such,
only allocated during migrations, not easily avoidable.
Another example is QEMU_VM_VMDESCRIPTION that is definitely migration
specific (not part of src QEMU), but dest is already careful there, in
qemu_loadvm_state():
if (ret == 0 && should_send_vmdesc()) {
...
if (section_type != QEMU_VM_VMDESCRIPTION) {
...
} else {
buf = g_malloc(0x1000);
size = qemu_get_be32(f);
while (size > 0) {
uint32_t read_chunk = MIN(size, 0x1000);
qemu_get_buffer(f, buf, read_chunk);
size -= read_chunk;
}
g_free(buf);
}
I also remember VFIO has some internal buffering only used in migration, I
also remember when I reviewed it I tried to point out the buffer limitation
issue I hope it was properly settled..
I hope we're always careful on those otherwise, but these cases should be
rare.
Thanks,
--
Peter Xu
