[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: a small C program to test xdm's /dev/mem reading on your architecture

On Mon, 26 Aug 2002 17:04:26 +1000
"matthew green" <mrg@eterna.com.au> wrote:

> actually, i hadn't, but there wasn't very much there besides the
> fact that people found it was xdm reading /dev/mem and a small
> patch for debian to enable /dev/random (i'd suggest /dev/urandom).
> my point is that on modern systems we simply should not read
> from /dev/mem for these purposes _ever_.  so far it has shown to
> be unsafe on at least:

I believe the /dev/mem gets read only in systems where no /dev/(u)random
exists. There really are such systems. Agreed, reading raw memory is an
unstable and dangerous way of getting enthropy, but xdm needs some way
of getting it. If I understood the thread correctly, the preferred way
indeed is the /dev/(u)random way. Still, the unlucky ones with no
/dev/(u)random should not be forgotten.

I think the "safe" way of getting random data without a decent random
source would be to write one. This, however, would be more that just
a small patch. A simple random number generator doesn't do, since it's
all too predictable. One approach could be using two separate threads
to read the same rnd-generator, so the system's scheduler would make
the resulting data sequence unpredictable. However, I believe this is
not very portable approach either: it is only possible, if threads are.
And even if the system supports mt-programming, how can we be sure
that the thread switching happens unpredictably? So, a better solution
is needed. Probably one even exists.

Just my 2 cents,


Reply to: