This patch set is my first pass at adding support for some more
RNG drivers to the kernel. My basic goal was to keep the same
user space interface as exists, but not have to reproduce all
the same 100 lines of user space interface code across every new
driver (as we currently do with watchdogs...)
The new code separate the HW specifc driver from the user
interface code and just adds a few function pointers so that
the two can talk to each other. I opted out of using a sysfs
class and all that complication b/c there will be one and only
one RNG device at a time from all the HW I can see.
I've added drivers for Intels' IXP4xx and for the TI OMAP,
though the later has not been tested (it builds) as I don't
have the hardware. Same goes for x86...builds but no HW for
me to test locally. Freescale MPC8xxx is next but that requires
a bit more work.
As for the discussion on moving the implementation completely
out of the kernel, it is not completely doable. While we
can do it for simple HW such as the IXP and X86, there are
some cases that basically require us to have kernel code:
- On systems like OMAP, we want to be able to suspend/resume
the RNG device and the device clocks and that needs to be done
from kernel space as part of the PM path.
- On the MPC8xxx, the RNG is just part of a large crypto unit
that also does SHA-1 and MD5 along with some other operations
for which I'd like to see (and will probably write) a driver. The
RNG commands are queued in a chain along with the other units and
trying to get user space to share that queue will just be a mess.
So..we might as well keep them all in the kernel instead of having
to know about some HW and not know about others.
Some of the things on my TODO list:
- Allow a fastpath where we don't even have the user space portion
and the HW drivers just feed the entropy pool directly. While
this bypasses the FIPS tests and such, there are some applications
where this is OK or where we really don't want the extra proccess
context switching. This is specially true on ARM. I'll have to add
IRQ driven support to the drivers to that, but that's trivial. There
is also some HW (MPC8xxx for example) that does periodic self-tests
in HW and lists itself as "FIPs-compliant" and will trigger an error if
data should no longer be trusted and in that case doing a software
test might also be undesirable. But...we should let the user decide
at build time (or runtime?).
- Since I'm adding IRQ support, go ahead and add poll(2) support so
that when we do have a user space daemon, it's not constantly
poking at us.
~Deepak
(This is my first time using the magical quilt mail scripts so apologies
in advance if anything breaks)
--
Deepak Saxena - [email protected] - http://www.plexity.net
Even a stopped clock gives the right time twice a day.
[email protected] wrote:
> - Allow a fastpath where we don't even have the user space portion
> and the HW drivers just feed the entropy pool directly. While
> this bypasses the FIPS tests and such, there are some applications
> where this is OK or where we really don't want the extra proccess
> context switching. This is specially true on ARM. I'll have to add
> IRQ driven support to the drivers to that, but that's trivial. There
> is also some HW (MPC8xxx for example) that does periodic self-tests
> in HW and lists itself as "FIPs-compliant" and will trigger an error if
> data should no longer be trusted and in that case doing a software
> test might also be undesirable. But...we should let the user decide
> at build time (or runtime?).
Not interesting in pursuing this path. This has been discussed
endlessly, check the archives.
We want the FIPS tests. Hardware (especially cheap hardware) is often
known to go haywire. Trusting hardware to do the FIPS tests is pretty
silly, since you're trusting the piece that might go haywire to tell you
its OK. RNGs have a history of suddenly providing non-random data, for
a variety of reasons (usually poor board wiring).
We also want the userspace daemon because that gives the sysadmin far
more control over how much entropy is added to the system. 99.9% of the
cases in the real world, we don't want the RNG pumping entropy into the
pool at full speed. That will likely pump in more data than a system
needs, chewing CPU. The admin can't even kill the daemon to reclaim his
CPU, if its all in-kernel.
It's not brain surgery, to concoct a method by which an interrupt-driven
device is used from userspace.
Jeff
On Oct 19 2005, at 11:01, Jeff Garzik was caught saying:
> Not interesting in pursuing this path. This has been discussed
> endlessly, check the archives.
>
> We want the FIPS tests. Hardware (especially cheap hardware) is often
> known to go haywire. Trusting hardware to do the FIPS tests is pretty
> silly, since you're trusting the piece that might go haywire to tell you
> its OK. RNGs have a history of suddenly providing non-random data, for
> a variety of reasons (usually poor board wiring).
>
> We also want the userspace daemon because that gives the sysadmin far
> more control over how much entropy is added to the system. 99.9% of the
> cases in the real world, we don't want the RNG pumping entropy into the
> pool at full speed. That will likely pump in more data than a system
> needs, chewing CPU. The admin can't even kill the daemon to reclaim his
> CPU, if its all in-kernel.
OK, understood. But other than the fastpath idea, are you OK with
the direction I took with the code?
~Deepak
--
Deepak Saxena - [email protected] - http://www.plexity.net
When law and duty are one, united by religion, you never become fully
conscious, fully aware of yourself. You are always a little less than
an individual. - Frank Herbert