All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Torsten Duwe <duwe@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Matt Mackall" <mpm@selenic.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Rusty Russell" <rusty@rustcorp.com.au>,
	"Satoru Takeuchi" <satoru.takeuchi@gmail.com>,
	ingo.tuchscherer@de.ibm.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Hans-Georg Markgraf" <MGRF@de.ibm.com>,
	"Gerald Schaefer" <gerald.schaefer@de.ibm.com>,
	"Martin Schwidefsky" <schwidefsky@de.ibm.com>,
	"Heiko Carstens" <heiko.carstens@de.ibm.com>,
	"Joe Perches" <joe@perches.com>, "Jörn Engel" <joern@logfs.org>
Subject: Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device
Date: Mon, 16 Jun 2014 10:40:33 -0400	[thread overview]
Message-ID: <20140616144033.GC19387@thunk.org> (raw)
In-Reply-To: <20140616140719.GA1744@suse.de>

On Mon, Jun 16, 2014 at 04:07:19PM +0200, Torsten Duwe wrote:
> > > TPM RNG is a crook ;-)
> > 
> > I think the word you mean is "crock" (as in "crock of sh*t"?)  :-)
> 
> Actually, I was thinking of a crutch. Makes you walk slowly, but better
> than nothing. Seems I've bent the wrong tube.

Heh.  One of the things that I have considered, especially for TPM, is
that in addition to having a very small quality rating, we should also
have some kind of delay so that we sleep some small amount time before
we pull from the TPM again.

Otherwise the result of using a very small quality rating is that we
end up pounding on the TPM a huge amount until the entropy pool is
above the write_wakeup threshold.  If there's some "real" use of the
TPM, such as authenticating to a wireless network, or some such, I'd
rather not be constantly pounding on the TPM if so happens that there
is a heavy drain on /dev/random at the same time that Network Manager
needs to reauthenticate to the 802.1x network.

> > manufacturer is supplying the device driver, it may not be a value
> > that other people will agree with.  Which is why I think making it
> > runtime configurable is a good thing.
> 
> Boot time configurable, I'd say. Again: this is a hardware property,
> multiplied by the admin's level of confidence in the absence of backdoors.
> It's easy with s390: from z/VM you can read all the guest's memory anyway.
> If you use this machine, you already trust IBM.

Sure, but I guess I'm a bit allergic to gazillions of boot
command-line parameters.  I guess if you are building a modular
kernel, this matters a lot less, since you can put the configs in
/etc/modprobe.d.

						- Ted

  reply	other threads:[~2014-06-16 14:40 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-21 14:29 [PATCH v2 00/03]: khwrngd Torsten Duwe
2014-03-21 14:32 ` [Patch v2 01/03]: provide an injection point for pure hardware randomness Torsten Duwe
2014-03-21 14:33 ` [PATCH v2 02/03]: hwrng: create filler thread Torsten Duwe
2014-03-27  0:50   ` Andy Lutomirski
2014-03-27  1:03     ` H. Peter Anvin
2014-03-27  1:11       ` Andy Lutomirski
2014-03-27  1:55         ` H. Peter Anvin
2014-03-27  4:47         ` H. Peter Anvin
2014-03-27 15:03           ` Torsten Duwe
2014-03-27 16:06           ` Andy Lutomirski
2014-03-27 14:54       ` Torsten Duwe
2014-03-27 15:47         ` Andy Lutomirski
2014-04-14 16:02       ` [PATCH v3 00/03]: hwrng: an in-kernel rngd Torsten Duwe
2014-04-14 16:04         ` [PATCH v3 01/03]: hwrng: provide an injection point for pure hardware randomness Torsten Duwe
2014-04-14 16:05         ` [PATCH v3 02/03]: hwrng: create filler thread Torsten Duwe
2014-04-14 16:06         ` [PATCH v3 03/03]: hwrng: khwrngd derating per device Torsten Duwe
2014-04-14 16:41           ` Andy Lutomirski
2014-04-15  8:51             ` Torsten Duwe
2014-04-15 16:53               ` Andy Lutomirski
2014-05-27 13:41                 ` [PATCH v5 00/03]: hwrng: an in-kernel rngd Torsten Duwe
2014-05-27 13:44                   ` [Patch 01/03]: provide an injection point for pure hardware randomness Torsten Duwe
2014-05-27 13:45                   ` [Patch v5 02/03]: hwrng: create filler thread Torsten Duwe
2014-05-27 13:46                   ` [Patch v5 03/03]: hwrng: khwrngd derating per device Torsten Duwe
2014-05-27 14:11                     ` [Patch v5.1 " Torsten Duwe
2014-06-12  1:24                       ` H. Peter Anvin
2014-06-12 10:09                         ` Torsten Duwe
2014-06-14  2:40                           ` Theodore Ts'o
2014-06-14  2:44                             ` H. Peter Anvin
2014-06-15  5:11                               ` Theodore Ts'o
2014-06-16  7:31                                 ` Torsten Duwe
2014-06-16 11:22                                   ` Theodore Ts'o
2014-06-16 14:07                                     ` Torsten Duwe
2014-06-16 14:40                                       ` Theodore Ts'o [this message]
     [not found]                                     ` <20140616141444.GB1744@suse.de>
     [not found]                                       ` <20140616142812.GB19387@thunk.org>
2014-07-11 13:43                                         ` Ingo Tuchscherer
2014-07-11 14:42                                           ` Theodore Ts'o
2014-04-14 16:09         ` [PATCH v3 00/03]: hwrng: an in-kernel rngd H. Peter Anvin
2014-04-14 16:24           ` Torsten Duwe
2014-04-14 16:29             ` H. Peter Anvin
2014-04-14 16:43             ` Andy Lutomirski
2014-04-14 16:27           ` [PATCH v4 03/03]: hwrng: khwrngd derating per device Torsten Duwe
2014-03-21 14:34 ` [PATCH v2 " Torsten Duwe

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=20140616144033.GC19387@thunk.org \
    --to=tytso@mit.edu \
    --cc=MGRF@de.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=duwe@suse.de \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=ingo.tuchscherer@de.ibm.com \
    --cc=joe@perches.com \
    --cc=joern@logfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mpm@selenic.com \
    --cc=rusty@rustcorp.com.au \
    --cc=satoru.takeuchi@gmail.com \
    --cc=schwidefsky@de.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.