- Jun 11, 2021
-
-
Rao, Lei authored
The data pointer has skipped vnet_hdr_len in the function of parse_packet_early().So, we can not subtract vnet_hdr_len again when calculating pkt->header_size in fill_pkt_tcp_info(). Otherwise, it will cause network packet comparsion errors and greatly increase the frequency of checkpoints. Signed-off-by:
Lei Rao <lei.rao@intel.com> Signed-off-by:
Zhang Chen <chen.zhang@intel.com> Reviewed-by:
Li Zhijian <lizhijian@fujitsu.com> Reviewed-by:
Zhang Chen <chen.zhang@intel.com> Reviewed-by:
Lukas Straub <lukasstraub2@web.de> Tested-by:
Lukas Straub <lukasstraub2@web.de> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Rao, Lei authored
This patch fixes the following: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f6ae4559859 in __GI_abort () at abort.c:79 #2 0x0000559aaa386720 in error_exit (err=16, msg=0x559aaa5973d0 <__func__.16227> "qemu_mutex_destroy") at util/qemu-thread-posix.c:36 #3 0x0000559aaa3868c5 in qemu_mutex_destroy (mutex=0x559aabffe828) at util/qemu-thread-posix.c:69 #4 0x0000559aaa2f93a8 in char_finalize (obj=0x559aabffe800) at chardev/char.c:285 #5 0x0000559aaa23318a in object_deinit (obj=0x559aabffe800, type=0x559aabfd7d20) at qom/object.c:606 #6 0x0000559aaa2331b8 in object_deinit (obj=0x559aabffe800, type=0x559aabfd9060) at qom/object.c:610 #7 0x0000559aaa233200 in object_finalize (data=0x559aabffe800) at qom/object.c:620 #8 0x0000559aaa234202 in object_unref (obj=0x559aabffe800) at qom/object.c:1074 #9 0x0000559aaa2356b6 in object_finalize_child_property (obj=0x559aac0dac10, name=0x559aac778760 "compare0-0", opaque=0x559aabffe800) at qom/object.c:1584 #10 0x0000559aaa232f70 in object_property_del_all (obj=0x559aac0dac10) at qom/object.c:557 #11 0x0000559aaa2331ed in object_finalize (data=0x559aac0dac10) at qom/object.c:619 #12 0x0000559aaa234202 in object_unref (obj=0x559aac0dac10) at qom/object.c:1074 #13 0x0000559aaa2356b6 in object_finalize_child_property (obj=0x559aac0c75c0, name=0x559aac0dadc0 "chardevs", opaque=0x559aac0dac10) at qom/object.c:1584 #14 0x0000559aaa233071 in object_property_del_child (obj=0x559aac0c75c0, child=0x559aac0dac10, errp=0x0) at qom/object.c:580 #15 0x0000559aaa233155 in object_unparent (obj=0x559aac0dac10) at qom/object.c:599 #16 0x0000559aaa2fb721 in qemu_chr_cleanup () at chardev/char.c:1159 #17 0x0000559aa9f9b110 in main (argc=54, argv=0x7ffeb62fa998, envp=0x7ffeb62fab50) at vl.c:4539 When chardev is cleaned up, chr_write_lock needs to be destroyed. But the colo-compare module is not cleaned up normally before it when the guest poweroff. It is holding chr_write_lock at this time. This will cause qemu crash.So we add the function of colo_compare_cleanup() before qemu_chr_cleanup() to fix the bug. Signed-off-by:
Lei Rao <lei.rao@intel.com> Reviewed-by:
Zhang Chen <chen.zhang@intel.com> Reviewed-by:
Lukas Straub <lukasstraub2@web.de> Tested-by:
Lukas Straub <lukasstraub2@web.de> Signed-off-by:
Zhang Chen <chen.zhang@intel.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Rao, Lei authored
Use the packet_new_nocopy instead of packet_new in the filter-rewriter module. There will be one less memory copy in the processing of each network packet. Signed-off-by:
Lei Rao <lei.rao@intel.com> Signed-off-by:
Zhang Chen <chen.zhang@intel.com> Reviewed-by:
Zhang Chen <chen.zhang@intel.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Rao, Lei authored
The iov_size has been calculated in filter_send(). we can directly return the size.In this way, this is no need to repeat calculations in filter_redirector_receive_iov(); Signed-off-by:
Lei Rao <lei.rao@intel.com> Reviewed-by:
Li Zhijian <lizhijian@fujitsu.com> Reviewed-by:
Zhang Chen <chen.zhang@intel.com> Reviewed-by:
Lukas Straub <lukasstraub2@web.de> Tested-by:
Lukas Straub <lukasstraub2@web.de> Signed-off-by:
Zhang Chen <chen.zhang@intel.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Rao, Lei authored
There is the same trace code in the colo_compare_packet_payload. Signed-off-by:
Lei Rao <lei.rao@intel.com> Reviewed-by:
Li Zhijian <lizhijian@fujitsu.com> Reviewed-by:
Zhang Chen <chen.zhang@intel.com> Reviewed-by:
Lukas Straub <lukasstraub2@web.de> Tested-by:
Lukas Straub <lukasstraub2@web.de> Signed-off-by:
Zhang Chen <chen.zhang@intel.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Jason Wang authored
No user for this helper, let's remove it. Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
- Jun 04, 2021
-
-
Andrew Melnychenko authored
When RSS is enabled the device tries to load the eBPF program to select RX virtqueue in the TUN. If eBPF can be loaded the RSS will function also with vhost (works with kernel 5.8 and later). Software RSS is used as a fallback with vhost=off when eBPF can't be loaded or when hash population requested by the guest. Signed-off-by:
Yuri Benditovich <yuri.benditovich@daynix.com> Signed-off-by:
Andrew Melnychenko <andrew@daynix.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Andrew Melnychenko authored
For now, that method supported only by Linux TAP. Linux TAP uses TUNSETSTEERINGEBPF ioctl. Signed-off-by:
Andrew Melnychenko <andrew@daynix.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Andrew Melnychenko authored
Additional code that will be used for eBPF setting steering routine. Signed-off-by:
Andrew Melnychenko <andrew@daynix.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
- Jun 02, 2021
-
-
Stefano Garzarella authored
Commit e50caf4a ("tracing: convert documentation to rST") converted docs/devel/tracing.txt to docs/devel/tracing.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/tracing.txt/tracing.rst/ $(git grep -l docs/devel/tracing.txt) Signed-off-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210517151702.109066-2-sgarzare@redhat.com> Signed-off-by:
Thomas Huth <thuth@redhat.com>
-
- May 27, 2021
-
-
Brad Smith authored
OpenBSD added support for tap(4) 10 releases ago. Remove the special casing for older releases. Signed-off-by:
Brad Smith <brad@comstyle.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
- May 04, 2021
-
-
Joelle van Dyne authored
Replace Windows specific macro with a more generic feature detection macro. Allows slirp smb feature to be disabled manually as well. Acked-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Joelle van Dyne <j@getutm.app> Message-Id: <20210315180341.31638-5-j@getutm.app> [Use $default_feature as the default. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- May 02, 2021
-
-
Thomas Huth authored
Stop including sysemu/sysemu.h in files that don't need it. Signed-off-by:
Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-2-thuth@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
Thomas Huth authored
Many files include qemu/log.h without needing it. Remove the superfluous include statements. Signed-off-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210328054833.2351597-1-thuth@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
- Apr 23, 2021
-
-
Jason Wang authored
There could be case that peer is NULL. This can happen when during network device hot-add where net device needs to be added first. So the patch check the existence of peer before trying to do the pad. Fixes: 969e50b6 ("net: Pad short frames to minimum size before sending from SLiRP/TAP") Signed-off-by:
Jason Wang <jasowang@redhat.com> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com> Reviewed-by:
Stefan Weil <sw@weilnetz.de> Message-id: 20210423031803.1479-1-jasowang@redhat.com Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Apr 08, 2021
-
-
Jason Wang authored
Commit 969e50b6 ("net: Pad short frames to minimum size before sending from SLiRP/TAP") tries to pad frames but try to recyle the local array that is used for padding to tap thread. This patch fixes this by recyling the original buffer. Fixes: 969e50b6 ("net: Pad short frames to minimum size before sending from SLiRP/TAP") Tested-by:
Howard Spoelstra <hsp.cat7@gmail.com> Tested-by:
Bin Meng <bmeng.cn@gmail.com> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Jason Wang authored
Several issues has been reported for query-netdev series. Consider it's late in the rc, this reverts commit d32ad10a. Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Jason Wang authored
Several issues has been reported for query-netdev info series. Consider it's late in the rc, this reverts commit commit 59b5437e. Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Jason Wang authored
Several issues has been reported for query-netdev info series. Consider it's late in the rc, this reverts commit a0724776. Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Jason Wang authored
Several issues has been reported for query-netdev info series. Consider it's late in the rc, this reverts commit f2e8319d. Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
- Mar 22, 2021
-
-
Philippe Mathieu-Daudé authored
To simplify the function body, invert the if() statement, returning earlier. Since we already checked there is enough data in the iovec buffer, simply add an assert() call to consume the bytes_read variable. Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Miroslav Rezanina <mrezanin@redhat.com> Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Philippe Mathieu-Daudé authored
We can't know the caller read enough data in the memory pointed by ext_hdr to cast it as a ip6_ext_hdr_routing. Declare rt_hdr on the stack and fill it again from the iovec. Since we already checked there is enough data in the iovec buffer, simply add an assert() call to consume the bytes_read variable. This fix a 2 bytes buffer overrun in eth_parse_ipv6_hdr() reported by QEMU fuzzer: $ cat << EOF | ./qemu-system-i386 -M pc-q35-5.0 \ -accel qtest -monitor none \ -serial none -nographic -qtest stdio outl 0xcf8 0x80001010 outl 0xcfc 0xe1020000 outl 0xcf8 0x80001004 outw 0xcfc 0x7 write 0x25 0x1 0x86 write 0x26 0x1 0xdd write 0x4f 0x1 0x2b write 0xe1020030 0x4 0x190002e1 write 0xe102003a 0x2 0x0807 write 0xe1020048 0x4 0x12077cdd write 0xe1020400 0x4 0xba077cdd write 0xe1020420 0x4 0x190002e1 write 0xe1020428 0x4 0x3509d807 write 0xe1020438 0x1 0xe2 EOF ================================================================= ==2859770==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdef904902 at pc 0x561ceefa78de bp 0x7ffdef904820 sp 0x7ffdef904818 READ of size 1 at 0x7ffdef904902 thread T0 #0 0x561ceefa78dd in _eth_get_rss_ex_dst_addr net/eth.c:410:17 #1 0x561ceefa41fb in eth_parse_ipv6_hdr net/eth.c:532:17 #2 0x561cef7de639 in net_tx_pkt_parse_headers hw/net/net_tx_pkt.c:228:14 #3 0x561cef7dbef4 in net_tx_pkt_parse hw/net/net_tx_pkt.c:273:9 #4 0x561ceec29f22 in e1000e_process_tx_desc hw/net/e1000e_core.c:730:29 #5 0x561ceec28eac in e1000e_start_xmit hw/net/e1000e_core.c:927:9 #6 0x561ceec1baab in e1000e_set_tdt hw/net/e1000e_core.c:2444:9 #7 0x561ceebf300e in e1000e_core_write hw/net/e1000e_core.c:3256:9 #8 0x561cef3cd4cd in e1000e_mmio_write hw/net/e1000e.c:110:5 Address 0x7ffdef904902 is located in stack of thread T0 at offset 34 in frame #0 0x561ceefa320f in eth_parse_ipv6_hdr net/eth.c:486 This frame has 1 object(s): [32, 34) 'ext_hdr' (line 487) <== Memory access at offset 34 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow net/eth.c:410:17 in _eth_get_rss_ex_dst_addr Shadow bytes around the buggy address: 0x10003df188d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10003df188e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10003df188f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10003df18900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10003df18910: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 =>0x10003df18920:[02]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x10003df18930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10003df18940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10003df18950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10003df18960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10003df18970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Stack left redzone: f1 Stack right redzone: f3 ==2859770==ABORTING Add the corresponding qtest case with the fuzzer reproducer. FWIW GCC 11 similarly reported: net/eth.c: In function 'eth_parse_ipv6_hdr': net/eth.c:410:15: error: array subscript 'struct ip6_ext_hdr_routing[0]' is partly outside array bounds of 'struct ip6_ext_hdr[1]' [-Werror=array-bounds] 410 | if ((rthdr->rtype == 2) && (rthdr->segleft == 1)) { | ~~~~~^~~~~~~ net/eth.c:485:24: note: while referencing 'ext_hdr' 485 | struct ip6_ext_hdr ext_hdr; | ^~~~~~~ net/eth.c:410:38: error: array subscript 'struct ip6_ext_hdr_routing[0]' is partly outside array bounds of 'struct ip6_ext_hdr[1]' [-Werror=array-bounds] 410 | if ((rthdr->rtype == 2) && (rthdr->segleft == 1)) { | ~~~~~^~~~~~~~~ net/eth.c:485:24: note: while referencing 'ext_hdr' 485 | struct ip6_ext_hdr ext_hdr; | ^~~~~~~ Cc: qemu-stable@nongnu.org Buglink: https://bugs.launchpad.net/qemu/+bug/1879531 Reported-by:
Alexander Bulekov <alxndr@bu.edu> Reported-by:
Miroslav Rezanina <mrezanin@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Miroslav Rezanina <mrezanin@redhat.com> Fixes: eb700029 ("net_pkt: Extend packet abstraction as required by e1000e functionality") Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Philippe Mathieu-Daudé authored
We want to check fields from ip6_ext_hdr_routing structure and if correct read the full in6_address. Let's directly check if our iovec contains enough data for everything, else return early. Suggested-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Miroslav Rezanina <mrezanin@redhat.com> Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Philippe Mathieu-Daudé authored
Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Miroslav Rezanina <mrezanin@redhat.com> Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Philippe Mathieu-Daudé authored
The 'offset' argument represents the offset to the ip6_ext_hdr header, rename it as 'ext_hdr_offset'. Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Miroslav Rezanina <mrezanin@redhat.com> Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Philippe Mathieu-Daudé authored
The length field is already contained in the ip6_ext_hdr structure. Check it direcly in eth_parse_ipv6_hdr() before calling _eth_get_rss_ex_dst_addr(), which gets a bit simplified. Reviewed-by:
Miroslav Rezanina <mrezanin@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Philippe Mathieu-Daudé authored
The in6_address comes after the ip6_ext_hdr_routing header, not after the ip6_ext_hdr one. Fix the offset. Cc: qemu-stable@nongnu.org Reported-by:
Stefano Garzarella <sgarzare@redhat.com> Fixes: eb700029 ("net_pkt: Extend packet abstraction as required by e1000e functionality") Reviewed-by:
Miroslav Rezanina <mrezanin@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Lukas Straub authored
g_queue_remove needs to look up the list entry first, but we already have it as result and can remove it directly with g_queue_delete_link. Signed-off-by:
Lukas Straub <lukasstraub2@web.de> Signed-off-by:
Zhang Chen <chen.zhang@intel.com> Reviewed-by:
Zhang Chen <chen.zhang@intel.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Lukas Straub authored
Additional to removing the packet from the secondary queue, we also need to free it. Signed-off-by:
Lukas Straub <lukasstraub2@web.de> Signed-off-by:
Zhang Chen <chen.zhang@intel.com> Reviewed-by:
Zhang Chen <chen.zhang@intel.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Bin Meng authored
The minimum Ethernet frame length is 60 bytes. For short frames with smaller length like ARP packets (only 42 bytes), on a real world NIC it can choose either padding its length to the minimum required 60 bytes, or sending it out directly to the wire. Such behavior can be hardcoded or controled by a register bit. Similarly on the receive path, NICs can choose either dropping such short frames directly or handing them over to software to handle. On the other hand, for the network backends like SLiRP/TAP, they don't expose a way to control the short frame behavior. As of today they just send/receive data from/to the other end connected to them, which means any sized packet is acceptable. So they can send and receive short frames without any problem. It is observed that ARP packets sent from SLiRP/TAP are 42 bytes, and SLiRP/TAP just send these ARP packets to the other end which might be a NIC model that does not allow short frames to pass through. To provide better compatibility, for packets sent from QEMU network backends like SLiRP/TAP, we change to pad short frames before sending it out to the other end, if the other end does not forbid it via the nc->do_not_pad flag. This ensures a backend as an Ethernet sender does not violate the spec. But with this change, the behavior of dropping short frames from SLiRP/TAP interfaces in the NIC model cannot be emulated because it always receives a packet that is spec complaint. The capability of sending short frames from NIC models is still supported and short frames can still pass through SLiRP/TAP. This commit should be able to fix the issue as reported with some NIC models before, that ARP requests get dropped, preventing the guest from becoming visible on the network. It was workarounded in these NIC models on the receive path, that when a short frame is received, it is padded up to 60 bytes. The following 2 commits seem to be the one to workaround this issue in e1000 and vmxenet3 before, and should probably be reverted. commit 78aeb23e ("e1000: Pad short frames to minimum size (60 bytes)") commit 40a87c6c ("vmxnet3: Pad short frames to minimum size (60 bytes)") Signed-off-by:
Bin Meng <bmeng.cn@gmail.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Bin Meng authored
Add a helper to pad a short Ethernet frame to the minimum required length, which can be used by backends' code. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
- Mar 15, 2021
-
-
Alexey Kirillov authored
As we use QAPI NetClientState->stored_config to store and get information about backend network devices, we can drop fill of legacy field info_str for them. We still use info_str field for NIC and hubports, so we can not completely remove it. Signed-off-by:
Alexey Kirillov <lekiravi@yandex-team.ru> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Alexey Kirillov authored
Replace usage of legacy field info_str of NetClientState for backend network devices with QAPI NetdevInfo stored_config that already used in QMP query-netdev. This change increases the detail of the "info network" output and takes a more general approach to composing the output. NIC and hubports still use legacy info_str field. Signed-off-by:
Alexey Kirillov <lekiravi@yandex-team.ru> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Alexey Kirillov authored
The info_str field of the NetClientState structure is static and has a size of 256 bytes. This amount is often unclaimed, and the field itself is used exclusively for HMP "info network". The patch translates info_str to dynamic memory allocation. This action is also allows us to painlessly discard usage of this field for backend devices. Signed-off-by:
Alexey Kirillov <lekiravi@yandex-team.ru> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Alexey Kirillov authored
The query-netdev command is used to get the configuration of the current network device backends (netdevs). This is the QMP analog of the HMP command "info network" but only for netdevs (i.e. excluding NIC and hubports). The query-netdev command returns an array of objects of the NetdevInfo type, which are an extension of Netdev type. It means that response can be used for netdev-add after small modification. This can be useful for recreate the same netdev configuration. Information about the network device is filled in when it is created or modified and is available through the NetClientState->stored_config. Signed-off-by:
Alexey Kirillov <lekiravi@yandex-team.ru> Acked-by:
Markus Armbruster <armbru@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Jason Wang authored
Some NIC supports loopback mode and this is done by calling nc->info->receive() directly which in fact suppresses the effort of reentrancy check that is done in qemu_net_queue_send(). Unfortunately we can't use qemu_net_queue_send() here since for loopback there's no sender as peer, so this patch introduce a qemu_receive_packet() which is used for implementing loopback mode for a NIC with this check. NIC that supports loopback mode will be converted to this helper. This is intended to address CVE-2021-3416. Cc: Prasad J Pandit <ppandit@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Paolo Bonzini authored
When a network or network device is created from the command line or HMP, QemuOpts ensures that the id passes the id_wellformed check. However, QMP skips this: $ qemu-system-x86_64 -qmp stdio -S -nic user,id=123/456 qemu-system-x86_64: -nic user,id=123/456: Parameter id expects an identifier Identifiers consist of letters, digits, -, ., _, starting with a letter. $ qemu-system-x86_64 -qmp stdio -S {"execute":"qmp_capabilities"} {"return": {}} {"execute":"netdev_add", "arguments": {"type": "user", "id": "123/456"}} {"return": {}} After: $ qemu-system-x86_64 -qmp stdio -S {"execute":"qmp_capabilities"} {"return": {}} {"execute":"netdev_add", "arguments": {"type": "user", "id": "123/456"}} {"error": {"class": "GenericError", "desc": "Parameter "id" expects an identifier"}} Validity checks should be performed always at the bottom of the call chain, because QMP skips all the steps above. At the same time we know that every call chain should go through either QMP or (for legacy) through QemuOpts. Because the id for -net and -nic is automatically generated and not well-formed by design, just add the check to QMP. Cc: Jason Wang <jasowang@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
Bin Meng authored
"qemu-common.h" should be included to provide the forward declaration of qemu_hexdump() when DEBUG_NET is on. Signed-off-by:
Bin Meng <bin.meng@windriver.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com>
-
- Mar 09, 2021
-
-
Philippe Mathieu-Daudé authored
The 'running' argument from VMChangeStateHandler does not require other value than 0 / 1. Make it a plain boolean. Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Acked-by:
David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210111152020.1422021-3-philmd@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
Thomas Huth authored
We already got a global function called id_generate() to create unique IDs within QEMU. Let's use it in the network subsytem, too, instead of inventing our own ID scheme here. Signed-off-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20210215090225.1046239-1-thuth@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-