Re: [Qemu-devel] [PATCH 06/18] nbd: Avoid magic number for NBD max name size

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]

On 04/09/2016 04:35 AM, Alex Bligh wrote:
> 
> On 8 Apr 2016, at 23:05, Eric Blake <eblake@redhat.com> wrote:
> 
>> Declare a constant and use that when determining if an export
>> name fits within the constraints we are willing to support.
>>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
>> ---

>> +/* Maximum size of an export name */
>> +#define NBD_MAX_NAME_SIZE 255
> 
> Given the standard is either likely to or does (can't
> remember whether that patch is merged) document the
> maximum supported export length as 4096, why not change
> this to 4096?

I think I'd rather change the limit in a separate patch, auditing to
make sure that it works.  The current NBD Protocol states:

Where this document refers to a string, then unless otherwise stated,
that string is a sequence of UTF-8 code points, which is not NUL
terminated, MUST NOT contain NUL characters, SHOULD be no longer than
256 bytes and MUST be no longer than 4096 bytes.

So I agree that 255 is too small - a client sending 256 bytes and being
rejected by the server is a bug in the server, while a client sending
4096 bytes and being rejected by the server is not a protocol violation,
just poorer quality of implementation. Also, I think that the server
should gracefully reject the client for 4096 (as in a nice
NBD_ERR_REP_POLICY in response to NBD_OPT_INFO, stating that "your
request was valid by protocol, but not something I'm willing to
handle"), rather than abruptly disconnecting; while dealing with a
client that sends a 100M name is more likely to be a Denial-of-service
attack where an abrupt disconnect is nicer than wasting time reading to
the end of the client's message.

On the other hand, 4096 bytes is big enough that you can't safely stack
allocate (we are trying to get qemu to the point where it can be
compiled with gcc's options to warn on any function that requires more
than 4096 bytes for the entire function, as that is the largest safe
amount you can have before you can run into stack overflow turning what
is supposed to be SIGSEGV into a hard kill on Windows, if you get
unlucky enough to skip over the guard page).  Also, qemu has smaller
limits in other places (for example, no more than 1024 bytes for the
name of a qcow2 backing file), so it does no good to make qemu support
4096 bytes in NBD if it can't pass that on to the rest of qemu.

At any rate, I should probably stick this above explanation in the
commit message (or else do the audit, and merge it into this patch after
all, even if I pick a different limit than 4096).

> 
> Otherwise:
> 
> Reviewed-by: Alex Bligh <alex@alex.org.uk>
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]