From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ap12n-00071P-0k for qemu-devel@nongnu.org; Sat, 09 Apr 2016 18:07:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ap12l-0000ql-UV for qemu-devel@nongnu.org; Sat, 09 Apr 2016 18:07:52 -0400 References: <1460153158-21612-1-git-send-email-eblake@redhat.com> <1460153158-21612-7-git-send-email-eblake@redhat.com> From: Eric Blake Message-ID: <57097D2F.9010304@redhat.com> Date: Sat, 9 Apr 2016 16:07:43 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R85TPADTACoD16VGpcS2UkHr9KXleel5j" Subject: Re: [Qemu-devel] [PATCH 06/18] nbd: Avoid magic number for NBD max name size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "qemu-devel@nongnu.org" , Kevin Wolf , Paolo Bonzini , "open list:Block layer core" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R85TPADTACoD16VGpcS2UkHr9KXleel5j Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/09/2016 04:35 AM, Alex Bligh wrote: >=20 > On 8 Apr 2016, at 23:05, Eric Blake wrote: >=20 >> 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 >> --- >> +/* Maximum size of an export name */ >> +#define NBD_MAX_NAME_SIZE 255 >=20 > 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). >=20 > Otherwise: >=20 > Reviewed-by: Alex Bligh >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --R85TPADTACoD16VGpcS2UkHr9KXleel5j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXCX0vAAoJEKeha0olJ0NqiUcH/1V0UAWGjgxFobkIo00Rre1m taQVXDVOLP6BIuDL5fWVvSZMDKnvwK8WTOWm98pYEz+oI6CAsZc0PTiJXme+HZwl HXWKgaMzNd6lEvdTUP4ZT0B4T8WJ3qli7h2muSAZ2zsy07R9bke1mAgqAPj0aCPt OOjB6ByjYn0FihSyuhB0CfpXL3YL/jMfvGXsBbvaKfTIJrthfYZOzWqF36Kfp+QJ Qk7li/+DhbLWb2G4UBsx+pE7iX0w6D8gd84VHO4EIp+88ggkpmxr6oZV2RC0Teft rlG3igH517UVaSekITWtUMLg7YyqD/gE0UyGWhFCihitYtK+KOqqS+UYKBjWQwQ= =Wn5+ -----END PGP SIGNATURE----- --R85TPADTACoD16VGpcS2UkHr9KXleel5j--