On 03/29/2018 07:04 AM, Vladimir Sementsov-Ogievskiy wrote:
28.03.2018 22:43, Eric Blake wrote:The existing text on block sizes had a redundant statement about hard disconnects on large requests, but did not specify a size where that comes into play. In practice, several NBD implementations have settled on 32M (qemu, kernel module) or 64M (nbdkit) as the limit for maximum request size (at the client) or hard disconnect size (at the server); thus we should document 32M as the portable limit that clients can expect and servers should support as a way to increase interoperability.
...
+to be deemed a denial of service attack; however, for maximum +portability, any length less than 2^25 (33,554,432) bytes SHOULD NOT +be considered a denial of service attack (even if the advertised +maximum block size is smaller).intersting: "any lengths", what is it? is it length field? Or overall length of the whole request, which will be a bit larger?
I'd argue that the server should accept a *length* field of 32M, which means the overall request is slightly larger (at least, that seems to match the implementations I've reviewed, which first do a fixed-length read of the header, then see what *length* field says to additionally read, and the size clamping is done on the length field, not on what was already previously read). Do we need any wording tweak along those lines, or is it already reasonably clear?
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org