Linux-Doc Archive on lore.kernel.org
 help / color / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Mark Salyzyn <salyzyn@android.com>
Cc: Rob Herring <robh@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Android Kernel Team <kernel-team@android.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	Mark Brown <broonie@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alexander Potapenko <glider@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Juergen Gross <jgross@suse.com>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>
Subject: Re: [PATCH 2/3] random: rng-seed source is utf-8
Date: Fri, 14 Feb 2020 19:53:36 -0500
Message-ID: <20200215005336.GD439135@mit.edu> (raw)
In-Reply-To: <f15511bf-b840-0633-3354-506b7b0607fe@android.com>

On Fri, Feb 14, 2020 at 02:55:36PM -0800, Mark Salyzyn wrote:
> > This is why I really think what gets specified via the boot command
> > line, or bootconfig, should specify the bits of entropy and the
> > entropy seed *separately*, so it can be specified explicitly, instead
> > of assuming that *everyone knows* that rng-seed is either (a) a binary
> > string, or (b) utf-8, or (c) a hex string.  The fact is, everyone does
> > *not* know, or everyone will have a different implementation, which
> > everyone will say is *obviously* the only way to go....
> > 
> Given that the valid option are between 4 (hex), 6 (utf-8) or 8 (binary), we
> can either split the difference and accept 6; or take a pass at the values
> and determine which of the set they belong to [0-9a-fA-F], [!-~] or
> [\000-\377]  nor need to separately specify.

So let's split this up into separate issues.  First of all, from an
architectural issue, I really think we need to change
add_bootloader_randomness() in drivers/char/random.c so it looks like this:

void add_bootloader_randomness(const void *buf, unsigned int size, unsigned int entropy_bits)

That's because this is a general function that could be used by any
number of bootloaders.  For example, for the UEFI bootloader, it can
use the UEFI call that will return binary bits.  Some other bootloader
might use utf-8, etc.  So it would be an abstraction violation to have
code in drivers/char/random.c make assumption about how a particular
bootloader might be behaving.

The second question is we are going to be parsing an rng_seed
parameter it shows up in bootconfig or in the boot command line, how
do we decide how many bits of entropy it actually has.  The advantage
of using the boot command line is we don't need to change the rest of
the bootloader ecosystem.  But that's also a massive weakness, since
apparently some people are already using it, and perhaps not in the
same way.

So what I'd really prefer is if we use something new, and we define it
in a way that makes as close as possible to "impossible to misuse".
(See Rusty Russell's API design manifesto[1]).  So I'm going to
propose something different.  Let's use something new, say
entropy_seed_hex, and let's say that it *must* be a hex string:

    entropy_seed_hex=7337db91a4824e3480ba6d2dfaa60bec

If it is not a valid hex string, it gets zero entropy credit.

I don't think we really need to worry about efficient encoding of the
seed, since 256 bits is only 64 characters using a hex string.  And
whether it's 32 characters or 64 characters, the max command line
string is 32k, so it's probably not worth it to try to do something
more complex.  (And only 128 bits is needed to declare the CRNG to be
fully initialized, in which case we're talking about 16 characters
versus 32 charaters.)

[1] http://sweng.the-davies.net/Home/rustys-api-design-manifesto

						- Ted


  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14  6:10 [PATCH 0/3] random: add random.rng_seed to bootconfig entry Masami Hiramatsu
2020-02-14  6:10 ` [PATCH 1/3] bootconfig: Support non-ascii characters in value Masami Hiramatsu
2020-02-14  6:10 ` [PATCH 2/3] random: rng-seed source is utf-8 Masami Hiramatsu
2020-02-14 18:14   ` Hsin-Yi Wang
2020-02-14 19:58   ` Rob Herring
2020-02-14 22:47     ` Theodore Y. Ts'o
2020-02-14 22:55       ` Mark Salyzyn
2020-02-15  0:53         ` Theodore Y. Ts'o [this message]
2020-02-18 16:01           ` Mark Salyzyn
2020-02-18 16:52             ` Hsin-Yi Wang
2020-02-18 17:14             ` Theodore Y. Ts'o
2020-02-14  6:10 ` [PATCH 3/3] random: add random.rng_seed= bootconfig option Masami Hiramatsu
2020-02-14 13:49 ` [PATCH 0/3] random: add random.rng_seed to bootconfig entry Rob Herring
2020-02-14 17:00   ` Mark Salyzyn
2020-02-14 18:14     ` Rob Herring
2020-02-14 18:31       ` Mark Salyzyn
2020-02-15  0:17       ` Masami Hiramatsu

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=20200215005336.GD439135@mit.edu \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=glider@google.com \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hsinyi@chromium.org \
    --cc=jgross@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=mchehab+samsung@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=nivedita@alum.mit.edu \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=richard.henderson@linaro.org \
    --cc=robh@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=rppt@linux.ibm.com \
    --cc=salyzyn@android.com \
    --cc=tglx@linutronix.de \
    /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-Doc Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-doc/0 linux-doc/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-doc linux-doc/ https://lore.kernel.org/linux-doc \
		linux-doc@vger.kernel.org
	public-inbox-index linux-doc

Example config snippet for mirrors

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


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