netdev - Re: [RFC 2/2] e1000e: Support RXALL feature flag.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHXqBFJcPE1btvDFES-7a+i5PgwZjJ3CQHx6S7wvQKuk2zPtGQ@mail.gmail.com>
Date:	Wed, 8 Feb 2012 10:31:50 +0100
From:	Michał Mirosław <mirqus@...il.com>
To:	Ben Greear <greearb@...delatech.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC 2/2] e1000e: Support RXALL feature flag.

W dniu 8 lutego 2012 01:19 użytkownik Ben Greear
<greearb@...delatech.com> napisał:
> On 02/07/2012 04:06 PM, Michał Mirosław wrote:
>> 2012/2/8<greearb@...delatech.com>:
>>> From: Ben Greear<greearb@...delatech.com>
>>>
>>> This allows the NIC to receive all frames available, including
>>> those with bad FCS, un-matched vlans, ethernet control frames,
>>> and more.
>>>
>>> Tested by sending frames with bad FCS.
>> This should probably mark the bad packets somehow, so they are not
>> passed up the stack and mixed with correct traffic.
> Anything that does higher-level checksumming should figure out the
> problem, if it's real (ie, if not *just* a corrupted FCS).  Anything
> that doesn't is open to abuse by something sending corrupted packets
> with correct checksums anyway.
>
> But, if you think it's really needed, I could add a flag to the skb and
> then free the skb after the ptype_all logic in netif_receive_skb
> has been called?

Hmm. Passing of possibly corrupted packets might be useful for
UDPlite, but for other IP protocols CRC32 is stronger than IP checksum
and ignoring the former would allow more silently broken packets to
pass through.

I'm not convinced either way, though - just opening a discussion, as
this might change the assumptions on IP over Ethernet people make in
their apps.

When IP checksum (incl. TCP/UDP) is ok and FCS is bad, then we have a
few possibilities:
 1. only some bits in FCS are bad,
 2. some 2 matching bits of IP/TCP/UDP checksum and payload are flipped,
 3. a lot of bits (at least 16) in packet's data or header are bad,
 4. some other corruption.

Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html