mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Jason Cooper <barebox@lakedaemon.net>
To: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 2/5] lib: random: get_random_bytes from HWRNG if present
Date: Fri, 26 Feb 2016 20:28:32 +0000	[thread overview]
Message-ID: <20160226202832.GE7219@io.lakedaemon.net> (raw)
In-Reply-To: <1456488287-23404-3-git-send-email-s.trumtrar@pengutronix.de>

Hi Steffen,

On Fri, Feb 26, 2016 at 01:04:44PM +0100, Steffen Trumtrar wrote:
> Instead of generating pseudo random numbers, get random bytes
> from an optional HW generator, if enabled and registered.
> 
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> ---
>  lib/random.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)

I have a long interest in KASLR on arm/arm64, so I'm glad to see this
series!  :-)

> diff --git a/lib/random.c b/lib/random.c
> index 210fea99466e..ff82dd1bed85 100644
> --- a/lib/random.c
> +++ b/lib/random.c
> @@ -1,5 +1,6 @@
>  #include <common.h>
>  #include <stdlib.h>
> +#include <linux/hw_random.h>
>  
>  static unsigned int random_seed;
>  
> @@ -22,6 +23,24 @@ void get_random_bytes(void *_buf, int len)
>  {
>  	char *buf = _buf;
>  
> +	if (IS_ENABLED(CONFIG_HWRNG)) {
> +		struct hwrng *rng;
> +		int bytes;
> +
> +		rng = hwrng_get_first();
> +		if (!PTR_ERR(rng)) {
> +			while (len) {
> +				bytes = hwrng_get_data(rng, _buf, len, 0);
> +				if (!bytes)
> +					goto sw_fallback;
> +				len -= bytes;
> +			}
> +
> +			return;
> +		}
> +	}
> +
> +sw_fallback:
>  	while (len--)
>  		*buf++ = rand() % 256;
>  }

However, I disagree with this approach.  One of the main problems we've
had over the years with random number generation is not being clear
about *how* the numbers were generated.  Something designed for placing
characters in a game is not suitable for creating long-term crypto keys,
stack canaries, and ASLR offsets.  See the paper on iOS bootloader and
KASLR [1].

With that in mind, I'd like to suggest that we preserve the current
functionality of get_random_bytes() as a non-strong source of entropy.
After all, all current calls to srand() feed in a time...

We can then add get_hwrng_bytes() which makes it clear where the bytes
are coming from.  Users down the line can more easily make an assessment
of whether the SoC hwrng is trusted or not for their usecase.

My goal here is to have the bootloader grab some strong random numbers
to hand off to the kernel.  The decompressor would consume a bit of it
to initialize KASLR, and the rest would be consumed seeding the kernel's
entropy pools.

A second goal is to have the OS write a seed file somewhere the
bootloader can access.  Then, on reboot, the bootloader can read it in
and hand it off to the kernel for KASLR, etc.  But that is orthogonal to
this patch series...

thx,

Jason.

[1] http://mista.nu/research/early_random-paper.pdf

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2016-02-26 20:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26 12:04 [PATCH 0/5] HWRNG: add support for HW Random Number Generators Steffen Trumtrar
2016-02-26 12:04 ` [PATCH 1/5] drivers: add simple hw_random implementation Steffen Trumtrar
2016-02-29  7:06   ` Sascha Hauer
2016-02-26 12:04 ` [PATCH 2/5] lib: random: get_random_bytes from HWRNG if present Steffen Trumtrar
2016-02-26 20:28   ` Jason Cooper [this message]
2016-02-29 13:45     ` Steffen Trumtrar
2016-02-26 12:04 ` [PATCH 3/5] ARM: imx25: clk: add rngb clock Steffen Trumtrar
2016-02-26 12:04 ` [PATCH 4/5] ARM: i.MX25: dtsi: add rng node Steffen Trumtrar
2016-02-26 12:04 ` [PATCH 5/5] hw_random: add driver for Freescale RNGC Steffen Trumtrar
2016-02-29  7:33   ` Sascha Hauer

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=20160226202832.GE7219@io.lakedaemon.net \
    --to=barebox@lakedaemon.net \
    --cc=barebox@lists.infradead.org \
    --cc=s.trumtrar@pengutronix.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
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