From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42412 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Prd4y-0008Nd-41 for qemu-devel@nongnu.org; Mon, 21 Feb 2011 16:14:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Prd4x-0004kC-6H for qemu-devel@nongnu.org; Mon, 21 Feb 2011 16:14:00 -0500 Received: from moutng.kundenserver.de ([212.227.126.171]:52081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Prd4w-0004jk-OD for qemu-devel@nongnu.org; Mon, 21 Feb 2011 16:13:59 -0500 Message-ID: <4D62D58C.7060103@mail.berlios.de> Date: Mon, 21 Feb 2011 22:13:48 +0100 From: Stefan Weil MIME-Version: 1.0 Subject: [Qemu-devel] Pad short frames to minimum size (60 bytes) References: <1284842625-13920-1-git-send-email-stefanha@linux.vnet.ibm.com> <20100918212710.GB3981@laped.lan> <20100920104259.GA23898@redhat.com> <4C97C4A4.1030801@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Stefan Hajnoczi , Bruce Rogers , Stefan Hajnoczi , qemu-devel@nongnu.org, "Edgar E. Iglesias" Am 21.09.2010 11:16, schrieb Stefan Hajnoczi: > On Mon, Sep 20, 2010 at 9:31 PM, Anthony Liguori > wrote: >> 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 >>>> wrote: >>>>> This doesn't look right. AFAIK, MAC's dont pad on receive. >>>> I agree. NICs 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? It sounds like the root >> cause 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 The latest patch which was sent was for eepro100.c (Bruce Rogers), but any ethernet NIC has the same kind of problem. Does the majority still think that patching the MAC emulation is the right way (although real MACs don't pad on receive, as Edgar already explained)? Then all ethernet NIC emulations should handle the padding in the same way. The code should be marked as a workaround which has nothing to do with the MAC emulation. MAC emulation code for short frames should not be removed. If there is consensus on this, I'll send a modified patch for eepro100.c (or Bruce modifies his patch so it does add the workaround comment without removing the short frame code). The better way would be padding in qemu's network code for those devices which need it (that means adding a new flag "min_frame_length" for ethernet devices). Stefan W.