diff mbox

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

Message ID 1378366158-31183-1-git-send-email-linus.walleij@linaro.org (mailing list archive)
State New, archived
Headers show

Commit Message

Linus Walleij Sept. 5, 2013, 7:29 a.m. UTC
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(+)

Comments

Paul Walmsley Sept. 9, 2013, 7:14 p.m. UTC | #1
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paul Walmsley Sept. 9, 2013, 8:15 p.m. UTC | #2
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij Sept. 10, 2013, 8:20 a.m. UTC | #3
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Oct. 3, 2013, 6:13 p.m. UTC | #4
* 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

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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;