linux-kernel - Re: [HW_RNG] How to use generic rng in kernel space

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]

Message-Id: <200608012249.20324.mb@bu3sch.de>
Date:	Tue, 1 Aug 2006 22:49:20 +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 Tuesday 01 August 2006 14:09, moreau francis wrote:
> Hi
> 
> I developped a HW RNG for a custom board and several
> other drivers are using it through a special entry I made.
> I was planning to move the code in order to use the generic
> the RNG layer but I encounter an issue.
>
> Currently it seems not possible for a driver to use HW RNG,
> because there's no entry point for that. Is that something
> deliberate ?
> 
Never ever do that. Never use the data from a hardware RNG
directly. There is intentionally no interface to do so.
If you need random data in some driver, use the functions
in random.h to get random data.

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.

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.

> Another question about the implementation. If O_NONBLOCK
> flag is passed when opening /dev/hw_random, how does the
> read method ensure that the caller won't sleep since it calls
> mutex_lock_interruptible() function unconditiannaly ? I must
> miss something but don't know what...

I second Alan's answer here. ;)

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