linux-kernel - 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]

Date:	Thu, 15 May 2008 18:34:43 -0400
From:	Theodore Tso <tytso@....edu>
To:	Jesper Juhl <jesper.juhl@...il.com>
Cc:	Adrian Bunk <bunk@...nel.org>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Chris Peterson <cpeterso@...terso.com>, jeff@...zik.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	mpm@...enic.com
Subject: Re: [PATCH] drivers/net: remove network drivers' last few uses of
	IRQF_SAMPLE_RANDOM

On Fri, May 16, 2008 at 12:13:39AM +0200, Jesper Juhl wrote:
> 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.

It Depends.

For certain workloads, a lot of these issues might just boil out, or
not result in as much entropy as you think.  Think about a certificate
server which doesn't get much traffic, but when it is contacted, it is
expected to create new high security RSA keys and the public key
certificates to go with it.  If the attacker knows the machine type,
distribution OS loaded, etc., it might not be that hard to brute force
guess many of the factors you have listed above.

Basically the question has always been one of the overhead to collect
and boil down any input data (which after all, any user space process
can send arbitrary data into the entropy pool via "cat my_secret_data
> /dev/random") which will never hurt and might help.  The tricky bit
is estimating how much "entropy" should be ascribed to data which is
sent into the entropy pool, and this is where you have to be very
careful.

If you screw the entropy credit information then security of
/dev/random will be impacted.  /dev/urandom won't be impacted since it
doesn't care about the entropy estimation.  That's why only root is
allowed to use the ioctl which atomically sends in some "known to be
random" data and the entropy credit ascribed to that data.

	     	     	     	    	     	- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/