From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51234 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OxzAH-0006KF-Ib for qemu-devel@nongnu.org; Tue, 21 Sep 2010 05:29:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oxz7H-0005xY-IU for qemu-devel@nongnu.org; Tue, 21 Sep 2010 05:26:33 -0400 Received: from adelie.canonical.com ([91.189.90.139]:46359) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oxz7H-0005xH-Br for qemu-devel@nongnu.org; Tue, 21 Sep 2010 05:26:23 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by adelie.canonical.com with esmtp (Exim 4.69 #1 (Debian)) id 1Oxz7E-0000GH-Jj for ; Tue, 21 Sep 2010 10:26:21 +0100 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id F048A2E81EF for ; Tue, 21 Sep 2010 09:25:59 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Sep 2010 09:16:42 -0000 From: Stefan Hajnoczi <638955@bugs.launchpad.net> Sender: bounces@canonical.com References: <20100915132907.2955.78648.malonedeb@gandwana.canonical.com> <4C97C4A4.1030801@codemonkey.ws> Message-Id: Subject: [Bug 638955] Re: [Qemu-devel] [PATCH] e1000: Pad short frames to minimum size (60 bytes) Errors-To: bounces@canonical.com Reply-To: Bug 638955 <638955@bugs.launchpad.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Mon, Sep 20, 2010 at 9:31 PM, Anthony Liguori wr= ote: > On 09/20/2010 05:42 AM, Michael S. Tsirkin wrote: >> >> On Sun, Sep 19, 2010 at 07:36:51AM +0100, Stefan Hajnoczi wrote: >> >>> >>> On Sat, Sep 18, 2010 at 10:27 PM, Edgar E. Iglesias >>> =C2=A0wrote: >>> >>>> >>>> This doesn't look right. AFAIK, MAC's dont pad on receive. >>>> >>> >>> I agree. =C2=A0NICs that do padding will do it on transmit, not receive. >>> Anything coming in on the wire should already have the minimum length. >>> >> >> QEMU never gets access to the wire. >> Our APIs do not really pass complete ethernet packets: >> we forward packets without checksum and padding. >> >> I think it makes complete sense to keep this and >> handle padding in devices because we >> have devices that pass the frame to guest without padding and checksum. >> It should be easy to replace padding code in devices that >> need it with some kind of macro. >> > > Would this not also address the problem? =C2=A0It sounds like the root ca= use is > the tap code, not the devices.. This won't work when s->has_vnet_hdr is 1 because the virtio-net header consumes buffer space and reduces the amount we pad. The padding size should be 60 + (s->has_vnet_hdr ? sizeof(struct virtio_net_hdr) : 0). Adjusting the length without clearing the untouched buffer space is probably fine. I'm trying to think of a scenario where this becomes an information leak (security issue). Perhaps if the guest has vlans enabled and allows different users to sniff traffic only on their vlans? Then you may be able to read part of another vlan's traffic by sending short packets to your vlan and gathering the padding data. This is pretty contrived but doing a <60 byte memset would prevent the issue for sure. Stefan -- = emulated netcards don't work with recent sunos kernel https://bugs.launchpad.net/bugs/638955 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: hi there, i'm using qemu-kvm backend in version: # qemu-kvm -version QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 = Fabrice Bellard and there are just *not working any of model=3D$type with combinations of r= ecent sunos (solaris, openindiana, opensolaris, ..) .. you can download for testing purposes iso from here: http://dlc-origin.open= indiana.org/isos/147/ or from here: http://genunix.org/distributions/indian= a/ << osol and oi are also bubuntu-like *live cds, so no need to bother wit= h installing behaviour is as follows: e1000 - receiving doesn't work, transmitting works .. dladm (tool for handl= e ethers) shows that is all ok, correct mode is loaded up, it just seems li= ke this driver works at 100% but .. rtl8169|pcnet - works in 10Mbit mode with several other issues like high cp= u utilization and so .. dladm is unable to recognize options for this kind = of -nic others - just don't work .. i experienced this issue several times in past .. woraround was, that rt= l8169 worked so-so .. with recent sunos kernel it doesn't. it's easy to reproduce, this is why i'm not putting here more then launchin= g script for my virtual machine: # cat openindiana.sh qemu-kvm -hda /home/kvm/openindiana/openindiana.img -m 2048 -localtime -cdr= om /home/kvm/+images/oi-dev-147-x86.iso -boot d \ -vga std -vnc :9 -k en-us -monitor unix:/home/kvm/openindiana/instance,serv= er,nowait \ -net nic,model=3De1000,vlan=3D1 -net tap,ifname=3Doi0,script=3Dno,vlan=3D1 & sleep 2; ip l set oi0 up; ip a a 192.168.99.9/24 dev oi0; regards by daniel