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). > > However, migration is hardly the worst offender here, and I am > not at all sure we need to start with it if we even want > to address this limitation. Agree. Thanks, -- Peter Xu
