linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <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
Date: Sat, 06 May 2006 17:08:10 -0700 (PDT)	[thread overview]
Message-ID: <20060506.170810.74552888.davem@davemloft.net> (raw)
In-Reply-To: <20060506164808.GY15445@waste.org>

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.

  parent reply	other threads:[~2006-05-07  0:08 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05 16:42 [PATCH 1/14] random: Remove SA_SAMPLE_RANDOM from floppy driver Matt Mackall
2006-05-05 16:42 ` [PATCH 6/14] random: Remove redundant SA_SAMPLE_RANDOM from touchscreen drivers Matt Mackall
2006-05-05 16:42 ` [PATCH 4/14] random: Change cpqarray to use add_disk_randomness Matt Mackall
2006-05-05 16:42 ` [PATCH 2/14] random: Remove redundant SA_SAMPLE_RANDOM from NinjaSCSI Matt Mackall
2006-05-05 16:42 ` [PATCH 3/14] random: Make CCISS use add_disk_randomness Matt Mackall
2006-05-05 16:42 ` [PATCH 5/14] random: Remove bogus SA_SAMPLE_RANDOM from at91 compact flash driver Matt Mackall
2006-05-05 16:42 ` [PATCH 8/14] random: Remove SA_SAMPLE_RANDOM from USB gadget drivers Matt Mackall
2006-05-06 11:07   ` Denis Vlasenko
2006-05-06 18:16     ` David Brownell
2006-05-06 18:31       ` Matt Mackall
2006-05-05 16:42 ` [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers Matt Mackall
2006-05-05 17:13   ` Kyle Moffett
2006-05-05 17:24     ` Matt Mackall
2006-05-05 19:11       ` Theodore Tso
2006-05-05 20:30         ` Stephen Hemminger
2006-05-05 20:34         ` Matt Mackall
2006-05-06 11:55           ` Theodore Tso
2006-05-06 16:48             ` Matt Mackall
2006-05-06 17:29               ` Bernd Eckenfels
2006-05-06 18:05               ` Theodore Tso
2006-05-06 20:33                 ` Matt Mackall
2006-05-07  0:17                   ` David S. Miller
2006-05-07  1:22                   ` Theodore Tso
2006-05-07  5:07                     ` Matt Mackall
2006-05-08 21:58                     ` Sami Farin
2006-05-24 22:47                 ` Marcin Dalecki
2006-05-25  0:08                   ` Theodore Tso
2006-05-31 19:29                     ` Bill Davidsen
2006-05-07  0:08               ` David S. Miller [this message]
2006-05-07  4:59                 ` Matt Mackall
2006-05-07  5:46                   ` David S. Miller
2006-05-07 16:31                     ` Matt Mackall
2006-05-07 13:13                   ` Thiago Galesi
2006-05-07 16:00                     ` Matt Mackall
2006-05-07 17:00                       ` Thiago Galesi
2006-05-08  0:13                       ` Theodore Tso
2006-05-08  2:55                         ` Matt Mackall
2006-05-08  6:26                   ` Pavel Machek
2006-05-08  7:07                     ` David S. Miller
2006-05-08 14:05                       ` Matt Mackall
2006-05-08 17:21                         ` Pavel Machek
2006-05-08 17:27                           ` Matt Mackall
2006-05-09 11:23                             ` Pavel Machek
2006-05-11 10:05                           ` Ph. Marek
2006-05-24 22:35         ` Marcin Dalecki
2006-05-05 21:10   ` David S. Miller
2006-05-05 23:03     ` Matt Mackall
2006-05-05 23:19       ` David S. Miller
2006-05-06 14:08     ` Folkert van Heusden
2006-05-06 15:19       ` Lee Revell
2006-05-07 10:35         ` Folkert van Heusden
2006-05-07 16:33           ` Matt Mackall
2006-05-05 16:42 ` [PATCH 9/14] random: Remove SA_SAMPLE_RANDOM from i2c drivers Matt Mackall
2006-05-05 16:42 ` [PATCH 10/14] random: Remove bogus SA_SAMPLE_RANDOM from mpc52xx serial driver Matt Mackall
2006-05-05 16:42 ` [PATCH 11/14] random: Remove UML usage of SA_SAMPLE_RANDOM Matt Mackall
2006-05-05 16:42 ` [PATCH 13/14] random: Remove SA_SAMPLE_RANDOM from IRQ fastpath Matt Mackall
2006-05-05 16:42 ` [PATCH 12/14] random: Remove not very useful SA_SAMPLE_RANDOM from lubbock Matt Mackall
2006-05-05 16:42 ` [PATCH 14/14] random: Remove add_interrupt_randomness Matt Mackall
2006-05-08  7:38 [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers linux
2006-05-12  6:09 ` linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060506.170810.74552888.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=mrmacman_g4@mac.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).