diff options
author | Eric Blake <eblake@redhat.com> | 2019-01-17 13:36:54 -0600 |
---|---|---|
committer | Eric Blake <eblake@redhat.com> | 2019-01-21 15:49:52 -0600 |
commit | d21a2d3451d7f1defea5104ce28938f228fab0d4 (patch) | |
tree | 1f4c9be8d8156169966861e8a48b2555ba4c2be5 /blockdev.c | |
parent | 138796d0f545ad4b6c74ad2cbe5f6e08c454a0b9 (diff) | |
download | qemu-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