Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

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 justification for a kernel API at that point.
> > 
> > It is only because there are only couple of HW crypto devices
> > in the tree, with one crypto framework inclusion there will be
> > at least redouble.
> 
> 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 catastrophic consequences, there is no point
> for this API at all.

Currently implemented in-tree drivers(hw_random.c, do not have spec
about 
VIA) do not perform any kind of validation, drivers created for
OCF/acrypto
have HW validated RNG.
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 would be even be a good idea to have two way of turning it on - 
kernel config option and ioctl() one - to allow embedded systems
with too limited userspace not change it's applications.
Of course with big fat warning about possible dramatical consequences.

> Cheers,
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]