17.01.2019 22:36, Eric Blake wrote: > We want to be able to detect whether a given qemu NBD server is > exposing the right export(s) and dirty bitmaps, at least for > regression testing. We could use 'nbd-client -l' from the upstream > NBD project to list exports, but it's annoying to rely on > out-of-tree binaries; furthermore, nbd-client doesn't necessarily > know about all of the qemu NBD extensions. Thus, we plan on adding > a new mode to qemu-nbd that merely sniffs all possible information > from the server during handshake phase, then disconnects and dumps > the information. > > This patch adds the low-level client code for grabbing the list > of exports. It benefits from the recent refactoring patches, in > order to share as much code as possible when it comes to doing > validation of server replies. The resulting information is stored > in an array of NBDExportInfo which has been expanded to any > description string, along with a convenience function for freeing > the list. > > Note: a malicious server could exhaust memory of a client by feeding > an unending loop of exports; perhaps we should place a limit on how > many we are willing to receive. But note that a server could > reasonably be serving an export for every file in a large directory, > where an arbitrary limit in the client means we can't list anything > from such a server; the same happens if we just run until the client > fails to malloc() and thus dies by an abort(), where the limit is > no longer arbitrary but determined by available memory. Since the > client is already planning on being short-lived, it's hard to call > this a denial of service attack that would starve off other uses, > so it does not appear to be a security issue. > > Signed-off-by: Eric Blake<ebl...@redhat.com> > Reviewed-by: Richard W.M. Jones<rjo...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> -- Best regards, Vladimir
