Date: Sat, 06 May 2006 17:08:10 -0700 (PDT)
Message-Id: <20060506.170810.74552888.davem@davemloft.net>
To: mpm@selenic.com
Cc: tytso@mit.edu, mrmacman_g4@mac.com, akpm@osdl.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network
 drivers
From: "David S. Miller" <davem@davemloft.net>
In-Reply-To: <20060506164808.GY15445@waste.org>
References: <20060505203436.GW15445@waste.org>
	<20060506115502.GB18880@thunk.org>
	<20060506164808.GY15445@waste.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2193
Lines: 51

From: Matt Mackall <mpm@selenic.com>
Date: Sat, 6 May 2006 11:48:08 -0500

> But network traffic should be _assumed_ to be observable to some
> degree.

But, and this is a huge but and the one that matters, nothing
between the network packet arriving and the interrupt being
delivered is observable outside of the machine.

The PHY of the network card has some tiny delays internal
to how it decodes the coding sequence on the wire and passes
it on to the MAC.

The MAC and the bus frontend have all sorts of timing and
delays wrt. making sure the necessary RX descriptor is fetched
and if a free packet buffer is available, DMA'ing the packet
into memory.

If the chip has hw interrupt mitigation enabled, these add other
delays and almost across the board these interrupt mitigation
timers are relatively imprecise.  If the first packet that starts
the time hits half-way between two clock ticks, the mitigation
fire will be a half clock off.

There are propagation delays for the interrupt to get to the cpu.
Every implementation is there, but the delays are there and highly
variable.  In many cases, it's the time to send a cacheline over
the main system bus to the target cpu (MSI, or sparc64 style PCI
controllers which turn traditional INTX signals into 64-byte
interrupt packets targeted at specific cpus).

Then there is the trap entry delay, and perhaps the cpu has interrupts
disabled while holding a spinlock or whatever.  Then there are all the
cache misses and instruction execution delays just to get into the
interrupt handler.

None of this is observable or predictable outside of the machine.
So the arguments about the SA_SAMPLE_RANDOM samples being risky in
the networking drivers is bogus.

Please put together a test case that proves that /dev/random can
be predicted just by being on the wire sniffing packets going into
the machine.  Then you will have my full support.

Everything shown so far is theoretical swiss cheese.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/