/dev/urandom

/dev/urandom

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 174 bytes --]

Hi,

u-boot tools/sunxi-spl-image-builder.c reads from /dev/urandom .

For reproducibility I'd like this to be a static file.  Do we already have one
for this purpose?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: /dev/urandom

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

On Tue, Jul 10, 2018 at 06:22:11PM +0200, Danny Milosavljevic wrote:
> Hi,
> 
> u-boot tools/sunxi-spl-image-builder.c reads from /dev/urandom .
> 
> For reproducibility I'd like this to be a static file.  Do we already have one
> for this purpose?

You could use /dev/zero. What does the program do with the random data?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: /dev/urandom

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> u-boot tools/sunxi-spl-image-builder.c reads from /dev/urandom .
>
> For reproducibility I'd like this to be a static file.  Do we already have one
> for this purpose?

I think it would be better to patch software as needed to avoid trying
to generate random numbers in specific places, mainly because it would
force us to always be aware of what the random numbers are being used
for, so that we can evaluate the potential security implications.

If we simply make /dev/urandom deterministic, then we will not be in the
position to know what the (non)random numbers are being used for, and we
run the risk of introducing serious security issues.

Note that it would not be sufficient to audit the software once to see
what the random numbers were being used for, because future versions of
the software might add additional uses for random numbers.  If that ever
happens, then the difference between the two approaches will become
important.

If we make /dev/urandom deterministic, then new uses for random numbers
introduced in future versions will be *automatically* made non-random,
and we might not notice.  On the other hand, if we patch out specific
uses of randomness, then new uses for randomness will be left intact
until we add patches for them.  This is as it should be, I think.

What do you think?

      Mark

Re: /dev/urandom

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

Hi Leo,

On Tue, 10 Jul 2018 14:28:09 -0400
Leo Famulari <leo@famulari.name> wrote:

> On Tue, Jul 10, 2018 at 06:22:11PM +0200, Danny Milosavljevic wrote:
> > Hi,
> > 
> > u-boot tools/sunxi-spl-image-builder.c reads from /dev/urandom .
> > 
> > For reproducibility I'd like this to be a static file.  Do we already have one
> > for this purpose?  
> 
> You could use /dev/zero. What does the program do with the random data?

It writes an image file.  Since that image is later written to flash storage
(by the user), the program randomizes the data in order to increase longevity.
Then it stores the random data used as well.

See http://soc.yonsei.ac.kr/Abstract/International_journal/pdf/106_Data%20Randomization%20Scheme%20for%20Endurance%20Enhancement%20and%20Interference%20Mitigation%20of%20Multilevel%20Flash%20Memory%20Devices.pdf

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: /dev/urandom

[Ludovic Courtès]

Hello Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> u-boot tools/sunxi-spl-image-builder.c reads from /dev/urandom .
>
> For reproducibility I'd like this to be a static file.  Do we already have one
> for this purpose?

I’d be wary of introducing a static /dev/urandom.  It could do more than
we want, or we could leave it around in places where it shouldn’t be.

For reproducibility purposes, (gnu system vm) precomputes file system
UUIDs, for instance, instead of letting them be computed as a function
of /dev/urandom.  Dunno if a similar technique could be used here.

Otherwise, what about patching U-Boot so that the file above honors and
environment variable or something that would allow us to specify a seed?

Ludo’.

Re: /dev/urandom

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

On Tue, Jul 10, 2018 at 08:58:43PM +0200, Danny Milosavljevic wrote:
> It writes an image file.  Since that image is later written to flash storage
> (by the user), the program randomizes the data in order to increase longevity.
> Then it stores the random data used as well.

I see. Like Ludo and Mark, I think we should avoid doing tricky things
with urandom.

Could /dev/zero work here? Does it use urandom once, to get a seed, or
does it read urandom repeatedly, expecting different values each time?

Also, I wonder if Guix users would want reproducibility here instead of
longer-lived NAND storage.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: /dev/urandom

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

Hi Mark,

those are all good points.

In this specific case the randomness is necessary for NAND wear levelling,
so getting rid of it isn't good anyhow.

I'll investigate whether there is a way to defer invocation of
the randomizer so that the user can invoke it in the installed package.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: /dev/urandom

[Vincent Legoll]

On Wed, Jul 11, 2018 at 4:17 PM, Danny Milosavljevic
<dannym@scratchpost.org> wrote:
> the randomness is necessary for NAND wear levelling,

Any pointers about that subject ?

This looks strange as I'd have thought that less writes => less wear.

-- 
Vincent Legoll

Re: /dev/urandom

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

Hi Vincent,

On Wed, 11 Jul 2018 17:07:02 +0200
Vincent Legoll <vincent.legoll@gmail.com> wrote:

> On Wed, Jul 11, 2018 at 4:17 PM, Danny Milosavljevic
> <dannym@scratchpost.org> wrote:
> > the randomness is necessary for NAND wear levelling,  
> 
> Any pointers about that subject ?

http://soc.yonsei.ac.kr/Abstract/International_journal/pdf/106_Data%20Randomization%20Scheme%20for%20Endurance%20Enhancement%20and%20Interference%20Mitigation%20of%20Multilevel%20Flash%20Memory%20Devices.pdf

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: /dev/urandom

[Vincent Legoll]

Hello,

On Wed, Jul 11, 2018 at 5:50 PM, Danny Milosavljevic
<dannym@scratchpost.org> wrote:
> http://soc.yonsei.ac.kr/Abstract/International_journal/pdf/106_Data%20Randomization%20Scheme%20for%20Endurance%20Enhancement%20and%20Interference%20Mitigation%20of%20Multilevel%20Flash%20Memory%20Devices.pdf

Thanks a lot

I didn't understand everything in there, but sufficiently to sleep
a bit less stupid tonight...

I think it boils down to that: this random data mitigates errors
that are due to cell content interferences. I don't think it is directly
related to cells wear.

Do you concur ?

-- 
Vincent Legoll