Re: [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers

From: Matt Mackall <mpm@xxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: fxp0 generating lots of interrupts
    ... >>the moment and there is almost no network activity at the moment. ... When using polling you won't see any interrupts anymore. ... generates a interrupt for every packet sent as well. ... Normally you get one interrupt per packet. ...
    (freebsd-current)
  • Re: IF_HANDOFF vs. IFQ_HANDOFF
    ... There should be a nearly-complete interrupt ... > an interrupt after every packet. ... interrupt mark on fragments in the middle of a packet. ... before sending frames in sk_start if number of available Tx descriptors ...
    (freebsd-net)
  • Re: RFC: issues concerning the next NAPI interface
    ... If NAPI disables interrupts and keeps them disabled while there are more packets arriving or more transmits being completed, why do hardware interrupt mitigation / coalescing features of the network silicon help? ... dominates the packet processing costs. ... A driver's poll() would set an internal flag and record the current jiffies value when finding workdone=0 rather than doing an immediate napi_complete. ...
    (Linux-Kernel)
  • Re: NIPS solutions
    ... > machines are used? ... each packet that is arriving at the ... > network interface triggers an hardware interrupt that is instantly ... the soft interrupt packet queue. ...
    (Focus-IDS)
  • Re: very busy syslog server
    ... For the syslog daemon, I have chosen rsyslogd, and the backend is mysql. ... broadcast/multicast datagrams dropped due to no socket ->>> 123677 dropped due to full socket buffers 0 not for hashed pcb ... than one packet per interrupt. ...
    (freebsd-performance)
Loading