[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] add fd limitations for avoiding a buffer overfl
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH] add fd limitations for avoiding a buffer overflow |
Date: |
Fri, 25 Jan 2013 15:30:34 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Jan 25, 2013 at 04:14:49PM +0800, Amos Kong wrote:
> FD_SET() and FD_CLR() are used to add and remove one descriptor from a
> set, the 'fd' should be less than FD_SETSIZE. Glibc will give a warning
> and crash the qemu when we set a fd (1024) to a set.
>
> # qemu -device virtio-net-pci,netdev=macvtap_netdev,mac=92:ff:8a:11:fe:57
> -netdev tap,id=macvtap_netdev,fd=1024 1024<>/dev/tap4
>
> *** buffer overflow detected ***: x86_64-softmmu/qemu-system-x86_64
> terminated
> ======= Backtrace: =========
> /lib64/libc.so.6(__fortify_fail+0x37)[0x7f842a2134a7]
> /lib64/libc.so.6(+0x35e9d08620)[0x7f842a211620]
> /lib64/libc.so.6(+0x35e9d0a417)[0x7f842a213417]
> x86_64-softmmu/qemu-system-x86_64(+0x1901fd)[0x7f842f09f1fd]
> x86_64-softmmu/qemu-system-x86_64(+0x198388)[0x7f842f0a7388]
> x86_64-softmmu/qemu-system-x86_64(main+0xfa9)[0x7f842ef897a9]
> /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f842a12aa05]
> x86_64-softmmu/qemu-system-x86_64(+0x7ed49)[0x7f842ef8dd49]
> ======= Memory map: ========
> ....
>
> This patch added limitations when init tap device and set fd handler
> for synchronous IO.
>
> Signed-off-by: Amos Kong <address@hidden>
> ---
> iohandler.c | 3 +++
> net/tap.c | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletions(-)
It would be much nicer to avoid fd_set than to add error code paths for
this API limitation.
With increased use of thread eventfds/pipe notification as seen in
vhost-net and virtio-blk-data-plane, the chance of really hitting 1024
file descriptors is growing. I've already seen a PCI multifunction test
case where we exceed 1024 fds :(.
Anthony, Paolo: Is there an alternative to select(2)? I think this was
discussed a bit during the glib event loop integration.
The two requirements I can think of are:
1. Portable so that we don't have to write OS-specific versions (epoll,
kqueue, etc).
2. Sub-millisecond timeouts.
Maybe we can use timerfd (and emulate it on non-Linux hosts) and then
fully use the glib event loop?
Internally glib prefers poll(2) but will fall back to select(2) on weird
OSes. On Windows it has dedicated code.
Stefan