Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

2008/5/15 Adrian Bunk <bunk@xxxxxxxxxx>:
On Thu, May 15, 2008 at 09:07:52AM -0700, Brandeburg, Jesse wrote:
Alan Cox wrote:
Chris Peterson <cpeterso@xxxxxxxxxxxx> wrote:
I know Jeff Garzik says he's not interested in an anti-entropy
pogrom for existing net drivers, but here is the patch if anyone
else is interested..? :)

Only 12 net drivers are affected, the last of the
theoretically-exploitable network entropy.

Looks fine to me. If Jeff doesn't want to touch them then send them
direct to Andrew/Linus.

A more interesting alternative might be to mark things like network
drivers with a new flag say IRQF_SAMPLE_DUBIOUS so that users can be
given a switch to enable/disable their use depending upon the
environment.

we've been hearing rumblings of big customers wanting (maybe requiring)
wired network drivers from Intel to advertise this flag. Jeff have you
heard of such?

I think the argument is that a headless system (no keyboard/mouse, no
soundcard, probably no video) with a libata based driver and a network
driver without IRQF_SAMPLE_RANDOM has *no* sources of entropy. In this
case the argument is very strong for at least *some* source of entropy
from interrupts so that randomness can get some external input. Just
try rebuilding a kernel RPM over an ssh session and you'll see what I
mean.

In short, I agree with Alan's IRQF_SAMPLE_DUBIOUS, and know of Linux
customers who also want the same.

We have two random number interfaces:
- /dev/random
- /dev/urandom

If a customer wants to get data from /dev/random although there's not
enough entropy that's not a problem we can solve (we can only try to
gather more real entropy if possible).

If he can live with dubious data he can simply use /dev/urandom .

If a customer wants to use /dev/random and demands to get dubious data
there if nothing better is available fulfilling his wish only moves
the security bug from his crappy application to the Linux kernel.

But what we could perhaps do with some kind of IRQF_SAMPLE_DUBIOUS would
be to improve the quality of the data in /dev/urandom if there's not
enough entropy available?

I have seen embedded systems with zero entropy, and dubious entropy
might there be better than no entropy at all.
Or am I wrong on the latter?


Note: I'm far from being any kind of expert on this topic, but I just
had a crazy idea.

What if we use the time between syscalls being made as a source of
(very little) entropy?

My point is that the rate (and timing between) syscalls is depending
on very many factors; the kernel version (and configuration), the
software installed, the software currently executing, the state of the
software currently executing, the number of apps executing, the amount
of network traffic, the accuracy of the hardware clock, the speed of
(various) IO sources (network, disk, USB, etc), the speed (and type)
of the CPU, the speed of memory. And various other things.
I'd guess that predicting the syscall rate and interval between
syscalls would be too hard to accurately predict to predict the actual
entropy generated by that sampling in any real world scenario.
Wouldn't that make it a reasonable entropy source for machines that
have no other sources (and a fair contributor of entropy even for
machines that do have other sources) ??


--
Jesper Juhl <jesper.juhl@xxxxxxxxx>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
--
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