aboutsummaryrefslogtreecommitdiff
path: root/blockdev.c
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2019-01-17 13:36:54 -0600
committerEric Blake <eblake@redhat.com>2019-01-21 15:49:52 -0600
commitd21a2d3451d7f1defea5104ce28938f228fab0d4 (patch)
tree1f4c9be8d8156169966861e8a48b2555ba4c2be5 /blockdev.c
parent138796d0f545ad4b6c74ad2cbe5f6e08c454a0b9 (diff)
downloadqemu-d21a2d3451d7f1defea5104ce28938f228fab0d4.zip
qemu-d21a2d3451d7f1defea5104ce28938f228fab0d4.tar.gz
qemu-d21a2d3451d7f1defea5104ce28938f228fab0d4.tar.bz2
nbd/client: Add nbd_receive_export_list()
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 <eblake@redhat.com> Reviewed-by: Richard W.M. Jones <rjones@redhat.com> Message-Id: <20190117193658.16413-18-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Diffstat (limited to 'blockdev.c')
0 files changed, 0 insertions, 0 deletions