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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]