This patch adds support to the kernel for some more HW RNG devices
and cleans up the code a bit. 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 separates the HW specific 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 on a given system.
I've added drivers for Intels' IXP4xx and for the TI OMAP and
these have both been tested.
There was some discussion on lkml on the subject of killing
the in-kernel driver and moving the whole implementation to
user space but that cannot be done as some SOCs (MPC85xx for
example) have the RNG unit as part of a larger device that
needs kernel space code to manage command descriptor rings
and other such things. We also want to be able to suspend/resume
the RNG devices (see OMAP driver) and that needs to be done as part
of the kernel PM path.
Please apply,
~Deepak
--
Deepak Saxena - [email protected] - http://www.plexity.net
Even a stopped clock gives the right time twice a day.
Deepak Saxena wrote:
> This patch adds support to the kernel for some more HW RNG devices
> and cleans up the code a bit. 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 separates the HW specific 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 on a given system.
>
> I've added drivers for Intels' IXP4xx and for the TI OMAP and
> these have both been tested.
I would prefer to let this live in -mm at least for a little while.
Confirmation from AMD, Intel and VIA owners would be really nice, too.
AMD and Intel might be a little bit hard to find. I think Peter Anvin
had an Intel ICH w/ RNG at one time...
> There was some discussion on lkml on the subject of killing
> the in-kernel driver and moving the whole implementation to
> user space but that cannot be done as some SOCs (MPC85xx for
> example) have the RNG unit as part of a larger device that
> needs kernel space code to manage command descriptor rings
> and other such things. We also want to be able to suspend/resume
> the RNG devices (see OMAP driver) and that needs to be done as part
> of the kernel PM path.
None of this precludes having this stuff in userspace.
That said, I don't object to your code being an intermediate step.
Jeff (hw_random author)
On Sat, 29 Oct 2005, Jeff Garzik wrote:
>
> I would prefer to let this live in -mm at least for a little while.
> Confirmation from AMD, Intel and VIA owners would be really nice, too. AMD and
> Intel might be a little bit hard to find. I think Peter Anvin had an Intel
> ICH w/ RNG at one time...
I'm just wondering why via/amd/intel end up being one driver. It would
seem to be more sensible to have separate drivers for them, since they
have no real overlap..
Linus
Linus Torvalds wrote:
>
> On Sat, 29 Oct 2005, Jeff Garzik wrote:
>
>>I would prefer to let this live in -mm at least for a little while.
>>Confirmation from AMD, Intel and VIA owners would be really nice, too. AMD and
>>Intel might be a little bit hard to find. I think Peter Anvin had an Intel
>>ICH w/ RNG at one time...
>
>
> I'm just wondering why via/amd/intel end up being one driver. It would
> seem to be more sensible to have separate drivers for them, since they
> have no real overlap..
No real reason other than historical. Split up would be my preference.
Jeff
On Saturday 29 October 2005 18:09, Jeff Garzik wrote:
>Deepak Saxena wrote:
>> This patch adds support to the kernel for some more HW RNG devices
>> and cleans up the code a bit. 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 separates the HW specific 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 on a given system.
>>
>> I've added drivers for Intels' IXP4xx and for the TI OMAP and
>> these have both been tested.
>
>I would prefer to let this live in -mm at least for a little while.
>Confirmation from AMD, Intel and VIA owners would be really nice, too.
>AMD and Intel might be a little bit hard to find. I think Peter Anvin
>had an Intel ICH w/ RNG at one time...
Does anyone know if there is a hardware RNG in my Athlons? XP-2800
here, XP-1400 in the shop box, & a K6-III in the firewall.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Free OpenDocument reader/writer/converter download:
http://www.openoffice.org
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Sunday 30 October 2005 01:23, Gene Heskett wrote:
[snip]
>
> Does anyone know if there is a hardware RNG in my Athlons? XP-2800
> here, XP-1400 in the shop box, & a K6-III in the firewall.
It's a mainboard feature, not a CPU feature.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Alistair John Strachan wrote:
> On Sunday 30 October 2005 01:23, Gene Heskett wrote:
> [snip]
>
>>Does anyone know if there is a hardware RNG in my Athlons? XP-2800
>>here, XP-1400 in the shop box, & a K6-III in the firewall.
>
>
> It's a mainboard feature, not a CPU feature.
And is there a docmentation on how to find which RNG device you have?
Or is there lsrng (like lspci) :-)
Most of the device names I have never heard of, but working with 5+ MB vendors and all the different
models of MB I really have no idea where do I have this and that...
So, any method of autodetecting a RNG device?
And a question, I always wanted to ask: is there a cheap hardware random device usable in linux that
is PCI/USB/serial whatever pluggable? For MBs without RNG in the chipset.
Kalin.
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
> > [snip]
> >>Does anyone know if there is a hardware RNG in my Athlons? XP-2800
> >>here, XP-1400 in the shop box, & a K6-III in the firewall.
> > It's a mainboard feature, not a CPU feature.
> And is there a docmentation on how to find which RNG device you have?
> Or is there lsrng (like lspci) :-)
> Most of the device names I have never heard of, but working with 5+ MB vendors and all the different
> models of MB I really have no idea where do I have this and that...
> So, any method of autodetecting a RNG device?
> And a question, I always wanted to ask: is there a cheap hardware random device usable in linux that
> is PCI/USB/serial whatever pluggable? For MBs without RNG in the chipset.
Consider:
audio-entropyd: use a cheap soundcard for generating entropy (http://www.vanheusden.com/aed/)
video-entropyd: use that obsolete webcam for same thing (http://www.vanheusden.com/ved/)
Folkert van Heusden
--
Try MultiTail! Multiple windows with logfiles, filtered with regular
expressions, colored output, etc. etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Get your PGP/GPG key signed at http://www.biglumber.com!
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com
On Oct 29 2005, at 18:33, Jeff Garzik was caught saying:
> Linus Torvalds wrote:
> >On Sat, 29 Oct 2005, Jeff Garzik wrote:
> >>I would prefer to let this live in -mm at least for a little while.
> >>Confirmation from AMD, Intel and VIA owners would be really nice, too.
> >>AMD and
> >>Intel might be a little bit hard to find. I think Peter Anvin had an
> >>Intel
> >>ICH w/ RNG at one time...
> >
> >I'm just wondering why via/amd/intel end up being one driver. It would
> >seem to be more sensible to have separate drivers for them, since they
> >have no real overlap..
>
> No real reason other than historical. Split up would be my preference.
OK, will split and send to Andrew for -mm tree.
~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
On Oct 29 2005, at 18:09, Jeff Garzik was caught saying:
> Deepak Saxena wrote:
> >There was some discussion on lkml on the subject of killing
> >the in-kernel driver and moving the whole implementation to
> >user space but that cannot be done as some SOCs (MPC85xx for
> >example) have the RNG unit as part of a larger device that
> >needs kernel space code to manage command descriptor rings
> >and other such things. We also want to be able to suspend/resume
> >the RNG devices (see OMAP driver) and that needs to be done as part
> >of the kernel PM path.
>
> None of this precludes having this stuff in userspace.
I think moving it to user space will add more complexity for
the case where the HW unit is shared with an in in-kernel driver.
Instead of just having a simple char interface to read the data,
it would require providing a facility for the user space code to
add commands into the command linked list which seems like more
kernel code to me.
That being said, we can revisit that when actually writing the
MPC85xx code.
Tnx,
~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
On Sun, 30 Oct 2005, Deepak Saxena wrote:
>
> I think moving it to user space will add more complexity for
> the case where the HW unit is shared with an in in-kernel driver.
Moving it to user space is just generally stupid.
Often, the random stuff comes from chipsets, not the CPU itself. Not
user-accessible at all, and even if it were, it would be a bad idea to
have user space do things the kernel does normally ("what northbridge do I
have").
There may be use for a user-level library that handles the native CPU
instructions for high performance, but that in no way negates the reason
why /dev/random and friends exist in the first place.
Linus
Linus Torvalds wrote:
>
> On Sun, 30 Oct 2005, Deepak Saxena wrote:
>
>>I think moving it to user space will add more complexity for
>>the case where the HW unit is shared with an in in-kernel driver.
>
>
> Moving it to user space is just generally stupid.
>
> Often, the random stuff comes from chipsets, not the CPU itself. Not
> user-accessible at all, and even if it were, it would be a bad idea to
> have user space do things the kernel does normally ("what northbridge do I
> have").
>
> There may be use for a user-level library that handles the native CPU
> instructions for high performance, but that in no way negates the reason
> why /dev/random and friends exist in the first place.
>
We're not talking about /dev/random, we're talking about /dev/hw_random
which is read by rndg and then fed by userspace back into /dev/[u]random.
Clearly, there are cases (e.g. VIA) where rndg or a library called from
rngd could just as easily have done the extraction in userspace, and for
that, it makes no sense to force it to do it in the kernel. For some,
it could be done either way, and for others a kernel driver is clearly
needed. Integrating them all into /dev/hw_random was probably a
mistake, though.
-hpa