From: Hsin-Yi Wang <hsinyi@chromium.org>
To: Mark Salyzyn <salyzyn@android.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>, 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>,
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: Wed, 19 Feb 2020 00:52:19 +0800 [thread overview]
Message-ID: <CAJMQK-j8w5++R-CCAVVupba96JRVJ+O91J=O-MT3nep+rx1Yzw@mail.gmail.com> (raw)
In-Reply-To: <243ab5a8-2ce1-1465-0175-3f5d483cbde1@android.com>
On Wed, Feb 19, 2020 at 12:01 AM Mark Salyzyn <salyzyn@android.com> wrote:
>
> On 2/14/20 4:53 PM, Theodore Y. Ts'o wrote:
> > 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. An
> > 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
> >
> I am additionally concerned about add_bootloader_randomness() because it
> is possible for it to sleep because of add_hwgenerator_randomness() as
> once it hits the entropy threshold. As-is it can not be used inside
> start_kernel() because the sleep would result in a kernel panic, and I
> suspect its use inside early_init_dt_scan_chosen() for the commit "fdt:
> add support for rng-seed" might also be problematic since it is
> effectively called underneath start_kernel() is it not?
>
> If add_bootloader_randomness was rewritten to call
> add_device_randomness() always, and when trusted also called the
> functionality of the new credit_trusted_entropy_bits (no longer needing
> to be exported if so), then the function could be used in both
> start_kernel() and early_init_dt_scan_chosen().
>
I tested 64 bytes rng-seed previously so didn't hit the threshold that
makes it suspend. Thanks for pointing this out.
+1 for changing the add_bootloader_randomness() function as you
suggested to avoid this issue. But besides credit_entropy_bits(), they
are also different on crng_init (crng_fast_load/crng_slow_load).
next prev parent reply other threads:[~2020-02-18 16:52 UTC|newest]
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
2020-02-18 16:01 ` Mark Salyzyn
2020-02-18 16:52 ` Hsin-Yi Wang [this message]
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 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='CAJMQK-j8w5++R-CCAVVupba96JRVJ+O91J=O-MT3nep+rx1Yzw@mail.gmail.com' \
--to=hsinyi@chromium.org \
--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=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 \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).