Jivin Jeff Garzik lays it down ...
...
> >If kernelspace can assist and driver _knows_ in advance that data
> >produced is cryptographically strong, why not allow it directly
> >access pools?
>
> A kernel driver cannot know in advance that the data from a hardware RNG
> is truly random, unless t
Jeff wrote:
> Or all 1's (more likely), or all 0x55's, or...
Stray thought - to follow up stray thought:
Hmmm ... run some numbers through a good compression program,
and complain if they compress much.
--
I won't rest till it's the best ...
Programme
Bill Davidsen wrote:
If the hardware RNG always fails to all zeros it should be possible to
detect that it failed with the need for userspace daemons. While true
random bits might legitimately have 10k zeros in a row, I will bet that
if it happens the device isn't working.
Or all 1's (more lik
Jeff Garzik wrote:
Bill Davidsen wrote:
Herbert Xu wrote:
You missed the point. This has nothing to do with the crypto API.
Jeff is saying that if this is disabled by default, then only a few
users will enable it and therefore use this API.
Since we can't afford to enable it by default as hardware
On March 29, 2005 05:50 am, Evgeniy Polyakov wrote:
> I think the most people use hardware accelerated devices to
> speed up theirs calculations - embedded world is the best example -
> applications that are written to use /dev/random
> will work just too slow, so hardware vendors
> place HW assis
Bill Davidsen wrote:
Herbert Xu wrote:
You missed the point. This has nothing to do with the crypto API.
Jeff is saying that if this is disabled by default, then only a few
users will enable it and therefore use this API.
Since we can't afford to enable it by default as hardware RNG may
fail which
On Mar 29, 2005, at 17:02, Bill Davidsen wrote:
Wait a minute, if it fails the system drops back to software,
Does it? It would seem that if it fails and begins returning
all zeroes, then the seed function would (depending on the
implementation) be called like this:
add_random_bytes("\0\0\0\0"
Herbert Xu wrote:
You missed the point. This has nothing to do with the crypto API.
Jeff is saying that if this is disabled by default, then only a few
users will enable it and therefore use this API.
Since we can't afford to enable it by default as hardware RNG may
fail which can lead to catastro
On Tue, Mar 29, 2005 at 02:16:12AM -0500, Jeff Garzik wrote:
> [EMAIL PROTECTED] wrote:
> >>>pool. The consensus was that the FIPS testing should be moved to
> >>>userspace.
> >>
> >>Consensus from whom? And who says the FIPS testing is useful anyways?
> >>I think you just need to trust the rando
On Tue, Mar 29, 2005 at 02:17:24AM -0500, Jeff Garzik wrote:
> Andi Kleen wrote:
> >BTW what do you do when the FIPS test fails? I dont see a good fallback
> >path for this case.
>
> If the FIPS test fails, do the obvious: don't feed that data to the
> kernel (and credit entropy), and possibly s
On Tue, 2005-03-29 at 17:11 +0400, Evgeniy Polyakov wrote:
> On Tue, 2005-03-29 at 22:43 +1000, Herbert Xu wrote:
> > On Tue, Mar 29, 2005 at 04:15:17PM +0400, Evgeniy Polyakov wrote:
> > > > > On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
> > > >
> > > > > > Well if you can demonstrate tha
On Tue, Mar 29, 2005 at 09:39:21PM +1000, Herbert Xu wrote:
> Well when you get 55mb/s from /dev/random please get back to me.
I will add you to my list for notification of Fortuna Patch to /dev/random
(/dev/urandom)
JLC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Tue, 2005-03-29 at 22:43 +1000, Herbert Xu wrote:
> On Tue, Mar 29, 2005 at 04:15:17PM +0400, Evgeniy Polyakov wrote:
> > > > On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
> > >
> > > > > Well if you can demonstrate that you're getting a higher rate of
> > > > > throughput from your RNG
On Tue, Mar 29, 2005 at 04:15:17PM +0400, Evgeniy Polyakov wrote:
> > > On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
> >
> > > > Well if you can demonstrate that you're getting a higher rate of
> > > > throughput from your RNG by doing this in kernel space vs. doing
> > > > it in user spac
Hi!
> > > > Well if you can demonstrate that you're getting a higher rate of
> > > > throughput from your RNG by doing this in kernel space vs. doing
> > > > it in user space please let me know.
> > >
> > > While raw bits reading from hw_random on the fastest
> > > VIA boards can exceed 55mbits
On Tue, 2005-03-29 at 21:39 +1000, Herbert Xu wrote:
> On Tue, Mar 29, 2005 at 03:42:05PM +0400, Evgeniy Polyakov wrote:
> > On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
>
> > > Well if you can demonstrate that you're getting a higher rate of
> > > throughput from your RNG by doing this in
On Tue, Mar 29, 2005 at 03:42:05PM +0400, Evgeniy Polyakov wrote:
> On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
> > Well if you can demonstrate that you're getting a higher rate of
> > throughput from your RNG by doing this in kernel space vs. doing
> > it in user space please let me know
On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
> On Tue, Mar 29, 2005 at 02:50:28PM +0400, Evgeniy Polyakov wrote:
> >
> > Without ability speed this up in kernel, we completely [ok, almost]
> > loose all RNG advantages.
>
> Well if you can demonstrate that you're getting a higher rate of
>
Hello!
> We trust hardware, anyway. Like your disk *could* accidentaly turn on
> setuid bit on /bin/bash, and we do not insist on userspace
> disk-validator.
But there is a very important difference: the most likely (both in theory
and practice) failure of a disk is clearly visible, while failure
On Tue, Mar 29, 2005 at 02:50:28PM +0400, Evgeniy Polyakov wrote:
>
> Without ability speed this up in kernel, we completely [ok, almost]
> loose all RNG advantages.
Well if you can demonstrate that you're getting a higher rate of
throughput from your RNG by doing this in kernel space vs. doing
i
On Tue, Mar 29, 2005 at 12:38:01PM +0200, Pavel Machek wrote:
>
> It seems to me that people wanting this level of assurance should do
> their own FIPS (or whatever) tests.
That's exactly what the current scheme of driver + rngd allows you
to do. For those that require high assurance, they can l
On Tue, 2005-03-29 at 20:30 +1000, Herbert Xu wrote:
> On Tue, Mar 29, 2005 at 12:21:04PM +0200, Pavel Machek wrote:
> >
> > What catastrophic consequences? Noone is likely to even *notice*, and
> > it does not help practical attack at all. Unless hardware RNGs are
> > *very* flakey (like, more fl
Hi!
> > What catastrophic consequences? Noone is likely to even *notice*, and
> > it does not help practical attack at all. Unless hardware RNGs are
> > *very* flakey (like, more flakey than harddrives), this is not a problem.
>
> The reason some people use hardware RNGs in the first place is bec
On Pá 25-03-05 17:13:11, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 09:16:01AM +0300, Evgeniy Polyakov wrote:
> > On Fri, 2005-03-25 at 00:58 -0500, Jeff Garzik wrote:
> >
> > > If its disabled by default, then you and 2-3 other people will use this
> > > feature. Not enough justification for a
On Tue, Mar 29, 2005 at 12:21:04PM +0200, Pavel Machek wrote:
>
> What catastrophic consequences? Noone is likely to even *notice*, and
> it does not help practical attack at all. Unless hardware RNGs are
> *very* flakey (like, more flakey than harddrives), this is not a problem.
The reason some
On Tue, Mar 29, 2005 at 12:18:16PM +0200, Pavel Machek wrote:
>
> I do not think paranoia about random generators is neccessary. If
> vendor provides you with random generator, it should be ok to just use
> it. [Did anyone see failing hw random generator, *at all*?] I can
> provide you with plenty
Hi!
On Pá 25-03-05 18:25:31, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 10:19:55AM +0300, Evgeniy Polyakov wrote:
> >
> > Noone will complain on Linux if NIC is broken and produces wrong
> > checksum
> > and HW checksum offloading is enabled using ethtools.
>
> This is completely different. Th
Hi!
> >>See the earlier discussion, when data validation was -removed- from the
> >>original Intel RNG driver, and moved to userspace.
> >
> >I'm not arguing against userspace validation, but if data produced
> >_is_ cryptographically strong, why revalidate it again?
>
> You cannot prove this w
Andi Kleen wrote:
We -used- to need data from RNG directly into the kernel randomness
Are you sure? I dont think there was ever code to do this in
mainline. There might have been something in -ac*, but not mainline.
Yes, I am positive. I wrote the code. Look at the old Intel RNG driver
code, b
[EMAIL PROTECTED] wrote:
pool. The consensus was that the FIPS testing should be moved to userspace.
Consensus from whom? And who says the FIPS testing is useful anyways?
I think you just need to trust the random generator, it is like
you need to trust any other piece of hardware in your machine.
Andi Kleen wrote:
BTW what do you do when the FIPS test fails? I dont see a good fallback
path for this case.
If the FIPS test fails, do the obvious: don't feed that data to the
kernel (and credit entropy), and possibly stop using the hardware RNG
under a human has intervened.
This is not rocke
On Wed, Mar 23, 2005 at 09:32:26PM -0800, Andrew Morton wrote:
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> > > It neither applies correctly nor compiles in current kernels. 2.6.11 is
> > > very old in kernel time.
> >
> > Hrm. This is getting pretty lame, if you can't take patches from the
On Mon, Mar 28, 2005 at 08:45:10AM -0500, Jean-Luc Cooke wrote:
>
> I have clients who run online Casinos. So spewing lots of reliable garbage
> is a good thing. That's why they chose Fortuna. Bad random data input is
> not a factor as long as there is enough trustwothy random data coming in.
> > For joe-user imho it's better to do a check from a cronjob once a day. But
> > for
> > high demand security, maybe make it pluggable? Like that a user can plug-in
> > some
> > module which does the testing? Then you can have several kinds of tests
> > depending on your needs.
> In my old 2.4
On Sun, Mar 27, 2005 at 08:55:03PM +0200, [EMAIL PROTECTED] wrote:
> > > pool. The consensus was that the FIPS testing should be moved to
> > > userspace.
> > Consensus from whom? And who says the FIPS testing is useful anyways?
> > I think you just need to trust the random generator, it is like
On Fri, Mar 25, 2005 at 06:43:49PM -0500, Jeff Garzik wrote:
>
> Consider what an RNG does: spews garbage.
>
> In practical applications, you -do not- want to dedicate the machine to
> spewing garbage. The vast majority of users would prefer to use their
> machines for real stuff. Thus, "extr
> > pool. The consensus was that the FIPS testing should be moved to userspace.
> Consensus from whom? And who says the FIPS testing is useful anyways?
> I think you just need to trust the random generator, it is like
> you need to trust any other piece of hardware in your machine. Or do you
> ch
> We -used- to need data from RNG directly into the kernel randomness
Are you sure? I dont think there was ever code to do this in
mainline. There might have been something in -ac*, but not mainline.
> pool. The consensus was that the FIPS testing should be moved to userspace.
Consensus from w
On Sat, 26 Mar 2005 11:36:02 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 26, 2005 at 03:47:33AM +0300, Evgeniy Polyakov wrote:
> >
> > It looks like we all misunderstand each other -
> > why do you think that if there will be kernel <-> kernel
> > RNG dataflow, then system will con
On Sat, Mar 26, 2005 at 03:47:33AM +0300, Evgeniy Polyakov wrote:
>
> It looks like we all misunderstand each other -
> why do you think that if there will be kernel <-> kernel
> RNG dataflow, then system will continuously spent all
> it's time to produce that data?
It doesn't matter whether it'
On Sat, 26 Mar 2005 10:47:45 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 25, 2005 at 06:43:49PM -0500, Jeff Garzik wrote:
> >
> > In any case, it is the wrong solution to simply "turn on the tap" and
> > let the RNG spew data. There needs to be a limiting factor... typically
> > rn
On Fri, Mar 25, 2005 at 06:43:49PM -0500, Jeff Garzik wrote:
>
> In any case, it is the wrong solution to simply "turn on the tap" and
> let the RNG spew data. There needs to be a limiting factor... typically
> rngd should figure out when /dev/random needs more entropy, or simply
> delay a little
On Fri, Mar 25, 2005 at 04:50:16PM -0600, Kim Phillips wrote:
> I did some tests and found that the udelay(200) call in hw_random.c is
> not good for extreme RNG consumption. Whether or not such extremes
> occur in real life, on the mpc8541, /dev/hwrandom is an order of
> magnitude slower than
On Fri, 2005-03-25 at 18:25 +1100, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 10:19:55AM +0300, Evgeniy Polyakov wrote:
> >
> > Noone will complain on Linux if NIC is broken and produces wrong
> > checksum
> > and HW checksum offloading is enabled using ethtools.
>
> This is completely different
On Fri, 2005-03-25 at 02:19 -0500, Jeff Garzik wrote:
> Evgeniy Polyakov wrote:
> > Noone will complain on Linux if NIC is broken and produces wrong
> > checksum
> > and HW checksum offloading is enabled using ethtools.
>
>
> Actually, that is a problem and people have definitely complained about
On Fri, Mar 25, 2005 at 10:19:55AM +0300, Evgeniy Polyakov wrote:
>
> Noone will complain on Linux if NIC is broken and produces wrong
> checksum
> and HW checksum offloading is enabled using ethtools.
This is completely different. The worst that can happen with checksum
offloading is that the p
Evgeniy Polyakov wrote:
Noone will complain on Linux if NIC is broken and produces wrong
checksum
and HW checksum offloading is enabled using ethtools.
Actually, that is a problem and people have definitely complained about
it in the past.
Jeff
-
To unsubscribe from this list: send the l
On Fri, 2005-03-25 at 17:56 +1100, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 09:59:18AM +0300, Evgeniy Polyakov wrote:
> >
> > It is not only about userspace/kernelspace system calls and data
> > copying,
> > but about whole revalidation process, which can and is quite expensive,
> > due to syst
On Fri, Mar 25, 2005 at 09:59:18AM +0300, Evgeniy Polyakov wrote:
>
> It is not only about userspace/kernelspace system calls and data
> copying,
> but about whole revalidation process, which can and is quite expensive,
> due to system calls, copying and validating itself,
What I meant is if you
On Fri, 2005-03-25 at 17:33 +1100, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 09:34:19AM +0300, Evgeniy Polyakov wrote:
> >
> > Such hardware is used mostly in embedded world where SW crypto
> > processing
> > is too expensive, so users of such HW likely want to trust to
> > theirs hardware and l
On Fri, Mar 25, 2005 at 09:34:19AM +0300, Evgeniy Polyakov wrote:
>
> Such hardware is used mostly in embedded world where SW crypto
> processing
> is too expensive, so users of such HW likely want to trust to
> theirs hardware and likely will turn in on.
That's fine. All you need for these embe
On Fri, 2005-03-25 at 17:13 +1100, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 09:16:01AM +0300, Evgeniy Polyakov wrote:
> > On Fri, 2005-03-25 at 00:58 -0500, Jeff Garzik wrote:
> >
> > > If its disabled by default, then you and 2-3 other people will use this
> > > feature. Not enough justificat
On Fri, 2005-03-25 at 00:58 -0500, Jeff Garzik wrote:
> Evgeniy Polyakov wrote:
> > So I still insist on creating ability to contribute entropy directly,
> > without userspace validation.
> > It will be turned off by default.
>
> If its disabled by default, then you and 2-3 other people will use t
On Fri, Mar 25, 2005 at 09:16:01AM +0300, Evgeniy Polyakov wrote:
> On Fri, 2005-03-25 at 00:58 -0500, Jeff Garzik wrote:
>
> > If its disabled by default, then you and 2-3 other people will use this
> > feature. Not enough justification for a kernel API at that point.
>
> It is only because the
Evgeniy Polyakov wrote:
So I still insist on creating ability to contribute entropy directly,
without userspace validation.
It will be turned off by default.
If its disabled by default, then you and 2-3 other people will use this
feature. Not enough justification for a kernel API at that point.
On Thu, Mar 24, 2005 at 11:45:53PM -0500, Jeff Garzik wrote:
>
> I agree with this sentiment; this is mainly a policy decision that
> kernel programmers should not make.
Exactly. Policy decisions like this as well as entropy checking
should be done in user-space.
Cheers,
--
Visit Openswan at
On Thu, 2005-03-24 at 14:59 +0300, Evgeniy Polyakov wrote:
> For example here is patch to enable acrypto support for hw_random.c
> It is very simple and support only upto 4 bytes request, of course it
> is not interested for anyone, but it is only 2-minutes example:
Full port.
--- ./drivers/char
On Thu, 2005-03-24 at 23:48 -0500, Jeff Garzik wrote:
> > And how HIFN driver can contribute entropy?
>
> Use the current chrdev->rngd method.
Why HIFN must be chardev?
> > You may say, that hardware can be broken and thus produces
> > wrong data, but if user want, it can turn it on or off.
>
Evgeniy Polyakov wrote:
On Thu, 2005-03-24 at 15:56 -0500, Jeff Garzik wrote:
See the earlier discussion, when data validation was -removed- from the
original Intel RNG driver, and moved to userspace.
I'm not arguing against userspace validation, but if data produced
_is_ cryptographically strong,
Evgeniy Polyakov wrote:
On Thu, 2005-03-24 at 15:39 -0500, Jeff Garzik wrote:
Evgeniy Polyakov wrote:
hw_random.c already does it using userspace daemons,
which is bad idea for very fast HW - like VIA xstore/xcrypt
instructions.
This is incorrect, because it implies that a user would want to use t
On Thu, 2005-03-24 at 15:56 -0500, Jeff Garzik wrote:
> > Idea to validate entropy data is good in general,
> > but it should be implemented in a way allowing external both in-kernel
> > and userspace
> > processes to contribute data.
> > So for in-kernel use we need such a mechanism, and userspa
On Thu, 2005-03-24 at 15:39 -0500, Jeff Garzik wrote:
> Evgeniy Polyakov wrote:
> > hw_random.c already does it using userspace daemons,
> > which is bad idea for very fast HW - like VIA xstore/xcrypt
> > instructions.
>
> This is incorrect, because it implies that a user would want to use the
>
On Thu, Mar 24, 2005 at 09:25:40AM -0500, Jean-Luc Cooke wrote:
>
> If your RNG were properly written, it shouldn't matter if the data you're
> pumping into /dev/random passed muster or not. If you're tracking entropy
> count, then that's a different story of course.
We're talking about hardware
Jean-Luc Cooke wrote:
On Thu, Mar 24, 2005 at 07:48:18AM -0500, Jeff Garzik wrote:
If you want to add entropy to the kernel entropy pool from hardware RNG,
you should use the userland daemon, which detects non-random (broken)
hardware and provides throttling, so that RNG data collection does not
David McCullough wrote:
Jivin Jeff Garzik lays it down ...
Evgeniy Polyakov wrote:
On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
so that true random number generator devi
Evgeniy Polyakov wrote:
On Thu, 2005-03-24 at 23:23 +1000, David McCullough wrote:
Jivin Jeff Garzik lays it down ...
Evgeniy Polyakov wrote:
On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *
Evgeniy Polyakov wrote:
hw_random can not and will not support HIFN, freescale, ixp and
great majority of the existing and future HW crypto devices.
I mean that userspace daemon(or any other one) which want to contribute
entropy
should use crypto framwork to obtain all it's data, but not different
David McCullough wrote:
Jivin Jeff Garzik lays it down ...
David McCullough wrote:
Jivin Jeff Garzik lays it down ...
On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote:
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords)
Evgeniy Polyakov wrote:
hw_random.c already does it using userspace daemons,
which is bad idea for very fast HW - like VIA xstore/xcrypt
instructions.
This is incorrect, because it implies that a user would want to use the
'xstore' feature at full speed -- which would dominate the CPU,
drastical
Andi Kleen wrote:
Andrew Morton <[EMAIL PROTECTED]> writes:
David McCullough <[EMAIL PROTECTED]> wrote:
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
It neither applies correctly nor compiles in current kernels. 2.6.11 is
very old in kernel ti
Andrew Morton <[EMAIL PROTECTED]> writes:
> David McCullough <[EMAIL PROTECTED]> wrote:
>>
>> Here is a small patch for 2.6.11 that adds a routine:
>>
>> add_true_randomness(__u32 *buf, int nwords);
>
> It neither applies correctly nor compiles in current kernels. 2.6.11 is
> very old in ke
On Thu, Mar 24, 2005 at 07:48:18AM -0500, Jeff Garzik wrote:
> If you want to add entropy to the kernel entropy pool from hardware RNG,
> you should use the userland daemon, which detects non-random (broken)
> hardware and provides throttling, so that RNG data collection does not
> consume 100%
On Thu, 2005-03-24 at 23:23 +1000, David McCullough wrote:
> Jivin Jeff Garzik lays it down ...
> > Evgeniy Polyakov wrote:
> > >On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
> > >
> > >>Hi all,
> > >>
> > >>Here is a small patch for 2.6.11 that adds a routine:
> > >>
> > >> add_true_
Jivin Jeff Garzik lays it down ...
> Evgeniy Polyakov wrote:
> >On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
> >
> >>Hi all,
> >>
> >>Here is a small patch for 2.6.11 that adds a routine:
> >>
> >>add_true_randomness(__u32 *buf, int nwords);
> >>
> >>so that true random number ge
On Thu, 2005-03-24 at 07:48 -0500, Jeff Garzik wrote:
> Evgeniy Polyakov wrote:
> > On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
> >
> >>Hi all,
> >>
> >>Here is a small patch for 2.6.11 that adds a routine:
> >>
> >>add_true_randomness(__u32 *buf, int nwords);
> >>
> >>so that t
Jivin Jeff Garzik lays it down ...
> David McCullough wrote:
> >Jivin Jeff Garzik lays it down ...
> >
> >>On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote:
> >>
> >>>Hi all,
> >>>
> >>>Here is a small patch for 2.6.11 that adds a routine:
> >>>
> >>> add_true_randomness(__u32 *b
Evgeniy Polyakov wrote:
On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
so that true random number generator device drivers can add a entropy
to the system. Drivers that us
Jivin Andrew Morton lays it down ...
> David McCullough <[EMAIL PROTECTED]> wrote:
> >
> > Here is a small patch for 2.6.11 that adds a routine:
> >
> > add_true_randomness(__u32 *buf, int nwords);
>
> It neither applies correctly nor compiles in current kernels. 2.6.11 is
> very old in ker
> Also, there are other entropy daemons floating about. I think there is
> one that obtains noise from an audio device.
That's correct: http://www.vanheusden.com/aed/ audio-entropyd
There's also one for doing the same with video4linux devices:
http://www.vanheusden.com/ved/
Folkert van Heusd
On Wed, 2005-03-23 at 20:38 -0800, Andrew Morton wrote:
> David McCullough <[EMAIL PROTECTED]> wrote:
> >
> > Here is a small patch for 2.6.11 that adds a routine:
> >
> > add_true_randomness(__u32 *buf, int nwords);
>
> It neither applies correctly nor compiles in current kernels. 2.6.11 is
On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
> Hi all,
>
> Here is a small patch for 2.6.11 that adds a routine:
>
> add_true_randomness(__u32 *buf, int nwords);
>
> so that true random number generator device drivers can add a entropy
> to the system. Drivers that use this
Jeff Garzik wrote:
Andrew Morton wrote:
David McCullough <[EMAIL PROTECTED]> wrote:
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
It neither applies correctly nor compiles in current kernels. 2.6.11 is
very old in kernel time.
Hrm. This i
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > It neither applies correctly nor compiles in current kernels. 2.6.11 is
> > very old in kernel time.
>
> Hrm. This is getting pretty lame, if you can't take patches from the
> -latest- stable release. It's pretty easy in BK:
>
> bk clone -
Andrew Morton wrote:
David McCullough <[EMAIL PROTECTED]> wrote:
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
It neither applies correctly nor compiles in current kernels. 2.6.11 is
very old in kernel time.
Hrm. This is getting pretty lame,
David McCullough wrote:
Jivin Jeff Garzik lays it down ...
On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote:
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
so that true random number generator device drivers can add
David McCullough wrote:
> Are you talking about /dev/hw_random ? If not then sorry I didn't see it :-(
>
> On a lot of the small systems I work on, /dev/random is completely
> unresponsive, and all the apps use /dev/random, not /dev/hw_random.
>
> Would you suggest making /dev/random point t
Jivin Jeff Garzik lays it down ...
> On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote:
> >
> > Hi all,
> >
> > Here is a small patch for 2.6.11 that adds a routine:
> >
> > add_true_randomness(__u32 *buf, int nwords);
> >
> > so that true random number generator device driv
David McCullough <[EMAIL PROTECTED]> wrote:
>
> Here is a small patch for 2.6.11 that adds a routine:
>
> add_true_randomness(__u32 *buf, int nwords);
It neither applies correctly nor compiles in current kernels. 2.6.11 is
very old in kernel time.
Are we likely to see any in-kernel users
On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote:
>
> Hi all,
>
> Here is a small patch for 2.6.11 that adds a routine:
>
> add_true_randomness(__u32 *buf, int nwords);
>
> so that true random number generator device drivers can add a entropy
> to the system. Drivers that
89 matches
Mail list logo
