[PATCH v2] ARM: omap2: throw the die id into the entropy pool

[PATCH v2] ARM: omap2: throw the die id into the entropy pool

[Linus Walleij]

Atleast eight bytes of this number are totally unique for the device
it seems, so this is a perfect candidate for feeding the entropy
pool. One byte more or less of constants does not matter so feed in
the entire OID struct.

Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Use omap_device_initcall() to avoid calling on non-OMAPs.
---
 arch/arm/mach-omap2/id.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..9260d09 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/random.h>
 #include <linux/slab.h>
 
 #ifdef CONFIG_SOC_BUS
@@ -130,6 +131,17 @@ void omap_get_die_id(struct omap_die_id *odi)
 	odi->id_3 = read_tap_reg(OMAP_TAP_DIE_ID_3);
 }
 
+static int __init omap_feed_randpool(void)
+{
+	struct omap_die_id odi;
+
+	/* Throw the die ID into the entropy pool at boot */
+	omap_get_die_id(&odi);
+	add_device_randomness(&odi, sizeof(odi));
+	return 0;
+}
+omap_device_initcall(omap_feed_randpool);
+
 void __init omap2xxx_check_revision(void)
 {
 	int i, j;
-- 
1.8.1.4

Re: [PATCH v2] ARM: omap2: throw the die id into the entropy pool

[Paul Walmsley]

Hi Linus,

On Thu, 5 Sep 2013, Linus Walleij wrote:

> Atleast eight bytes of this number are totally unique for the device
> it seems, so this is a perfect candidate for feeding the entropy
> pool. One byte more or less of constants does not matter so feed in
> the entire OID struct.
> 
> Cc: Theodore Ts'o <tytso@mit.edu>
> Cc: Paul Walmsley <paul@pwsan.com>
> Reviewed-by: Kevin Hilman <khilman@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Heh, that function name "add_device_randomness()" is a bit misleading.  
It's not actually intended to add "randomness": from 
drivers/char/random.c:

/*
 * Add device- or boot-specific data to the input and nonblocking
 * pools to help initialize them to unique values.
 *
 * None of this adds any entropy, it is meant to avoid the
 * problem of the nonblocking pool having similar initial state
 * across largely identical devices.
 */

But of course the function name is not your fault :-)  The entropy count 
isn't increased by this, so:

Reviewed-by: Paul Walmsley <paul@pwsan.com>

Thanks Linus.


- Paul

Re: [PATCH v2] ARM: omap2: throw the die id into the entropy pool

[Paul Walmsley]

By the way, if anyone wants to expand on Linus' patch for OMAP, there are 
several other register fields that could be mixed in, which, based on 
their names, might vary on a per-chip basis.  For example, on OMAP4, the 
CONTROL_STD_FUSE_OPP* and CONTROL_DPLL_NWELL_TRIM* registers.



- Paul

Re: [PATCH v2] ARM: omap2: throw the die id into the entropy pool

[Linus Walleij]

On Mon, Sep 9, 2013 at 9:14 PM, Paul Walmsley <paul@pwsan.com> wrote:

> Heh, that function name "add_device_randomness()" is a bit misleading.
> It's not actually intended to add "randomness": from
> drivers/char/random.c:

Yeah you're right...

Tony feel free to edit the commit message when applying.

>  * None of this adds any entropy, it is meant to avoid the
>  * problem of the nonblocking pool having similar initial state
>  * across largely identical devices.

It's noble enough, just a few years back I ran into the problem where
all boards in a test farm came up with the same ethernet MAC
address due to the initialization of the nonblocking pool being
constant.

Yours,
Linus Walleij

Re: [PATCH v2] ARM: omap2: throw the die id into the entropy pool

[Tony Lindgren]

* Linus Walleij <linus.walleij@linaro.org> [130910 01:28]:
> On Mon, Sep 9, 2013 at 9:14 PM, Paul Walmsley <paul@pwsan.com> wrote:
> 
> > Heh, that function name "add_device_randomness()" is a bit misleading.
> > It's not actually intended to add "randomness": from
> > drivers/char/random.c:
> 
> Yeah you're right...
> 
> Tony feel free to edit the commit message when applying.
> 
> >  * None of this adds any entropy, it is meant to avoid the
> >  * problem of the nonblocking pool having similar initial state
> >  * across largely identical devices.
> 
> It's noble enough, just a few years back I ran into the problem where
> all boards in a test farm came up with the same ethernet MAC
> address due to the initialization of the nonblocking pool being
> constant.

Thanks, I'll apply this into omap-for-v3.13/fixes-not-urgent
with updated comments.

Tony