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:	Fri, 4 Aug 2006 23:08:24 +0200
From:	Michael Buesch <mb@...sch.de>
To:	moreau francis <francis_moreau2000@...oo.fr>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [HW_RNG] How to use generic rng in kernel space

On Friday 04 August 2006 15:00, moreau francis wrote:
> Michael Buesch wrote:
> > The dataflow is as follows:
> 
> > HW-RNG -> userspace RNGD (through /dev/hwrng) -> the daemon
> > checks it for sanity and puts it back into the kernel through
> > /dev/random -> Your driver gets the data from the /dev/random
> > entropy pools.
> 
> Is that also true for embedded systems ? I mean we may not found
> any rngd on these systems.

Yes, I think so.

> One other question now: suppose that others drivers need to use
> random data during their inits. At this time userspace appli still not
> have been started. How does it work ?
> 
> > This is very neccesary, because your HW-RNG may fail and
> > so you may unintentionally use non-random data, if you use
> > the random data from the RNG directly.
> > The data _must_ go through userspace rngd, which does FIPS
> > sanity checks on the data.
> 
> Well I'm working on a secure SOC which have a randown hardware
> which is supposed to return true random data. I understand that 
> some self tests on the random data are needed but doing them in 
> userspace is suprising.

The whole purpose of the hrwng subsystem is to give userspace
an interface to the RNG device. Not more and not less.

So, if you have a special hwrng on your embedded board and you
have some special driver in that board, why not interface
directly from the driver to the hwrng-driver?
This is all pretty special case.
In the hwrng-driver you could still additionally do a
hrwng_register() to export the functionality to
userspace, though.


I am not a friend of a direct in-kernel hwrng access interface,
because it may return crap data by definition. Many (all current)
RNG devices may fail and return non-random data. If that's happily
used by some in-kernel user by the interface, we are screwed.

Why can't you build your random-data consumer as module and load
it later, when random data is available (and was carefully checked
by various tests in rngd)?

-- 
Greetings Michael.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ