Re: Yet another updated entropy patch

[Thomas Schwinge]

Hello!

On Sun, Jul 15, 2007 at 10:53:02PM +0200, Marcus Brinkmann wrote:
> At Fri, 13 Jul 2007 22:50:00 -0400,
> Michael Casadevall <sonicmctails@gmail.com> wrote:
> > On Jul 13, 2007, at 4:30 AM, Marcus Brinkmann wrote:
> > /* Sune Kirkeby's entropy patch (which was a port of the
> >   * linux entropy drivers for GNU mach) placed the keyboard
> >   * entropy source here. I looked at that for an idea of
> >   * where how to do write this driver. */
> 
> Drop the superfluous * characters.  I don't consider it more readable,

I do.  :-)

> but even it is more readable, there is an overriding concern: You are
> formatting the text across two dimensions, while it should be
> formatted as a one dimensional text.

Uhm, Marcus, I don't really feel like discussing such nuisance, but I'd
say that as soon as you're putting in new-line breaks (which the GCS and
our own sanity mandates) you're as well editing in two dimensions, isn't
it?

> 1) A screen reader will read your text aloud as: "... a port of the
> ASTERISK linux entropy ..."

Stupid screen reader's artificial intelligence.  ;-)

> 2) If you edit the text, you have to edit the *'s as well.  Actually,
> emacs is smart enough to do this for you in most circumstances, but
> anyway, it's just wrong.

You also have to edit the new-line breaks or have your editor do it.


But now for some more important things.

> > > This is a shame!  You shall not waste perfectly good entropy like
> > > this.  In fact, you just convinced me that we should do pool mixing in
> > > the kernel.  (But this is not the only reason).

Hmm.

> > > Now for the more serious stuff: All entropy ain't equal.  Entropy from
> > > the network, keyboard, hard drive and mouse have very different
> > > quality.  There is no perfect way to estimate the amount of entropy
> > > from any of these sources, but I will give you a quick example why
> > > this is a problem.  Consider keyboard input.  Typically, we use maybe
> > > 70-80 characters, and not all equally often.  However, you store these
> > > in 8 bit which can hold 256 distinct values.  Clearly the 256 distinct
> > > possible values are not going to be evenly distributed.  Some will
> > > never occur, some will occur more often than others.  Network packets
> > > are similar, and mouse data is also not perfectly random (in fact, you
> > > OR a constant into the byte, and these bits will always be on no
> > > matter what).  In any case, entropy is often over-rated.
> > >
> > > There are two things missing in your patch:
> > >
> > > 1. [ Entropy needs weighting. ]

> > > 2. The entropy pool then needs to be mixed, because the entropy is
> > > only an estimate and fluctuates wildly.  Mixing evens out the
> > > distribution.  Your current driver suggests a user-space mixing, but
> > > then the user space mixer needs to know the entropy estimate!  This
> > > could probably done by the control interface, but this starts to
> > > become unwildly.  Furthermore, it is not a good idea to drop entropy
> > > when the pool is full (you can't increase the entropy above the pool
> > > size, but you can improve the quality of the pool by mixing more
> > > entropy into it as a safety net, even when it is full).  Entropy is a
> > > scarce resource, and we have such poor entropy sources that pushing
> > > all data over to user space may be a performance issue in the current
> > > implementation (consider that all network traffic needs to be copied
> > > several times!).  It seems to make sense to me to mix in the kernel,
> > > and again in user space (user space then implements pools with
> > > different qualities, based on the high quality kernel entropy pool
> > > data).
> 
> I think the main arguments in favor of in-kernel mixing are:
> 
> 1) You don't waste any entropy (additional entropy will serve to
> improve pool quality).

True.  But: in reality (in a running system) you also wouldn't waste any
entropy, I suppose, because there would be a translator continuously
(trying to and blocking while) reading out of the entropy device, so that
all entropy data would be transferred to user space into the respective
translator's pool, as soon as it was made available by the kernel.

> 2) The entropy of PC random sources is generally extremely low, which
> means that you have a poor raw source data to random data ration.
> Mixing in the kernel drastically reduces data transfer quantity.

This is absolutely true.  However you didn't convince me yet if you say
this is a reason to put entropy mixing into the micro kernel.  We could
also put network stacks or file systems back into the kernel with such
argumentation.  Or where is the difference?

> 3) A marginal security argument: The internal status of the pool is
> potentially more strongly hidden.

User space (user `root', opening the `entropy' device) can read out all
entropy nevertheless, so I don't see what this would buy us.


Can't we come up with something better than putting the mixing machinery
into the kernel?


Regards,
 Thomas

signature.asc
Description: Digital signature