Skip to content
  • Eric Blake's avatar
    d21a2d34
    nbd/client: Add nbd_receive_export_list() · d21a2d34
    Eric Blake authored
    
    
    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: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarRichard W.M. Jones <rjones@redhat.com>
    Message-Id: <20190117193658.16413-18-eblake@redhat.com>
    Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    d21a2d34
    nbd/client: Add nbd_receive_export_list()
    Eric Blake authored
    
    
    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: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarRichard W.M. Jones <rjones@redhat.com>
    Message-Id: <20190117193658.16413-18-eblake@redhat.com>
    Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Loading