netdev - Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <1211727328.5913.58.camel@andromache>
Date:	Mon, 26 May 2008 00:25:28 +0930
From:	Glen Turner <gdt@....id.au>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
Cc:	Jeff Garzik <jeff@...zik.org>, Rick Jones <rick.jones2@...com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Chris Peterson <cpeterso@...terso.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses of
	IRQF_SAMPLE_RANDOM

On Thu, 2008-05-15 at 11:47 -0700, Kok, Auke wrote:

> How about the non-NAPI and non-throttled case? I would argue that without any irq
> mitigation we can still use SA_RANDOM.

You don't know what packet-shaping us upstream ISPs are using.
If we're shaping then we're moving packets in time so that they
arrive upon the ticking of a output queue playout clock.  That
is, packet arrival becomes periodic not random.

Linux has a class-based queuing implementation and this would
have a similar effect on outbound packets.

Nearby microwave ovens will add periodicy to the arrival
of WLAN data. It wouldn't shock me if multicast traffic
over WLANs (even if not addressed to the host in question)
had the same effect on unicast data.

TCP's behaviour hardly leads to random packet arrival times.
Take the probability of TCP data inter-packet arrival times.
It is at least a binomial distribution (and thus not a random
distribution, and thus not suitable for /dev/random):
 - Case A: first packet in a TCP window transmission
 - Case B: subsequent packets in a TCP window transmission
           (probability rises to near 1 that another packet
            will shortly follow this one).
TCP packet transmission times are also binomial and strongly
self-correlated.

Worst of all, packet arrivals and departures are remotely observable,
both to a classic remote attacker with access to the comms channel and
to another user on a multiuser host.  So even if packet arrivals and
departures were totally random they would not be of use, since the
"random" numbers which contribute to the key would be known to the
attacker.

Regards, Glen

--
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