Linux-man Archive on lore.kernel.org
 help / color / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Stephan Mueller <smueller@chronox.de>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Andy Lutomirski <luto@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	"Ahmed S. Darwish" <darwish.07@gmail.com>,
	Lennart Poettering <mzxreary@0pointer.de>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Alexander E. Patrakov" <patrakov@gmail.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Willy Tarreau <w@1wt.eu>, Matthew Garrett <mjg59@srcf.ucam.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	linux-man <linux-man@vger.kernel.org>
Subject: Re: [PATCH v3 0/8] Rework random blocking
Date: Fri, 27 Dec 2019 08:04:36 -0500
Message-ID: <20191227130436.GC70060@mit.edu> (raw)
In-Reply-To: <4048434.Q8HajmOrkZ@tauon.chronox.de>

On Fri, Dec 27, 2019 at 11:29:22AM +0100, Stephan Mueller wrote:
> 
> My definition of TRNG is identical to the German AIS 31 and I guess identical 
> to your definition of a TRNG.
> 
> A TRNG will produce an amount of random data that is equal to the amount of 
> "fresh" entropy that was provided by the noise source. I.e. it should be 
> identical to the blocking_pool behavior.

This begs the question of determining: (a) how much "fresh entropy"
you can actually get from a noise source, (b) at what rate the "fresh
entropy" is arriving, and (c) what assurance(s) you have that the
noise source is actually working correctly.

You can't make those assurances from software alone; it needs to be an
aspect of holistic design of the hardware's design; the supply chain,
and the software.  So if we are going to claime that we have something
like GRND_TRUERANDOM or /dev/trandom, or whatever, it needs to work on
IOT devices running ARM, RISC-V, MIPS, PowerPC, x86.  Some of these
architectures have no instruction reordering and are stupid simple;
some of these hardware platforms may have no high-resolution clock or
cryptographic instructions.

In addition, if you use a hardware device which is USB attached, how
does the kernel know that it really is the device that you think it
is?  The only way you know that a ChaosKey is a ChaosKey is by its USB
vendor and product id --- which can be easily forged by an attacker,
either in the supply chain or delivery path, or who walks up to the
laptop, yanks out the ChaosKey and replaces it with a "PutinKey" or a
"NSAKey".

So creating somethinig which shows up as "true random number
generator" as a generic Linux concept seems to me to be fraught
endeavor, and I'm not at all convince people need it.

> - add a new GRND_TRUERANDOM flag to getrandom(2) which allows access to the 
> TRNG. Andy did not like it because he mentioned that it may be misused since 
> the syscall is unprivileged.

Even if we could solve the "how the hell can the kernel guarantee that
the noise source is legitimate" problem in a general way that works
across all of the architectures, we still have the problem that
everyone thinks they need "the good stuff".

Suppose the system call was privileged and "true randomness" could
only be accessed as root.  What would happen?  Application programmers
would give instructions requiring that their application be installed
as root to be more secure, "because that way you can get access the
_really_ good random numbers".

So let's take a step back and ask the question: "Exactly what _value_
do you want to provide by creating some kind of true random
interface?"  What does this enable?  What applications does this
really help?

As I thought while watching the latest Star Wars movie: Why?  Why?
Whywhywhy?

					- Ted

  reply index

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-23  8:20 Andy Lutomirski
2019-12-23  8:20 ` [PATCH v3 1/8] random: Don't wake crng_init_wait when crng_init == 1 Andy Lutomirski
2020-01-07 20:42   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 2/8] random: Add a urandom_read_nowait() for random APIs that don't warn Andy Lutomirski
2020-01-07 20:43   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 3/8] random: Add GRND_INSECURE to return best-effort non-cryptographic bytes Andy Lutomirski
2020-01-07 20:44   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 4/8] random: Ignore GRND_RANDOM in getentropy(2) Andy Lutomirski
2020-01-07 20:44   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 5/8] random: Make /dev/random be almost like /dev/urandom Andy Lutomirski
2020-01-07 21:02   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 6/8] random: Remove the blocking pool Andy Lutomirski
2020-01-07 21:03   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 7/8] random: Delete code to pull data into pools Andy Lutomirski
2020-01-07 21:03   ` Theodore Y. Ts'o
2019-12-23  8:20 ` [PATCH v3 8/8] random: Remove kernel.random.read_wakeup_threshold Andy Lutomirski
2020-01-07 21:04   ` Theodore Y. Ts'o
2019-12-26  9:29 ` [PATCH v3 0/8] Rework random blocking Stephan Müller
2019-12-26 10:03   ` Matthew Garrett
2019-12-26 11:40     ` Stephan Mueller
2019-12-26 11:12   ` Andy Lutomirski
2019-12-26 12:03     ` Stephan Mueller
2019-12-26 12:46       ` Andy Lutomirski
2019-12-27  9:55         ` Stephan Mueller
2019-12-26 14:04       ` Theodore Y. Ts'o
2019-12-26 23:29         ` Andy Lutomirski
2019-12-27 10:29           ` Stephan Mueller
2019-12-27 13:04             ` Theodore Y. Ts'o [this message]
2019-12-27 21:22               ` Stephan Mueller
2019-12-27 22:08                 ` Theodore Y. Ts'o
2019-12-28  2:06                   ` Andy Lutomirski
2019-12-29 14:49                     ` Theodore Y. Ts'o
2019-12-29 15:08                       ` Andy Lutomirski
2019-12-28  7:01                   ` Willy Tarreau
2020-01-09 22:02                   ` Kurt Roeckx
2020-01-09 22:40                     ` Theodore Y. Ts'o
2020-01-09 23:02                       ` Kurt Roeckx
2020-01-10  7:53                         ` Stephan Mueller
2020-01-10  0:30                     ` Andy Lutomirski

Reply instructions:

You may reply publically 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=20191227130436.GC70060@mit.edu \
    --to=tytso@mit.edu \
    --cc=Jason@zx2c4.com \
    --cc=darwish.07@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=mtk.manpages@gmail.com \
    --cc=mzxreary@0pointer.de \
    --cc=patrakov@gmail.com \
    --cc=smueller@chronox.de \
    --cc=w@1wt.eu \
    /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

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git