On 05/11/2016 01:00 PM, Alex Bligh wrote: > Eric, > > I'm not convinced this fixes anything. > > You're now saying you MAY treat anything over 16k as a > denial of service attack. But in the existing text, you > MAY do that anyway - you don't have to treat all lengths > alike for all commands. Yes, but I'm about to post another patch for block sizes, where it is recommended that the denial of service length during transmission phase is 32M (since that matches the current kernel implementation, as well as the qemu implementation) - anything smaller than reduces portability. Calling out a MUCH smaller limit of 16k during handshake phase in contrast to transmission phase, and acknowledging that we have bytes in transmission phase that will always be 0 without some other extension to state otherwise, seems worthwhile. If nothing else, writing down our minimum size at which denial of service may occur will make sure that our future additions consider those lengths, and give clients something to be aware of even when servers don't advertise limits. Currently, qemu's denial of service limit is set to 32M for all messages, including option haggling, which is much larger than the 16k I'm proposing here. But wading through 32M of garbage from a client is a lot to ask of a server that wants to get to transmission phase as soon as possible, and if we take this patch, I will be updating qemu to have two different maximum message sizes (one for options, the other for transmission). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature