public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Paul Wouters <paul@xelerance.com>
Cc: linux-kernel@vger.kernel.org, Gabor Gombas <gombasg@sztaki.hu>,
	fedora-xen@redhat.com
Subject: Re: more random device badness in 2.6.18 :(
Date: Tue, 10 Oct 2006 23:13:02 +0200	[thread overview]
Message-ID: <200610102313.02783.mb@bu3sch.de> (raw)
In-Reply-To: <Pine.LNX.4.63.0610102257100.27986@tla.xelerance.com>

On Tuesday 10 October 2006 23:03, Paul Wouters wrote:
> On Tue, 10 Oct 2006, Gabor Gombas wrote:
> 
> > Why should Openswan touch /dev/hw_random directly?
> 
> Because using /dev/random whlie /dev/hw_random is available does not always
> work (eg with padlock)

Oh, wait wait. I don't really understand your sentence.
Why can't you use /dev/random?

> > There is a good reason why /dev/hw_random is different from /dev/random...
> 
> Why is this happening in userland? Will rng-tools run on every bare Linux
> system now? Including embedded systems? How about xen guests who don't have
> direct access to the host's hardware (or software) random?
> 
> Why is this entropy management not part of the kernel? So for Openswan to
> work correctly, it would need to depend on another daemon that may or may
> not be available and/or running?
> 
> I still believe /dev/random should just give the best random possible for
> the machine. Wether that is software random, or a piece of hardware, should
> not matter. That's the kernel's internal state and functioning.

/dev/hw_random should never be touched by anything else than rngd.
rngd takes the data from /dev/hw_random, _verifys_ it and puts it into
the normal /dev/random pools.
The verification step is really important.
So I would like to ask the other way around. Why should be put this code
into the kernel, while it works in userspace as good (or, some people may
argue it is even better in userspace, because it can more easily be exchanged,
debugged and configured. Whatever)

-- 
Greetings Michael.

  reply	other threads:[~2006-10-10 21:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-10 18:08 more random device badness in 2.6.18 :( Paul Wouters
2006-10-10 20:50 ` Gabor Gombas
2006-10-10 21:03   ` Paul Wouters
2006-10-10 21:13     ` Michael Buesch [this message]
2006-10-10 21:50       ` Paul Wouters
2006-10-10 22:05         ` Michael Buesch
2006-10-10 23:32     ` Gabor Gombas
2006-10-11  3:46       ` Paul Wouters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610102313.02783.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=fedora-xen@redhat.com \
    --cc=gombasg@sztaki.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@xelerance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox