qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]