On Wed, Jul 29, 2026 at 01:13:27PM -0300, Fabiano Rosas wrote: > I was thinking the vmstate code could define a limit to the size (of > anything) and always enforce it. The device code can then use some > custom macros (not yet existent) to limit even further.
PS: one more thing to mention on "further limit": To me, that was not a real thing that will help anything for real users. My guess is, it will only be something we can use to "convince" people stop opening security tickets.. and say "hey, see, we have an upper bound". IMHO no limit is really fine for QEMU's complex use case, it's because QEMU is a complex userapp, if it's a daemon and more accessible we may need to be more careful, but it's not: it's a hypervisor, here migration protocol (as one of the network consumer) is very dedicated, perf / maintenance / .. matter more than that upper limit. There're other things that might be more risky, like if we have NBD server listening and it's more of an attack surface. Even if so, I still think a VM userapp is very special. If I design migration from scratch, I would allow some migration command to dynamically create ramblocks, for example, and obviously that can really be any size: limiting it to 4T will stop working when one wants to create a 12T VM. 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.. That's partly why personally I want us to spend less time on all these limits.. because then we only handle trusted data stream, we can keep in mind whenever we want to be safer, but it's not 100% required and it's different from adhoc network servers. When the protocol allows "arbitrary size" I think we should just let it happen, and IMHO it avoids unnecessary work. -- Peter Xu
