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