* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 17:45 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 17:45 UTC (permalink / raw)
To: linux-arm-kernel
Laura,
Sorry to hijack the thread (sort of). :)
+ Kees Cook
On Wed, Feb 12, 2014 at 12:51:05PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014, Laura Abbott wrote:
> > This is an RFC to seed the random number pool earlier when using devicetree.
> > The big issue this is trying to solve is the fact that the stack canary for
> > ARM tends to be the same across bootups of the same device. This is because
> > the random number pools do not get initialized until after the canary has
> > been set up. The canary can be moved later, but in general there is still
> > no way to reliably get random numbers early for other features (e.g. vector
> > randomization).
>
> Implementation-wise this looks reasonable, and it obviously addresses a
> very real problem.
>
> > The goal here is to allow devices to add to the random pools via
> > add_device_randomness or some other method of their chosing at FDT time.
> > I realize that ARCH_RANDOM is already available but this didn't work because
> > 1) ARCH_RANDOM is not multi-platform compatible without added
> > infrastructure to ARM
>
> That could certainly be done, but I agree that a more generic
> approach like you did is nicer. One thing that might be useful
> would be to wire up your OF_RANDOM infrastructure as a generic
> implementation of ARCH_RANDOM, and merge your header file into
> include/asm-generic/archrandom.h, with an added way to call
> arch_get_random_long() for the devices you add.
>
> > The big reason to skip ARCH_RANDOM though is that the random number generation
> > we have would be reasonable if only seeded earlier.
>
> Yes, makes sense.
>
> I also wonder if we should add a 'trivial' implementation that just
> reads a DT property full of random numbers to use as either an initial
> seed, or to feed into arch_get_random_long(). This would allow the
> boot loader to pass any entropy it has already gathered into the kernel,
> but leaves the danger that people might pass static not-so-random data
> through a precompiled dtb file ;-). If we get the boot loaders to be
> smart enough, doing only this would be a much simpler kernel implementation
> than your suggestion, but I'm not sure how far I want to trust boot loaders.
I brought this up at last weeks devicetree irc meeting. My goal is to
provide early randomness for kaslr on ARM. Currently, my idea is modify
the init script to save an additional random seed from /dev/urandom to
/boot/random-seed.
The bootloader would then load this file into ram, and pass the
address/size to the kernel either via dt, or commandline. kaslr (run in
the decompressor) would consume some of this randomness, and then
random.c would consume the rest in a non-crediting initialization.
While not ideal, it works in absence of an HRNG, and is no worse than
the current situation of storing the seed in /var/lib/misc/random-seed.
It also doesn't require modification of the bootloaders. Just an
updated kernel, and update the bootloader environment to load the
seed.
Unfortunately, it's an idea so far. I have one project to get off of my
plate, then this is next :)
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 17:45 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 17:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Laura Abbott, Grant Likely, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Kumar Gala,
Kees Cook
Laura,
Sorry to hijack the thread (sort of). :)
+ Kees Cook
On Wed, Feb 12, 2014 at 12:51:05PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014, Laura Abbott wrote:
> > This is an RFC to seed the random number pool earlier when using devicetree.
> > The big issue this is trying to solve is the fact that the stack canary for
> > ARM tends to be the same across bootups of the same device. This is because
> > the random number pools do not get initialized until after the canary has
> > been set up. The canary can be moved later, but in general there is still
> > no way to reliably get random numbers early for other features (e.g. vector
> > randomization).
>
> Implementation-wise this looks reasonable, and it obviously addresses a
> very real problem.
>
> > The goal here is to allow devices to add to the random pools via
> > add_device_randomness or some other method of their chosing at FDT time.
> > I realize that ARCH_RANDOM is already available but this didn't work because
> > 1) ARCH_RANDOM is not multi-platform compatible without added
> > infrastructure to ARM
>
> That could certainly be done, but I agree that a more generic
> approach like you did is nicer. One thing that might be useful
> would be to wire up your OF_RANDOM infrastructure as a generic
> implementation of ARCH_RANDOM, and merge your header file into
> include/asm-generic/archrandom.h, with an added way to call
> arch_get_random_long() for the devices you add.
>
> > The big reason to skip ARCH_RANDOM though is that the random number generation
> > we have would be reasonable if only seeded earlier.
>
> Yes, makes sense.
>
> I also wonder if we should add a 'trivial' implementation that just
> reads a DT property full of random numbers to use as either an initial
> seed, or to feed into arch_get_random_long(). This would allow the
> boot loader to pass any entropy it has already gathered into the kernel,
> but leaves the danger that people might pass static not-so-random data
> through a precompiled dtb file ;-). If we get the boot loaders to be
> smart enough, doing only this would be a much simpler kernel implementation
> than your suggestion, but I'm not sure how far I want to trust boot loaders.
I brought this up at last weeks devicetree irc meeting. My goal is to
provide early randomness for kaslr on ARM. Currently, my idea is modify
the init script to save an additional random seed from /dev/urandom to
/boot/random-seed.
The bootloader would then load this file into ram, and pass the
address/size to the kernel either via dt, or commandline. kaslr (run in
the decompressor) would consume some of this randomness, and then
random.c would consume the rest in a non-crediting initialization.
While not ideal, it works in absence of an HRNG, and is no worse than
the current situation of storing the seed in /var/lib/misc/random-seed.
It also doesn't require modification of the bootloaders. Just an
updated kernel, and update the bootloader environment to load the
seed.
Unfortunately, it's an idea so far. I have one project to get off of my
plate, then this is next :)
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:13 ` Olof Johansson
0 siblings, 0 replies; 71+ messages in thread
From: Olof Johansson @ 2014-02-12 18:13 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, Kees Cook, Laura Abbott, Grant Likely,
Rob Herring, linux-kernel, devicetree, linux-arm-kernel,
Kumar Gala
On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
>
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
>
> While not ideal, it works in absence of an HRNG, and is no worse than
> the current situation of storing the seed in /var/lib/misc/random-seed.
> It also doesn't require modification of the bootloaders. Just an
> updated kernel, and update the bootloader environment to load the
> seed.
Hmm. There are some drawbacks with this -- it assumes you can "just
update the bootloader environment" which in general isn't easy to do.
Also, you can't assume that /boot is writable or exists on all
embedded systems.
In general, taking both runtime and system-dependend data and using
that to see entropy is a good idea. For example, device trees that
contain serial numbers and mac addresses for the individual system. I
think x86 feeds the DMI table in for similar purposes.
If that can be amended on some systems with a runtime seed (from
/boot), that's good but we can't rely on it.
-Olof
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:13 ` Olof Johansson
0 siblings, 0 replies; 71+ messages in thread
From: Olof Johansson @ 2014-02-12 18:13 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
>
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
>
> While not ideal, it works in absence of an HRNG, and is no worse than
> the current situation of storing the seed in /var/lib/misc/random-seed.
> It also doesn't require modification of the bootloaders. Just an
> updated kernel, and update the bootloader environment to load the
> seed.
Hmm. There are some drawbacks with this -- it assumes you can "just
update the bootloader environment" which in general isn't easy to do.
Also, you can't assume that /boot is writable or exists on all
embedded systems.
In general, taking both runtime and system-dependend data and using
that to see entropy is a good idea. For example, device trees that
contain serial numbers and mac addresses for the individual system. I
think x86 feeds the DMI table in for similar purposes.
If that can be amended on some systems with a runtime seed (from
/boot), that's good but we can't rely on it.
-Olof
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:13 ` Olof Johansson
0 siblings, 0 replies; 71+ messages in thread
From: Olof Johansson @ 2014-02-12 18:13 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, Kees Cook, Laura Abbott, Grant Likely,
Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Kumar Gala
On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
>
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
>
> While not ideal, it works in absence of an HRNG, and is no worse than
> the current situation of storing the seed in /var/lib/misc/random-seed.
> It also doesn't require modification of the bootloaders. Just an
> updated kernel, and update the bootloader environment to load the
> seed.
Hmm. There are some drawbacks with this -- it assumes you can "just
update the bootloader environment" which in general isn't easy to do.
Also, you can't assume that /boot is writable or exists on all
embedded systems.
In general, taking both runtime and system-dependend data and using
that to see entropy is a good idea. For example, device trees that
contain serial numbers and mac addresses for the individual system. I
think x86 feeds the DMI table in for similar purposes.
If that can be amended on some systems with a runtime seed (from
/boot), that's good but we can't rely on it.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:32 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 18:32 UTC (permalink / raw)
To: Olof Johansson
Cc: devicetree, Laura Abbott, Kees Cook, Arnd Bergmann, linux-kernel,
Rob Herring, Kumar Gala, Grant Likely, linux-arm-kernel
On Wed, Feb 12, 2014 at 10:13:59AM -0800, Olof Johansson wrote:
> On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
>
> > I brought this up at last weeks devicetree irc meeting. My goal is to
> > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > the init script to save an additional random seed from /dev/urandom to
> > /boot/random-seed.
> >
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
> >
> > While not ideal, it works in absence of an HRNG, and is no worse than
> > the current situation of storing the seed in /var/lib/misc/random-seed.
> > It also doesn't require modification of the bootloaders. Just an
> > updated kernel, and update the bootloader environment to load the
> > seed.
>
> Hmm. There are some drawbacks with this -- it assumes you can "just
> update the bootloader environment" which in general isn't easy to do.
true, the scope of my experience is consumer grade NASs, routers and
APs. At the very least, it's much easier than upgrading the bootloader.
Also, my pov is as a hobbyist modifying devices post-sale. The idea is
something I could add to my existing boxes without having to upgrade the
bootloaders.
> Also, you can't assume that /boot is writable or exists on all
> embedded systems.
In systems missing this capability, they often have the ability to
update the kernel. All that's needed is one block of flash. Current
random-seed size is 512 bytes. I'm not saying it's easy or desirable.
But for folks who feel it's necessary to have kaslr on embedded devices,
it would facilitate better random numbers. "Better" meaning much harder
for an attacker to guess.
> In general, taking both runtime and system-dependend data and using
> that to see entropy is a good idea.
Of course, I wasn't arguing for one or the other. As you said later, in
situations where you can't feed in a seed file, MAC addresses and serial
numbers are better than nothing.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:32 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 18:32 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 10:13:59AM -0800, Olof Johansson wrote:
> On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
>
> > I brought this up at last weeks devicetree irc meeting. My goal is to
> > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > the init script to save an additional random seed from /dev/urandom to
> > /boot/random-seed.
> >
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
> >
> > While not ideal, it works in absence of an HRNG, and is no worse than
> > the current situation of storing the seed in /var/lib/misc/random-seed.
> > It also doesn't require modification of the bootloaders. Just an
> > updated kernel, and update the bootloader environment to load the
> > seed.
>
> Hmm. There are some drawbacks with this -- it assumes you can "just
> update the bootloader environment" which in general isn't easy to do.
true, the scope of my experience is consumer grade NASs, routers and
APs. At the very least, it's much easier than upgrading the bootloader.
Also, my pov is as a hobbyist modifying devices post-sale. The idea is
something I could add to my existing boxes without having to upgrade the
bootloaders.
> Also, you can't assume that /boot is writable or exists on all
> embedded systems.
In systems missing this capability, they often have the ability to
update the kernel. All that's needed is one block of flash. Current
random-seed size is 512 bytes. I'm not saying it's easy or desirable.
But for folks who feel it's necessary to have kaslr on embedded devices,
it would facilitate better random numbers. "Better" meaning much harder
for an attacker to guess.
> In general, taking both runtime and system-dependend data and using
> that to see entropy is a good idea.
Of course, I wasn't arguing for one or the other. As you said later, in
situations where you can't feed in a seed file, MAC addresses and serial
numbers are better than nothing.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:32 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 18:32 UTC (permalink / raw)
To: Olof Johansson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Laura Abbott, Kees Cook,
Arnd Bergmann, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Kumar Gala, Grant Likely,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Feb 12, 2014 at 10:13:59AM -0800, Olof Johansson wrote:
> On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
>
> > I brought this up at last weeks devicetree irc meeting. My goal is to
> > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > the init script to save an additional random seed from /dev/urandom to
> > /boot/random-seed.
> >
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
> >
> > While not ideal, it works in absence of an HRNG, and is no worse than
> > the current situation of storing the seed in /var/lib/misc/random-seed.
> > It also doesn't require modification of the bootloaders. Just an
> > updated kernel, and update the bootloader environment to load the
> > seed.
>
> Hmm. There are some drawbacks with this -- it assumes you can "just
> update the bootloader environment" which in general isn't easy to do.
true, the scope of my experience is consumer grade NASs, routers and
APs. At the very least, it's much easier than upgrading the bootloader.
Also, my pov is as a hobbyist modifying devices post-sale. The idea is
something I could add to my existing boxes without having to upgrade the
bootloaders.
> Also, you can't assume that /boot is writable or exists on all
> embedded systems.
In systems missing this capability, they often have the ability to
update the kernel. All that's needed is one block of flash. Current
random-seed size is 512 bytes. I'm not saying it's easy or desirable.
But for folks who feel it's necessary to have kaslr on embedded devices,
it would facilitate better random numbers. "Better" meaning much harder
for an attacker to guess.
> In general, taking both runtime and system-dependend data and using
> that to see entropy is a good idea.
Of course, I wasn't arguing for one or the other. As you said later, in
situations where you can't feed in a seed file, MAC addresses and serial
numbers are better than nothing.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-12 17:45 ` Jason Cooper
(?)
@ 2014-02-12 18:17 ` Arnd Bergmann
-1 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2014-02-12 18:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Jason Cooper, keescook, devicetree, Laura Abbott, linux-kernel,
Rob Herring, Kumar Gala, Grant Likely
On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
>
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
I like the idea, but wouldn't it be easier to pass actual random data
using DT, rather than the address/size? That way we could even
use the same DT binding for passing randomness from the bootloader,
whereever it may have found that.
If the bootloader has internet connectivity, it could even mix in
some data from http://www.random.org/cgi-bin/randbyte?nbytes=256&format=f
;-)
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:17 ` Arnd Bergmann
0 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2014-02-12 18:17 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
>
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
I like the idea, but wouldn't it be easier to pass actual random data
using DT, rather than the address/size? That way we could even
use the same DT binding for passing randomness from the bootloader,
whereever it may have found that.
If the bootloader has internet connectivity, it could even mix in
some data from http://www.random.org/cgi-bin/randbyte?nbytes=256&format=f
;-)
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:17 ` Arnd Bergmann
0 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2014-02-12 18:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Laura Abbott, Jason Cooper, linux-kernel,
Rob Herring, Kumar Gala, Grant Likely, keescook
On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
>
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
I like the idea, but wouldn't it be easier to pass actual random data
using DT, rather than the address/size? That way we could even
use the same DT binding for passing randomness from the bootloader,
whereever it may have found that.
If the bootloader has internet connectivity, it could even mix in
some data from http://www.random.org/cgi-bin/randbyte?nbytes=256&format=f
;-)
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-12 18:17 ` Arnd Bergmann
(?)
@ 2014-02-12 18:45 ` Jason Cooper
-1 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 18:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, devicetree, Laura Abbott, linux-kernel,
Rob Herring, Kumar Gala, Grant Likely, keescook
On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> > I brought this up at last weeks devicetree irc meeting. My goal is to
> > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > the init script to save an additional random seed from /dev/urandom to
> > /boot/random-seed.
> >
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
>
> I like the idea, but wouldn't it be easier to pass actual random data
> using DT, rather than the address/size?
I thought about that at first, but that requires either that the
bootloader be upgraded to insert the data, or that userspace is
modifying the dtb at least twice per boot.
I chose address/size to facilitate modifying existing/fielded devices.
The user could modify the dtb once, and modify the bootloader
environment to load X amount to Y address. As a fallback, it could be
expressed on the commandline for non-DT bootloaders.
So I'm not against the idea of random-seed,{start,size} and a
random-seed,blob. I would just like the former to be available for
folks interested in the capability on existing hardware w/o upgrading
the bootloader.
> That way we could even use the same DT binding for passing randomness
> from the bootloader, whereever it may have found that.
The problem lies in defining "whereever" ;)
> If the bootloader has internet connectivity, it could even mix in
> some data from http://www.random.org/cgi-bin/randbyte?nbytes=256&format=f
> ;-)
Gah! Arnd, you just about gave me a heart attack. And http no less.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:45 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 18:45 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> > I brought this up at last weeks devicetree irc meeting. My goal is to
> > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > the init script to save an additional random seed from /dev/urandom to
> > /boot/random-seed.
> >
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
>
> I like the idea, but wouldn't it be easier to pass actual random data
> using DT, rather than the address/size?
I thought about that at first, but that requires either that the
bootloader be upgraded to insert the data, or that userspace is
modifying the dtb at least twice per boot.
I chose address/size to facilitate modifying existing/fielded devices.
The user could modify the dtb once, and modify the bootloader
environment to load X amount to Y address. As a fallback, it could be
expressed on the commandline for non-DT bootloaders.
So I'm not against the idea of random-seed,{start,size} and a
random-seed,blob. I would just like the former to be available for
folks interested in the capability on existing hardware w/o upgrading
the bootloader.
> That way we could even use the same DT binding for passing randomness
> from the bootloader, whereever it may have found that.
The problem lies in defining "whereever" ;)
> If the bootloader has internet connectivity, it could even mix in
> some data from http://www.random.org/cgi-bin/randbyte?nbytes=256&format=f
> ;-)
Gah! Arnd, you just about gave me a heart attack. And http no less.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:45 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 18:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laura Abbott,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Kumar Gala,
Grant Likely, keescook-F7+t8E8rja9g9hUCZPvPmw
On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> > I brought this up at last weeks devicetree irc meeting. My goal is to
> > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > the init script to save an additional random seed from /dev/urandom to
> > /boot/random-seed.
> >
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
>
> I like the idea, but wouldn't it be easier to pass actual random data
> using DT, rather than the address/size?
I thought about that at first, but that requires either that the
bootloader be upgraded to insert the data, or that userspace is
modifying the dtb at least twice per boot.
I chose address/size to facilitate modifying existing/fielded devices.
The user could modify the dtb once, and modify the bootloader
environment to load X amount to Y address. As a fallback, it could be
expressed on the commandline for non-DT bootloaders.
So I'm not against the idea of random-seed,{start,size} and a
random-seed,blob. I would just like the former to be available for
folks interested in the capability on existing hardware w/o upgrading
the bootloader.
> That way we could even use the same DT binding for passing randomness
> from the bootloader, whereever it may have found that.
The problem lies in defining "whereever" ;)
> If the bootloader has internet connectivity, it could even mix in
> some data from http://www.random.org/cgi-bin/randbyte?nbytes=256&format=f
> ;-)
Gah! Arnd, you just about gave me a heart attack. And http no less.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-12 18:45 ` Jason Cooper
@ 2014-02-12 19:12 ` Arnd Bergmann
-1 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2014-02-12 19:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Jason Cooper, devicetree, Laura Abbott, keescook, linux-kernel,
Rob Herring, Kumar Gala, Grant Likely
On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
> On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
> > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> > > I brought this up at last weeks devicetree irc meeting. My goal is to
> > > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > > the init script to save an additional random seed from /dev/urandom to
> > > /boot/random-seed.
> > >
> > > The bootloader would then load this file into ram, and pass the
> > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > the decompressor) would consume some of this randomness, and then
> > > random.c would consume the rest in a non-crediting initialization.
> >
> > I like the idea, but wouldn't it be easier to pass actual random data
> > using DT, rather than the address/size?
>
> I thought about that at first, but that requires either that the
> bootloader be upgraded to insert the data, or that userspace is
> modifying the dtb at least twice per boot.
>
> I chose address/size to facilitate modifying existing/fielded devices.
> The user could modify the dtb once, and modify the bootloader
> environment to load X amount to Y address. As a fallback, it could be
> expressed on the commandline for non-DT bootloaders.
Ah, so you are interested in boot loaders that can be scripted to do
what you had in mind but cannot be scripted to add or modify a DT
property. I hadn't considered that, but you are probably right that
this is at least 90% of the systems you'd find in the wild today.
Thinking this a bit further, I wonder if (at least upstream) u-boot
has a way to modify DT properties in a scripted way that would allow
the direct property. It sounds like a generally useful feature not
just for randomness, so if that doesn't already work, maybe someone
can implement it. In the simplest case, you'd only need to find the
address of an existing property in the dtb and load a file to
that location.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 19:12 ` Arnd Bergmann
0 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2014-02-12 19:12 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
> On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
> > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> > > I brought this up at last weeks devicetree irc meeting. My goal is to
> > > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > > the init script to save an additional random seed from /dev/urandom to
> > > /boot/random-seed.
> > >
> > > The bootloader would then load this file into ram, and pass the
> > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > the decompressor) would consume some of this randomness, and then
> > > random.c would consume the rest in a non-crediting initialization.
> >
> > I like the idea, but wouldn't it be easier to pass actual random data
> > using DT, rather than the address/size?
>
> I thought about that at first, but that requires either that the
> bootloader be upgraded to insert the data, or that userspace is
> modifying the dtb at least twice per boot.
>
> I chose address/size to facilitate modifying existing/fielded devices.
> The user could modify the dtb once, and modify the bootloader
> environment to load X amount to Y address. As a fallback, it could be
> expressed on the commandline for non-DT bootloaders.
Ah, so you are interested in boot loaders that can be scripted to do
what you had in mind but cannot be scripted to add or modify a DT
property. I hadn't considered that, but you are probably right that
this is at least 90% of the systems you'd find in the wild today.
Thinking this a bit further, I wonder if (at least upstream) u-boot
has a way to modify DT properties in a scripted way that would allow
the direct property. It sounds like a generally useful feature not
just for randomness, so if that doesn't already work, maybe someone
can implement it. In the simplest case, you'd only need to find the
address of an existing property in the dtb and load a file to
that location.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-12 19:12 ` Arnd Bergmann
@ 2014-02-12 19:43 ` Jason Cooper
-1 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 19:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, devicetree, Laura Abbott, keescook,
linux-kernel, Rob Herring, Kumar Gala, Grant Likely
On Wed, Feb 12, 2014 at 08:12:23PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
> > On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> > > > I brought this up at last weeks devicetree irc meeting. My goal is to
> > > > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > > > the init script to save an additional random seed from /dev/urandom to
> > > > /boot/random-seed.
> > > >
> > > > The bootloader would then load this file into ram, and pass the
> > > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > > the decompressor) would consume some of this randomness, and then
> > > > random.c would consume the rest in a non-crediting initialization.
> > >
> > > I like the idea, but wouldn't it be easier to pass actual random data
> > > using DT, rather than the address/size?
> >
> > I thought about that at first, but that requires either that the
> > bootloader be upgraded to insert the data, or that userspace is
> > modifying the dtb at least twice per boot.
> >
> > I chose address/size to facilitate modifying existing/fielded devices.
> > The user could modify the dtb once, and modify the bootloader
> > environment to load X amount to Y address. As a fallback, it could be
> > expressed on the commandline for non-DT bootloaders.
>
> Ah, so you are interested in boot loaders that can be scripted to do
> what you had in mind but cannot be scripted to add or modify a DT
> property. I hadn't considered that, but you are probably right that
> this is at least 90% of the systems you'd find in the wild today.
Yes, exactly.
> Thinking this a bit further, I wonder if (at least upstream) u-boot
> has a way to modify DT properties in a scripted way that would allow
> the direct property. It sounds like a generally useful feature not
> just for randomness, so if that doesn't already work, maybe someone
> can implement it. In the simplest case, you'd only need to find the
> address of an existing property in the dtb and load a file to
> that location.
Like fdtget from dtc? The thing is, this address would only need to be
setup once per board. Hypothetically, debian's flash-kernel could set
the address in the dtb, then set it in the u-boot environment. From
then on, only the normal initscript writing to random-seed would be
needed.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 19:43 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 19:43 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 08:12:23PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
> > On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> > > > I brought this up at last weeks devicetree irc meeting. My goal is to
> > > > provide early randomness for kaslr on ARM. Currently, my idea is modify
> > > > the init script to save an additional random seed from /dev/urandom to
> > > > /boot/random-seed.
> > > >
> > > > The bootloader would then load this file into ram, and pass the
> > > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > > the decompressor) would consume some of this randomness, and then
> > > > random.c would consume the rest in a non-crediting initialization.
> > >
> > > I like the idea, but wouldn't it be easier to pass actual random data
> > > using DT, rather than the address/size?
> >
> > I thought about that at first, but that requires either that the
> > bootloader be upgraded to insert the data, or that userspace is
> > modifying the dtb at least twice per boot.
> >
> > I chose address/size to facilitate modifying existing/fielded devices.
> > The user could modify the dtb once, and modify the bootloader
> > environment to load X amount to Y address. As a fallback, it could be
> > expressed on the commandline for non-DT bootloaders.
>
> Ah, so you are interested in boot loaders that can be scripted to do
> what you had in mind but cannot be scripted to add or modify a DT
> property. I hadn't considered that, but you are probably right that
> this is at least 90% of the systems you'd find in the wild today.
Yes, exactly.
> Thinking this a bit further, I wonder if (at least upstream) u-boot
> has a way to modify DT properties in a scripted way that would allow
> the direct property. It sounds like a generally useful feature not
> just for randomness, so if that doesn't already work, maybe someone
> can implement it. In the simplest case, you'd only need to find the
> address of an existing property in the dtb and load a file to
> that location.
Like fdtget from dtc? The thing is, this address would only need to be
setup once per board. Hypothetically, debian's flash-kernel could set
the address in the dtb, then set it in the u-boot environment. From
then on, only the normal initscript writing to random-seed would be
needed.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-12 19:12 ` Arnd Bergmann
(?)
@ 2014-02-12 23:55 ` Rob Herring
-1 siblings, 0 replies; 71+ messages in thread
From: Rob Herring @ 2014-02-12 23:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Jason Cooper, devicetree, Laura Abbott,
Kees Cook, linux-kernel, Rob Herring, Kumar Gala, Grant Likely
On Wed, Feb 12, 2014 at 1:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
>> On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
>> > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
>> > > I brought this up at last weeks devicetree irc meeting. My goal is to
>> > > provide early randomness for kaslr on ARM. Currently, my idea is modify
>> > > the init script to save an additional random seed from /dev/urandom to
>> > > /boot/random-seed.
>> > >
>> > > The bootloader would then load this file into ram, and pass the
>> > > address/size to the kernel either via dt, or commandline. kaslr (run in
>> > > the decompressor) would consume some of this randomness, and then
>> > > random.c would consume the rest in a non-crediting initialization.
>> >
>> > I like the idea, but wouldn't it be easier to pass actual random data
>> > using DT, rather than the address/size?
>>
>> I thought about that at first, but that requires either that the
>> bootloader be upgraded to insert the data, or that userspace is
>> modifying the dtb at least twice per boot.
>>
>> I chose address/size to facilitate modifying existing/fielded devices.
>> The user could modify the dtb once, and modify the bootloader
>> environment to load X amount to Y address. As a fallback, it could be
>> expressed on the commandline for non-DT bootloaders.
>
> Ah, so you are interested in boot loaders that can be scripted to do
> what you had in mind but cannot be scripted to add or modify a DT
> property. I hadn't considered that, but you are probably right that
> this is at least 90% of the systems you'd find in the wild today.
>
> Thinking this a bit further, I wonder if (at least upstream) u-boot
> has a way to modify DT properties in a scripted way that would allow
> the direct property. It sounds like a generally useful feature not
> just for randomness, so if that doesn't already work, maybe someone
> can implement it. In the simplest case, you'd only need to find the
> address of an existing property in the dtb and load a file to
> that location.
You would be referring to the u-boot fdt command which can read and
set properties. Of course, like all u-boot commands, that may or may
not be enabled by a vendor's u-boot. :(
Rob
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 23:55 ` Rob Herring
0 siblings, 0 replies; 71+ messages in thread
From: Rob Herring @ 2014-02-12 23:55 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 1:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
>> On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
>> > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
>> > > I brought this up at last weeks devicetree irc meeting. My goal is to
>> > > provide early randomness for kaslr on ARM. Currently, my idea is modify
>> > > the init script to save an additional random seed from /dev/urandom to
>> > > /boot/random-seed.
>> > >
>> > > The bootloader would then load this file into ram, and pass the
>> > > address/size to the kernel either via dt, or commandline. kaslr (run in
>> > > the decompressor) would consume some of this randomness, and then
>> > > random.c would consume the rest in a non-crediting initialization.
>> >
>> > I like the idea, but wouldn't it be easier to pass actual random data
>> > using DT, rather than the address/size?
>>
>> I thought about that at first, but that requires either that the
>> bootloader be upgraded to insert the data, or that userspace is
>> modifying the dtb at least twice per boot.
>>
>> I chose address/size to facilitate modifying existing/fielded devices.
>> The user could modify the dtb once, and modify the bootloader
>> environment to load X amount to Y address. As a fallback, it could be
>> expressed on the commandline for non-DT bootloaders.
>
> Ah, so you are interested in boot loaders that can be scripted to do
> what you had in mind but cannot be scripted to add or modify a DT
> property. I hadn't considered that, but you are probably right that
> this is at least 90% of the systems you'd find in the wild today.
>
> Thinking this a bit further, I wonder if (at least upstream) u-boot
> has a way to modify DT properties in a scripted way that would allow
> the direct property. It sounds like a generally useful feature not
> just for randomness, so if that doesn't already work, maybe someone
> can implement it. In the simplest case, you'd only need to find the
> address of an existing property in the dtb and load a file to
> that location.
You would be referring to the u-boot fdt command which can read and
set properties. Of course, like all u-boot commands, that may or may
not be enabled by a vendor's u-boot. :(
Rob
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 23:55 ` Rob Herring
0 siblings, 0 replies; 71+ messages in thread
From: Rob Herring @ 2014-02-12 23:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laura Abbott, Kees Cook,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Kumar Gala,
Grant Likely
On Wed, Feb 12, 2014 at 1:12 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
>> On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
>> > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
>> > > I brought this up at last weeks devicetree irc meeting. My goal is to
>> > > provide early randomness for kaslr on ARM. Currently, my idea is modify
>> > > the init script to save an additional random seed from /dev/urandom to
>> > > /boot/random-seed.
>> > >
>> > > The bootloader would then load this file into ram, and pass the
>> > > address/size to the kernel either via dt, or commandline. kaslr (run in
>> > > the decompressor) would consume some of this randomness, and then
>> > > random.c would consume the rest in a non-crediting initialization.
>> >
>> > I like the idea, but wouldn't it be easier to pass actual random data
>> > using DT, rather than the address/size?
>>
>> I thought about that at first, but that requires either that the
>> bootloader be upgraded to insert the data, or that userspace is
>> modifying the dtb at least twice per boot.
>>
>> I chose address/size to facilitate modifying existing/fielded devices.
>> The user could modify the dtb once, and modify the bootloader
>> environment to load X amount to Y address. As a fallback, it could be
>> expressed on the commandline for non-DT bootloaders.
>
> Ah, so you are interested in boot loaders that can be scripted to do
> what you had in mind but cannot be scripted to add or modify a DT
> property. I hadn't considered that, but you are probably right that
> this is at least 90% of the systems you'd find in the wild today.
>
> Thinking this a bit further, I wonder if (at least upstream) u-boot
> has a way to modify DT properties in a scripted way that would allow
> the direct property. It sounds like a generally useful feature not
> just for randomness, so if that doesn't already work, maybe someone
> can implement it. In the simplest case, you'd only need to find the
> address of an existing property in the dtb and load a file to
> that location.
You would be referring to the u-boot fdt command which can read and
set properties. Of course, like all u-boot commands, that may or may
not be enabled by a vendor's u-boot. :(
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:20 ` Jason Gunthorpe
0 siblings, 0 replies; 71+ messages in thread
From: Jason Gunthorpe @ 2014-02-12 18:20 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, keescook, devicetree, Laura Abbott, linux-kernel,
Rob Herring, Kumar Gala, Grant Likely, linux-arm-kernel
On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
Sure is a neat idea, but I think in general it would probably be smart
to include the entire FDT blob in the early random pool, that way you
get MACs and other machine unique data too.
>From there it is a small step to encourage bootloaders to include
boot-time-variable data in the DT like like 'boot time of day', 'cycle
counter', 'random blob', etc.
Then you just need the bootloader to dump the random-seed file into a
DT property.
Or have the bootloader fetch randomness from any HWRNG it has a driver
for. (eg a TPM)
Jason
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:20 ` Jason Gunthorpe
0 siblings, 0 replies; 71+ messages in thread
From: Jason Gunthorpe @ 2014-02-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
Sure is a neat idea, but I think in general it would probably be smart
to include the entire FDT blob in the early random pool, that way you
get MACs and other machine unique data too.
>From there it is a small step to encourage bootloaders to include
boot-time-variable data in the DT like like 'boot time of day', 'cycle
counter', 'random blob', etc.
Then you just need the bootloader to dump the random-seed file into a
DT property.
Or have the bootloader fetch randomness from any HWRNG it has a driver
for. (eg a TPM)
Jason
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:20 ` Jason Gunthorpe
0 siblings, 0 replies; 71+ messages in thread
From: Jason Gunthorpe @ 2014-02-12 18:20 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, keescook-F7+t8E8rja9g9hUCZPvPmw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laura Abbott,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Kumar Gala,
Grant Likely, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume the rest in a non-crediting initialization.
Sure is a neat idea, but I think in general it would probably be smart
to include the entire FDT blob in the early random pool, that way you
get MACs and other machine unique data too.
>From there it is a small step to encourage bootloaders to include
boot-time-variable data in the DT like like 'boot time of day', 'cycle
counter', 'random blob', etc.
Then you just need the bootloader to dump the random-seed file into a
DT property.
Or have the bootloader fetch randomness from any HWRNG it has a driver
for. (eg a TPM)
Jason
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:51 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 18:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: devicetree, Laura Abbott, keescook, Arnd Bergmann, linux-kernel,
Rob Herring, Kumar Gala, Grant Likely, linux-arm-kernel
On Wed, Feb 12, 2014 at 11:20:00AM -0700, Jason Gunthorpe wrote:
> On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
>
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
>
> Sure is a neat idea, but I think in general it would probably be smart
> to include the entire FDT blob in the early random pool, that way you
> get MACs and other machine unique data too.
Sure.
> From there it is a small step to encourage bootloaders to include
> boot-time-variable data in the DT like like 'boot time of day', 'cycle
> counter', 'random blob', etc.
I like it.
> Then you just need the bootloader to dump the random-seed file into a
> DT property.
Yes, see my response to Arnd re the binding. I'm also interested in
making it easier for devices already in the field. iow, without
upgrading the bootloader.
> Or have the bootloader fetch randomness from any HWRNG it has a driver
> for. (eg a TPM)
Depends on who you're protecting against. I'd prefer to have that
called out as a separate blob in the DT so the kernel could decide
whether to trust it explicitly, or mix it like random.c already does
with RDRAND.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:51 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 18:51 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 11:20:00AM -0700, Jason Gunthorpe wrote:
> On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
>
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
>
> Sure is a neat idea, but I think in general it would probably be smart
> to include the entire FDT blob in the early random pool, that way you
> get MACs and other machine unique data too.
Sure.
> From there it is a small step to encourage bootloaders to include
> boot-time-variable data in the DT like like 'boot time of day', 'cycle
> counter', 'random blob', etc.
I like it.
> Then you just need the bootloader to dump the random-seed file into a
> DT property.
Yes, see my response to Arnd re the binding. I'm also interested in
making it easier for devices already in the field. iow, without
upgrading the bootloader.
> Or have the bootloader fetch randomness from any HWRNG it has a driver
> for. (eg a TPM)
Depends on who you're protecting against. I'd prefer to have that
called out as a separate blob in the DT so the kernel could decide
whether to trust it explicitly, or mix it like random.c already does
with RDRAND.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 18:51 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-12 18:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Laura Abbott,
keescook-F7+t8E8rja9g9hUCZPvPmw, Arnd Bergmann,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Kumar Gala,
Grant Likely, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Feb 12, 2014 at 11:20:00AM -0700, Jason Gunthorpe wrote:
> On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
>
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
>
> Sure is a neat idea, but I think in general it would probably be smart
> to include the entire FDT blob in the early random pool, that way you
> get MACs and other machine unique data too.
Sure.
> From there it is a small step to encourage bootloaders to include
> boot-time-variable data in the DT like like 'boot time of day', 'cycle
> counter', 'random blob', etc.
I like it.
> Then you just need the bootloader to dump the random-seed file into a
> DT property.
Yes, see my response to Arnd re the binding. I'm also interested in
making it easier for devices already in the field. iow, without
upgrading the bootloader.
> Or have the bootloader fetch randomness from any HWRNG it has a driver
> for. (eg a TPM)
Depends on who you're protecting against. I'd prefer to have that
called out as a separate blob in the DT so the kernel could decide
whether to trust it explicitly, or mix it like random.c already does
with RDRAND.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-12 18:20 ` Jason Gunthorpe
@ 2014-02-17 15:54 ` Grant Likely
-1 siblings, 0 replies; 71+ messages in thread
From: Grant Likely @ 2014-02-17 15:54 UTC (permalink / raw)
To: Jason Gunthorpe, Jason Cooper
Cc: Arnd Bergmann, keescook, devicetree, Laura Abbott, linux-kernel,
Rob Herring, Kumar Gala, linux-arm-kernel
On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
>
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
>
> Sure is a neat idea, but I think in general it would probably be smart
> to include the entire FDT blob in the early random pool, that way you
> get MACs and other machine unique data too.
I applied a patch that did exactly that (109b623629), and then reverted
it (b920ecc82) shortly thereafter because add_device_randomness() is
a rather slow function and FDTs can get large. I'd like to see someone
do a reasonable analysis on the cost of using an FDT for randomness
before I reapply a patch doing something similar. An awful lot of the
FDT data is not very random, but there are certainly portions of it that
are appropriate for the random pool.
g.
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-17 15:54 ` Grant Likely
0 siblings, 0 replies; 71+ messages in thread
From: Grant Likely @ 2014-02-17 15:54 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
>
> > The bootloader would then load this file into ram, and pass the
> > address/size to the kernel either via dt, or commandline. kaslr (run in
> > the decompressor) would consume some of this randomness, and then
> > random.c would consume the rest in a non-crediting initialization.
>
> Sure is a neat idea, but I think in general it would probably be smart
> to include the entire FDT blob in the early random pool, that way you
> get MACs and other machine unique data too.
I applied a patch that did exactly that (109b623629), and then reverted
it (b920ecc82) shortly thereafter because add_device_randomness() is
a rather slow function and FDTs can get large. I'd like to see someone
do a reasonable analysis on the cost of using an FDT for randomness
before I reapply a patch doing something similar. An awful lot of the
FDT data is not very random, but there are certainly portions of it that
are appropriate for the random pool.
g.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-17 15:54 ` Grant Likely
(?)
@ 2014-02-17 16:13 ` Arnd Bergmann
-1 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2014-02-17 16:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Grant Likely, Jason Gunthorpe, Jason Cooper, devicetree,
Laura Abbott, keescook, linux-kernel, Rob Herring, Kumar Gala
On Monday 17 February 2014 15:54:19 Grant Likely wrote:
> On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> > On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> >
> > > The bootloader would then load this file into ram, and pass the
> > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > the decompressor) would consume some of this randomness, and then
> > > random.c would consume the rest in a non-crediting initialization.
> >
> > Sure is a neat idea, but I think in general it would probably be smart
> > to include the entire FDT blob in the early random pool, that way you
> > get MACs and other machine unique data too.
>
> I applied a patch that did exactly that (109b623629), and then reverted
> it (b920ecc82) shortly thereafter because add_device_randomness() is
> a rather slow function and FDTs can get large. I'd like to see someone
> do a reasonable analysis on the cost of using an FDT for randomness
> before I reapply a patch doing something similar. An awful lot of the
> FDT data is not very random, but there are certainly portions of it that
> are appropriate for the random pool.
Could we use a faster hash function that scans the entire device tree and
then just feed the output of that into add_device_randomness? We probably
can't expect that there is a lot of entropy in the DT blob, so the
result wouldn't be all that different in terms of quality of the random
seed.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-17 16:13 ` Arnd Bergmann
0 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2014-02-17 16:13 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 17 February 2014 15:54:19 Grant Likely wrote:
> On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> > On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> >
> > > The bootloader would then load this file into ram, and pass the
> > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > the decompressor) would consume some of this randomness, and then
> > > random.c would consume the rest in a non-crediting initialization.
> >
> > Sure is a neat idea, but I think in general it would probably be smart
> > to include the entire FDT blob in the early random pool, that way you
> > get MACs and other machine unique data too.
>
> I applied a patch that did exactly that (109b623629), and then reverted
> it (b920ecc82) shortly thereafter because add_device_randomness() is
> a rather slow function and FDTs can get large. I'd like to see someone
> do a reasonable analysis on the cost of using an FDT for randomness
> before I reapply a patch doing something similar. An awful lot of the
> FDT data is not very random, but there are certainly portions of it that
> are appropriate for the random pool.
Could we use a faster hash function that scans the entire device tree and
then just feed the output of that into add_device_randomness? We probably
can't expect that there is a lot of entropy in the DT blob, so the
result wouldn't be all that different in terms of quality of the random
seed.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-17 16:13 ` Arnd Bergmann
0 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2014-02-17 16:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree, Laura Abbott, Jason Cooper, linux-kernel,
Jason Gunthorpe, Rob Herring, Kumar Gala, Grant Likely, keescook
On Monday 17 February 2014 15:54:19 Grant Likely wrote:
> On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> > On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> >
> > > The bootloader would then load this file into ram, and pass the
> > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > the decompressor) would consume some of this randomness, and then
> > > random.c would consume the rest in a non-crediting initialization.
> >
> > Sure is a neat idea, but I think in general it would probably be smart
> > to include the entire FDT blob in the early random pool, that way you
> > get MACs and other machine unique data too.
>
> I applied a patch that did exactly that (109b623629), and then reverted
> it (b920ecc82) shortly thereafter because add_device_randomness() is
> a rather slow function and FDTs can get large. I'd like to see someone
> do a reasonable analysis on the cost of using an FDT for randomness
> before I reapply a patch doing something similar. An awful lot of the
> FDT data is not very random, but there are certainly portions of it that
> are appropriate for the random pool.
Could we use a faster hash function that scans the entire device tree and
then just feed the output of that into add_device_randomness? We probably
can't expect that there is a lot of entropy in the DT blob, so the
result wouldn't be all that different in terms of quality of the random
seed.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-17 16:13 ` Arnd Bergmann
@ 2014-02-17 18:23 ` Jason Cooper
-1 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-17 18:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Grant Likely, Jason Gunthorpe, devicetree,
Laura Abbott, keescook, linux-kernel, Rob Herring, Kumar Gala
On Mon, Feb 17, 2014 at 05:13:07PM +0100, Arnd Bergmann wrote:
> On Monday 17 February 2014 15:54:19 Grant Likely wrote:
> > On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> > > On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> > >
> > > > The bootloader would then load this file into ram, and pass the
> > > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > > the decompressor) would consume some of this randomness, and then
> > > > random.c would consume the rest in a non-crediting initialization.
> > >
> > > Sure is a neat idea, but I think in general it would probably be smart
> > > to include the entire FDT blob in the early random pool, that way you
> > > get MACs and other machine unique data too.
> >
> > I applied a patch that did exactly that (109b623629), and then reverted
> > it (b920ecc82) shortly thereafter because add_device_randomness() is
> > a rather slow function and FDTs can get large. I'd like to see someone
> > do a reasonable analysis on the cost of using an FDT for randomness
> > before I reapply a patch doing something similar. An awful lot of the
> > FDT data is not very random, but there are certainly portions of it that
> > are appropriate for the random pool.
>
> Could we use a faster hash function that scans the entire device tree and
> then just feed the output of that into add_device_randomness? We probably
> can't expect that there is a lot of entropy in the DT blob, so the
> result wouldn't be all that different in terms of quality of the random
> seed.
I think it would be easier to identify the few attributes that differ
from board to board (mac address, serial number, etc), and differ from
boot to boot (random-seed, timestamp) and just extract and feed those
in.
We already have the fdt parsing code in the decompressor...
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-17 18:23 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-17 18:23 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 17, 2014 at 05:13:07PM +0100, Arnd Bergmann wrote:
> On Monday 17 February 2014 15:54:19 Grant Likely wrote:
> > On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> > > On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> > >
> > > > The bootloader would then load this file into ram, and pass the
> > > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > > the decompressor) would consume some of this randomness, and then
> > > > random.c would consume the rest in a non-crediting initialization.
> > >
> > > Sure is a neat idea, but I think in general it would probably be smart
> > > to include the entire FDT blob in the early random pool, that way you
> > > get MACs and other machine unique data too.
> >
> > I applied a patch that did exactly that (109b623629), and then reverted
> > it (b920ecc82) shortly thereafter because add_device_randomness() is
> > a rather slow function and FDTs can get large. I'd like to see someone
> > do a reasonable analysis on the cost of using an FDT for randomness
> > before I reapply a patch doing something similar. An awful lot of the
> > FDT data is not very random, but there are certainly portions of it that
> > are appropriate for the random pool.
>
> Could we use a faster hash function that scans the entire device tree and
> then just feed the output of that into add_device_randomness? We probably
> can't expect that there is a lot of entropy in the DT blob, so the
> result wouldn't be all that different in terms of quality of the random
> seed.
I think it would be easier to identify the few attributes that differ
from board to board (mac address, serial number, etc), and differ from
boot to boot (random-seed, timestamp) and just extract and feed those
in.
We already have the fdt parsing code in the decompressor...
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-17 18:23 ` Jason Cooper
(?)
@ 2014-02-17 21:07 ` Geert Uytterhoeven
-1 siblings, 0 replies; 71+ messages in thread
From: Geert Uytterhoeven @ 2014-02-17 21:07 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, linux-arm-kernel, Grant Likely, Jason Gunthorpe,
devicetree, Laura Abbott, Kees Cook, linux-kernel, Rob Herring,
Kumar Gala
On Mon, Feb 17, 2014 at 7:23 PM, Jason Cooper <jason@lakedaemon.net> wrote:
>> Could we use a faster hash function that scans the entire device tree and
>> then just feed the output of that into add_device_randomness? We probably
>> can't expect that there is a lot of entropy in the DT blob, so the
>> result wouldn't be all that different in terms of quality of the random
>> seed.
>
> I think it would be easier to identify the few attributes that differ
> from board to board (mac address, serial number, etc), and differ from
> boot to boot (random-seed, timestamp) and just extract and feed those
> in.
Isn't identifying those (mostly) a manual process?
Calculating a fast hash is fully automatic.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 71+ messages in thread* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-17 21:07 ` Geert Uytterhoeven
0 siblings, 0 replies; 71+ messages in thread
From: Geert Uytterhoeven @ 2014-02-17 21:07 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 17, 2014 at 7:23 PM, Jason Cooper <jason@lakedaemon.net> wrote:
>> Could we use a faster hash function that scans the entire device tree and
>> then just feed the output of that into add_device_randomness? We probably
>> can't expect that there is a lot of entropy in the DT blob, so the
>> result wouldn't be all that different in terms of quality of the random
>> seed.
>
> I think it would be easier to identify the few attributes that differ
> from board to board (mac address, serial number, etc), and differ from
> boot to boot (random-seed, timestamp) and just extract and feed those
> in.
Isn't identifying those (mostly) a manual process?
Calculating a fast hash is fully automatic.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-17 21:07 ` Geert Uytterhoeven
0 siblings, 0 replies; 71+ messages in thread
From: Geert Uytterhoeven @ 2014-02-17 21:07 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, linux-arm-kernel, Grant Likely, Jason Gunthorpe,
devicetree, Laura Abbott, Kees Cook, linux-kernel, Rob Herring,
Kumar Gala
On Mon, Feb 17, 2014 at 7:23 PM, Jason Cooper <jason@lakedaemon.net> wrote:
>> Could we use a faster hash function that scans the entire device tree and
>> then just feed the output of that into add_device_randomness? We probably
>> can't expect that there is a lot of entropy in the DT blob, so the
>> result wouldn't be all that different in terms of quality of the random
>> seed.
>
> I think it would be easier to identify the few attributes that differ
> from board to board (mac address, serial number, etc), and differ from
> boot to boot (random-seed, timestamp) and just extract and feed those
> in.
Isn't identifying those (mostly) a manual process?
Calculating a fast hash is fully automatic.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-18 17:56 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-18 17:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, linux-arm-kernel, Grant Likely, Jason Gunthorpe,
devicetree, Laura Abbott, Kees Cook, linux-kernel, Rob Herring,
Kumar Gala
On Mon, Feb 17, 2014 at 10:07:50PM +0100, Geert Uytterhoeven wrote:
> On Mon, Feb 17, 2014 at 7:23 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> >> Could we use a faster hash function that scans the entire device tree and
> >> then just feed the output of that into add_device_randomness? We probably
> >> can't expect that there is a lot of entropy in the DT blob, so the
> >> result wouldn't be all that different in terms of quality of the random
> >> seed.
> >
> > I think it would be easier to identify the few attributes that differ
> > from board to board (mac address, serial number, etc), and differ from
> > boot to boot (random-seed, timestamp) and just extract and feed those
> > in.
>
> Isn't identifying those (mostly) a manual process?
> Calculating a fast hash is fully automatic.
The list would be pretty short, and once created wouldn't likely change
too often. But it really depends on the 'fast hash'. if the two
methods have comparable speed, I'd definitely prefer the hash. Easier
to maintain.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-18 17:56 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-18 17:56 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 17, 2014 at 10:07:50PM +0100, Geert Uytterhoeven wrote:
> On Mon, Feb 17, 2014 at 7:23 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> >> Could we use a faster hash function that scans the entire device tree and
> >> then just feed the output of that into add_device_randomness? We probably
> >> can't expect that there is a lot of entropy in the DT blob, so the
> >> result wouldn't be all that different in terms of quality of the random
> >> seed.
> >
> > I think it would be easier to identify the few attributes that differ
> > from board to board (mac address, serial number, etc), and differ from
> > boot to boot (random-seed, timestamp) and just extract and feed those
> > in.
>
> Isn't identifying those (mostly) a manual process?
> Calculating a fast hash is fully automatic.
The list would be pretty short, and once created wouldn't likely change
too often. But it really depends on the 'fast hash'. if the two
methods have comparable speed, I'd definitely prefer the hash. Easier
to maintain.
thx,
Jason.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-18 17:56 ` Jason Cooper
0 siblings, 0 replies; 71+ messages in thread
From: Jason Cooper @ 2014-02-18 17:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Grant Likely, Jason Gunthorpe, devicetree-u79uwXL29TY76Z2rM5mHXA,
Laura Abbott, Kees Cook, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Kumar Gala
On Mon, Feb 17, 2014 at 10:07:50PM +0100, Geert Uytterhoeven wrote:
> On Mon, Feb 17, 2014 at 7:23 PM, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
> >> Could we use a faster hash function that scans the entire device tree and
> >> then just feed the output of that into add_device_randomness? We probably
> >> can't expect that there is a lot of entropy in the DT blob, so the
> >> result wouldn't be all that different in terms of quality of the random
> >> seed.
> >
> > I think it would be easier to identify the few attributes that differ
> > from board to board (mac address, serial number, etc), and differ from
> > boot to boot (random-seed, timestamp) and just extract and feed those
> > in.
>
> Isn't identifying those (mostly) a manual process?
> Calculating a fast hash is fully automatic.
The list would be pretty short, and once created wouldn't likely change
too often. But it really depends on the 'fast hash'. if the two
methods have comparable speed, I'd definitely prefer the hash. Easier
to maintain.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-17 16:13 ` Arnd Bergmann
(?)
@ 2014-02-18 9:39 ` Grant Likely
-1 siblings, 0 replies; 71+ messages in thread
From: Grant Likely @ 2014-02-18 9:39 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: Jason Gunthorpe, Jason Cooper, devicetree, Laura Abbott,
keescook, linux-kernel, Rob Herring, Kumar Gala
On Mon, 17 Feb 2014 17:13:07 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 17 February 2014 15:54:19 Grant Likely wrote:
> > On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> > > On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> > >
> > > > The bootloader would then load this file into ram, and pass the
> > > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > > the decompressor) would consume some of this randomness, and then
> > > > random.c would consume the rest in a non-crediting initialization.
> > >
> > > Sure is a neat idea, but I think in general it would probably be smart
> > > to include the entire FDT blob in the early random pool, that way you
> > > get MACs and other machine unique data too.
> >
> > I applied a patch that did exactly that (109b623629), and then reverted
> > it (b920ecc82) shortly thereafter because add_device_randomness() is
> > a rather slow function and FDTs can get large. I'd like to see someone
> > do a reasonable analysis on the cost of using an FDT for randomness
> > before I reapply a patch doing something similar. An awful lot of the
> > FDT data is not very random, but there are certainly portions of it that
> > are appropriate for the random pool.
>
> Could we use a faster hash function that scans the entire device tree and
> then just feed the output of that into add_device_randomness? We probably
> can't expect that there is a lot of entropy in the DT blob, so the
> result wouldn't be all that different in terms of quality of the random
> seed.
>
> Arnd
Yes, I think that is a good solution.
g.
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-18 9:39 ` Grant Likely
0 siblings, 0 replies; 71+ messages in thread
From: Grant Likely @ 2014-02-18 9:39 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 17 Feb 2014 17:13:07 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 17 February 2014 15:54:19 Grant Likely wrote:
> > On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> > > On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> > >
> > > > The bootloader would then load this file into ram, and pass the
> > > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > > the decompressor) would consume some of this randomness, and then
> > > > random.c would consume the rest in a non-crediting initialization.
> > >
> > > Sure is a neat idea, but I think in general it would probably be smart
> > > to include the entire FDT blob in the early random pool, that way you
> > > get MACs and other machine unique data too.
> >
> > I applied a patch that did exactly that (109b623629), and then reverted
> > it (b920ecc82) shortly thereafter because add_device_randomness() is
> > a rather slow function and FDTs can get large. I'd like to see someone
> > do a reasonable analysis on the cost of using an FDT for randomness
> > before I reapply a patch doing something similar. An awful lot of the
> > FDT data is not very random, but there are certainly portions of it that
> > are appropriate for the random pool.
>
> Could we use a faster hash function that scans the entire device tree and
> then just feed the output of that into add_device_randomness? We probably
> can't expect that there is a lot of entropy in the DT blob, so the
> result wouldn't be all that different in terms of quality of the random
> seed.
>
> Arnd
Yes, I think that is a good solution.
g.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-18 9:39 ` Grant Likely
0 siblings, 0 replies; 71+ messages in thread
From: Grant Likely @ 2014-02-18 9:39 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Jason Gunthorpe, Jason Cooper, devicetree-u79uwXL29TY76Z2rM5mHXA,
Laura Abbott, keescook-F7+t8E8rja9g9hUCZPvPmw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Kumar Gala
On Mon, 17 Feb 2014 17:13:07 +0100, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Monday 17 February 2014 15:54:19 Grant Likely wrote:
> > On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> > > On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> > >
> > > > The bootloader would then load this file into ram, and pass the
> > > > address/size to the kernel either via dt, or commandline. kaslr (run in
> > > > the decompressor) would consume some of this randomness, and then
> > > > random.c would consume the rest in a non-crediting initialization.
> > >
> > > Sure is a neat idea, but I think in general it would probably be smart
> > > to include the entire FDT blob in the early random pool, that way you
> > > get MACs and other machine unique data too.
> >
> > I applied a patch that did exactly that (109b623629), and then reverted
> > it (b920ecc82) shortly thereafter because add_device_randomness() is
> > a rather slow function and FDTs can get large. I'd like to see someone
> > do a reasonable analysis on the cost of using an FDT for randomness
> > before I reapply a patch doing something similar. An awful lot of the
> > FDT data is not very random, but there are certainly portions of it that
> > are appropriate for the random pool.
>
> Could we use a faster hash function that scans the entire device tree and
> then just feed the output of that into add_device_randomness? We probably
> can't expect that there is a lot of entropy in the DT blob, so the
> result wouldn't be all that different in terms of quality of the random
> seed.
>
> Arnd
Yes, I think that is a good solution.
g.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-17 15:54 ` Grant Likely
@ 2014-02-18 18:19 ` Jason Gunthorpe
-1 siblings, 0 replies; 71+ messages in thread
From: Jason Gunthorpe @ 2014-02-18 18:19 UTC (permalink / raw)
To: Grant Likely
Cc: Jason Cooper, Arnd Bergmann, keescook, devicetree, Laura Abbott,
linux-kernel, Rob Herring, Kumar Gala, linux-arm-kernel
On Mon, Feb 17, 2014 at 03:54:19PM +0000, Grant Likely wrote:
> I applied a patch that did exactly that (109b623629), and then reverted
> it (b920ecc82) shortly thereafter because add_device_randomness() is
> a rather slow function and FDTs can get large. I'd like to see someone
> do a reasonable analysis on the cost of using an FDT for randomness
> before I reapply a patch doing something similar. An awful lot of the
> FDT data is not very random, but there are certainly portions of it that
> are appropriate for the random pool.
I read through the original thread from Tim Bird and FWIW I agree with
the assessment that passing the FDT through MD5 first is a good
approach.
Thinking into the future, I'd expect to see similar variable data in
DT on servers as we see in DMI, including:
- Vendor serial number for the HW, manufacturing date, model number,
and HW UUID
- Serial numbers and vendor part numbers for DIMMS
- MAC addresses for all the ethernet
- OEM specific data
At worst a 'choosen/linux,no-dt-random = 1' value in the DT to disable
it would solve the problem for those in embedded that care about
microseconds during booting.
Regards,
Jason
^ permalink raw reply [flat|nested] 71+ messages in thread* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-18 18:19 ` Jason Gunthorpe
0 siblings, 0 replies; 71+ messages in thread
From: Jason Gunthorpe @ 2014-02-18 18:19 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Feb 17, 2014 at 03:54:19PM +0000, Grant Likely wrote:
> I applied a patch that did exactly that (109b623629), and then reverted
> it (b920ecc82) shortly thereafter because add_device_randomness() is
> a rather slow function and FDTs can get large. I'd like to see someone
> do a reasonable analysis on the cost of using an FDT for randomness
> before I reapply a patch doing something similar. An awful lot of the
> FDT data is not very random, but there are certainly portions of it that
> are appropriate for the random pool.
I read through the original thread from Tim Bird and FWIW I agree with
the assessment that passing the FDT through MD5 first is a good
approach.
Thinking into the future, I'd expect to see similar variable data in
DT on servers as we see in DMI, including:
- Vendor serial number for the HW, manufacturing date, model number,
and HW UUID
- Serial numbers and vendor part numbers for DIMMS
- MAC addresses for all the ethernet
- OEM specific data
At worst a 'choosen/linux,no-dt-random = 1' value in the DT to disable
it would solve the problem for those in embedded that care about
microseconds during booting.
Regards,
Jason
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
2014-02-12 17:45 ` Jason Cooper
(?)
@ 2014-02-12 21:35 ` Kees Cook
-1 siblings, 0 replies; 71+ messages in thread
From: Kees Cook @ 2014-02-12 21:35 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, Laura Abbott, Grant Likely, Rob Herring, LKML,
devicetree, linux-arm-kernel, Kumar Gala
On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
I'm all for a good entropy source for early boot. :)
I need to figure out what's needed for relocation support first
though, before we can really tackle kernel base-address randomization
on ARM. I haven't had a chance to look around too closely yet, but it
seems like only x86 and ppc do this currently? Has anyone looked in
detail and what would be needed on ARM for CONFIG_RELOCATABLE
behavior?
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 71+ messages in thread
* [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 21:35 ` Kees Cook
0 siblings, 0 replies; 71+ messages in thread
From: Kees Cook @ 2014-02-12 21:35 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
I'm all for a good entropy source for early boot. :)
I need to figure out what's needed for relocation support first
though, before we can really tackle kernel base-address randomization
on ARM. I haven't had a chance to look around too closely yet, but it
seems like only x86 and ppc do this currently? Has anyone looked in
detail and what would be needed on ARM for CONFIG_RELOCATABLE
behavior?
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [RFC/PATCH 0/3] Add devicetree scanning for randomness
@ 2014-02-12 21:35 ` Kees Cook
0 siblings, 0 replies; 71+ messages in thread
From: Kees Cook @ 2014-02-12 21:35 UTC (permalink / raw)
To: Jason Cooper
Cc: Arnd Bergmann, Laura Abbott, Grant Likely, Rob Herring, LKML,
devicetree, linux-arm-kernel, Kumar Gala
On Wed, Feb 12, 2014 at 9:45 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed.
I'm all for a good entropy source for early boot. :)
I need to figure out what's needed for relocation support first
though, before we can really tackle kernel base-address randomization
on ARM. I haven't had a chance to look around too closely yet, but it
seems like only x86 and ppc do this currently? Has anyone looked in
detail and what would be needed on ARM for CONFIG_RELOCATABLE
behavior?
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 71+ messages in thread