Skip to content
Snippets Groups Projects
  • Daniel P. Berrangé's avatar
    e7b347d0
    net: detect errors from probing vnet hdr flag for TAP devices · e7b347d0
    Daniel P. Berrangé authored
    
    When QEMU sets up a tap based network device backend, it mostly ignores errors
    reported from various ioctl() calls it makes, assuming the TAP file descriptor
    is valid. This assumption can easily be violated when the user is passing in a
    pre-opened file descriptor. At best, the ioctls may fail with a -EBADF, but if
    the user passes in a bogus FD number that happens to clash with a FD number that
    QEMU has opened internally for another reason, a wide variety of errnos may
    result, as the TUNGETIFF ioctl number may map to a completely different command
    on a different type of file.
    
    By ignoring all these errors, QEMU sets up a zombie network backend that will
    never pass any data. Even worse, when QEMU shuts down, or that network backend
    is hot-removed, it will close this bogus file descriptor, which could belong to
    another QEMU device backend.
    
    There's no obvious guaranteed reliable way to detect that a FD genuinely is a
    TAP device, as opposed to a UNIX socket, or pipe, or something else. Checking
    the errno from probing vnet hdr flag though, does catch the big common cases.
    ie calling TUNGETIFF will return EBADF for an invalid FD, and ENOTTY when FD is
    a UNIX socket, or pipe which catches accidental collisions with FDs used for
    stdio, or monitor socket.
    
    Previously the example below where bogus fd 9 collides with the FD used for the
    chardev saw:
    
    $ ./x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hostnet0,fd=9 \
      -chardev socket,id=charchannel0,path=/tmp/qga,server,nowait \
      -monitor stdio -vnc :0
    qemu-system-x86_64: -netdev tap,id=hostnet0,fd=9: TUNGETIFF ioctl() failed: Inappropriate ioctl for device
    TUNSETOFFLOAD ioctl() failed: Bad address
    QEMU 2.9.1 monitor - type 'help' for more information
    (qemu) Warning: netdev hostnet0 has no peer
    
    which gives a running QEMU with a zombie network backend.
    
    With this change applied we get an error message and QEMU immediately exits
    before carrying on and making a bigger disaster:
    
    $ ./x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hostnet0,fd=9 \
      -chardev socket,id=charchannel0,path=/tmp/qga,server,nowait \
      -monitor stdio -vnc :0
    qemu-system-x86_64: -netdev tap,id=hostnet0,vhost=on,fd=9: Unable to query TUNGETIFF on FD 9: Inappropriate ioctl for device
    
    Reported-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
    Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
    Tested-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
    Message-id: 20171027085548.3472-1-berrange@redhat.com
    [lv: to simplify, don't check on EINVAL with TUNGETIFF as it exists since v2.6.27]
    Signed-off-by: default avatarLaurent Vivier <lvivier@redhat.com>
    Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
    e7b347d0
    History
    net: detect errors from probing vnet hdr flag for TAP devices
    Daniel P. Berrangé authored
    
    When QEMU sets up a tap based network device backend, it mostly ignores errors
    reported from various ioctl() calls it makes, assuming the TAP file descriptor
    is valid. This assumption can easily be violated when the user is passing in a
    pre-opened file descriptor. At best, the ioctls may fail with a -EBADF, but if
    the user passes in a bogus FD number that happens to clash with a FD number that
    QEMU has opened internally for another reason, a wide variety of errnos may
    result, as the TUNGETIFF ioctl number may map to a completely different command
    on a different type of file.
    
    By ignoring all these errors, QEMU sets up a zombie network backend that will
    never pass any data. Even worse, when QEMU shuts down, or that network backend
    is hot-removed, it will close this bogus file descriptor, which could belong to
    another QEMU device backend.
    
    There's no obvious guaranteed reliable way to detect that a FD genuinely is a
    TAP device, as opposed to a UNIX socket, or pipe, or something else. Checking
    the errno from probing vnet hdr flag though, does catch the big common cases.
    ie calling TUNGETIFF will return EBADF for an invalid FD, and ENOTTY when FD is
    a UNIX socket, or pipe which catches accidental collisions with FDs used for
    stdio, or monitor socket.
    
    Previously the example below where bogus fd 9 collides with the FD used for the
    chardev saw:
    
    $ ./x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hostnet0,fd=9 \
      -chardev socket,id=charchannel0,path=/tmp/qga,server,nowait \
      -monitor stdio -vnc :0
    qemu-system-x86_64: -netdev tap,id=hostnet0,fd=9: TUNGETIFF ioctl() failed: Inappropriate ioctl for device
    TUNSETOFFLOAD ioctl() failed: Bad address
    QEMU 2.9.1 monitor - type 'help' for more information
    (qemu) Warning: netdev hostnet0 has no peer
    
    which gives a running QEMU with a zombie network backend.
    
    With this change applied we get an error message and QEMU immediately exits
    before carrying on and making a bigger disaster:
    
    $ ./x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hostnet0,fd=9 \
      -chardev socket,id=charchannel0,path=/tmp/qga,server,nowait \
      -monitor stdio -vnc :0
    qemu-system-x86_64: -netdev tap,id=hostnet0,vhost=on,fd=9: Unable to query TUNGETIFF on FD 9: Inappropriate ioctl for device
    
    Reported-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
    Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
    Tested-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
    Message-id: 20171027085548.3472-1-berrange@redhat.com
    [lv: to simplify, don't check on EINVAL with TUNGETIFF as it exists since v2.6.27]
    Signed-off-by: default avatarLaurent Vivier <lvivier@redhat.com>
    Signed-off-by: default avatarJason Wang <jasowang@redhat.com>