[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1443022920.74600.13.camel@infradead.org>
Date: Wed, 23 Sep 2015 16:42:00 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org
Subject: Re: [RFC PATCH 1/3] Avoid making inappropriate requests of
NETIF_F_V[46]_CSUM devices
On Mon, 2015-09-21 at 17:29 +0100, David Woodhouse wrote:
>
> Did we ever resolve this? AFAICT from inspecting the code the
> virtio_net device still advertises hardware csum capabilities to the
> guest. And accepts packets which need checksumming, calling
> skb_partial_csum_set() as appropriate. Likewise tun, xen, macvtap and
> af_packet.
Here's a test case which provokes the network stack into handing a
CHECKSUM_PARTIAL skb to a device which it knows can't handle it. (It
obviously needs the AF_PACKET endianness ABI fix I sent earlier.)
You might well be right to refer to this as 'injecting unchecked crap',
but we are *gaining* injection points with the ability to do this, and
for not entirely insane reasons — people want to be able to make full
use of hardware offload capabilities.
And we *have* a safety check, to avoid handing CHECKSUM_PARTIAL buffers
to devices which can't handle them. We already do check the
capabilities of the device we end up routing it to, and complete the
checksum in software if the device can't cope.
All we're talking about here is a corner case when that existing check
doesn't actually give the right results, because it assumes a device
with NETIF_F_IP_CSUM can checksum *all* Legacy IP packets, not just TCP
and UDP.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@...el.com Intel Corporation
View attachment "raw.c" of type "text/x-csrc" (3051 bytes)
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5691 bytes)
Powered by blists - more mailing lists