linux-kernel - Re: more random device badness in 2.6.18 :(

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:	Tue, 10 Oct 2006 23:50:59 +0200 (CEST)
From:	Paul Wouters <paul@...erance.com>
To:	Michael Buesch <mb@...sch.de>
cc:	linux-kernel@...r.kernel.org, Gabor Gombas <gombasg@...aki.hu>,
	fedora-xen@...hat.com
Subject: Re: more random device badness in 2.6.18 :(

On Tue, 10 Oct 2006, Michael Buesch wrote:

> > > Why should Openswan touch /dev/hw_random directly?
> >
> > Because using /dev/random whlie /dev/hw_random is available does not always
> > work (eg with padlock)
>
> Oh, wait wait. I don't really understand your sentence.
> Why can't you use /dev/random?

We have noticed in the past that on VIA's with the padlock, that
/dev/random stopped working when hw_random got loaded, while we could
get random from /dev/hw_random. So we assumed that was the design.

> /dev/hw_random should never be touched by anything else than rngd.

Seems like a good argument to keep this state hidden in the kernel then.

> rngd takes the data from /dev/hw_random, _verifys_ it and puts it into
> the normal /dev/random pools.
> The verification step is really important.

I understand the use of a FIPS compliant hardware random.

> So I would like to ask the other way around. Why should be put this code
> into the kernel, while it works in userspace as good (or, some people may
> argue it is even better in userspace, because it can more easily be exchanged,
> debugged and configured. Whatever)

If only a single process should ever touch a device, I wonder why it is
a device visible to all of userland. For one, it confuses stupid people
like me. Second, it seems that perhaps the reason the VIA hardware random
was "broken" was becaus I and others were unaware of the requirement of
rngd with hw_random. I am obviously not the only one, since Fedora Core
6 test 3 autoloads the hardware random module, but does not come with
the rng-tools package to fix /dev/random to actually use /dev/hw_random.

At least I do feel better now about all the device renames. rngd
uses "hwrandom" per default, which no longer exists. Then there is
hw_random, which seems to be something obsolete for hwrng judging by
the softlink. And I can stop worrying that /dev/hw_random cannot be
read without root permission on default modprobe. I'm happy to hear I
no longer need to worry about all those devices, and I can go back and
remove the code that deals with /dev/hw_random, after I verify that the
VIA systems still have a functional /dev/random if someone modprobe's
hw_random without running rngd. But if not running rngd breaks /dev/random,
then we'll be forced to keep an eye out for those /dev/hw* devices.

Paul
-
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/