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
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 ...
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
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
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
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
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 ...
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 the data
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
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
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:
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
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
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
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
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"
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
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
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
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
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
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
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
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
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
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.
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
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 without
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. The worst
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 of
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 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 kernel API
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 because
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 flakey
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 let
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
it
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 failures
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
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 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 kernel
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 per second
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 space please let me
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 by doing this in
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 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 that you're getting
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 stop
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 random generator, it
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
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
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
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 assistant
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,
[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
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,
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, extreme
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
you
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 patch there
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.
I
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
-latest-
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
[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:
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,
> > 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
>
> 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
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
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
check
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
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 continuously
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
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
> >
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
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, 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, 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 bit
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
rngd should
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's like
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
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
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
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
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
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
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
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
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
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
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.
---
1 - 100 of 176 matches
Mail list logo
