Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > On 28/01/21 11:48, Maciej S. Szmigiero wrote: >>> >>> VMMs (especially big ones like QEMU) are complex and e.g. each driver >>> can cause memory regions (-> memslots in KVM) to change. With this >>> feature it becomes possible to set a limit upfront (based on VM >>> configuration) so it'll be more obvious when it's hit. >>> >> >> I see: it's a kind of a "big switch", so every VMM doesn't have to be >> modified or audited. >> Thanks for the explanation. > > Not really, it's the opposite: the VMM needs to opt into a smaller > number of memslots. > > I don't know... I understand it would be defense in depth, however > between dynamic allocation of memslots arrays and GFP_KERNEL_ACCOUNT, it > seems to be a bit of a solution in search of a problem. For now I > applied patches 1-2-5. An alternative with a new module parameter was also suggested, that would make it possible to protect against buggy/malicious VMMs but again, the attack is not any different from just creating many VMs. Module parameter will most like end up being unused 99,9% of the time (if not 100). I don't seem to have a strong opinion. -- Vitaly
