unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* /dev/urandom
@ 2018-07-10 16:22 Danny Milosavljevic
  2018-07-10 18:28 ` /dev/urandom Leo Famulari
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Danny Milosavljevic @ 2018-07-10 16:22 UTC (permalink / raw)
  To: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/urandom
  2018-07-10 16:22 /dev/urandom Danny Milosavljevic
@ 2018-07-10 18:28 ` Leo Famulari
  2018-07-10 18:58   ` /dev/urandom Danny Milosavljevic
  2018-07-10 18:43 ` /dev/urandom Mark H Weaver
  2018-07-10 22:18 ` /dev/urandom Ludovic Courtès
  2 siblings, 1 reply; 10+ messages in thread
From: Leo Famulari @ 2018-07-10 18:28 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/urandom
  2018-07-10 16:22 /dev/urandom Danny Milosavljevic
  2018-07-10 18:28 ` /dev/urandom Leo Famulari
@ 2018-07-10 18:43 ` Mark H Weaver
  2018-07-11 14:17   ` /dev/urandom Danny Milosavljevic
  2018-07-10 22:18 ` /dev/urandom Ludovic Courtès
  2 siblings, 1 reply; 10+ messages in thread
From: Mark H Weaver @ 2018-07-10 18:43 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/urandom
  2018-07-10 18:28 ` /dev/urandom Leo Famulari
@ 2018-07-10 18:58   ` Danny Milosavljevic
  2018-07-10 22:40     ` /dev/urandom Leo Famulari
  0 siblings, 1 reply; 10+ messages in thread
From: Danny Milosavljevic @ 2018-07-10 18:58 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/urandom
  2018-07-10 16:22 /dev/urandom Danny Milosavljevic
  2018-07-10 18:28 ` /dev/urandom Leo Famulari
  2018-07-10 18:43 ` /dev/urandom Mark H Weaver
@ 2018-07-10 22:18 ` Ludovic Courtès
  2 siblings, 0 replies; 10+ messages in thread
From: Ludovic Courtès @ 2018-07-10 22:18 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: guix-devel

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’.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/urandom
  2018-07-10 18:58   ` /dev/urandom Danny Milosavljevic
@ 2018-07-10 22:40     ` Leo Famulari
  0 siblings, 0 replies; 10+ messages in thread
From: Leo Famulari @ 2018-07-10 22:40 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/urandom
  2018-07-10 18:43 ` /dev/urandom Mark H Weaver
@ 2018-07-11 14:17   ` Danny Milosavljevic
  2018-07-11 15:07     ` /dev/urandom Vincent Legoll
  0 siblings, 1 reply; 10+ messages in thread
From: Danny Milosavljevic @ 2018-07-11 14:17 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/urandom
  2018-07-11 14:17   ` /dev/urandom Danny Milosavljevic
@ 2018-07-11 15:07     ` Vincent Legoll
  2018-07-11 15:50       ` /dev/urandom Danny Milosavljevic
  0 siblings, 1 reply; 10+ messages in thread
From: Vincent Legoll @ 2018-07-11 15:07 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/urandom
  2018-07-11 15:07     ` /dev/urandom Vincent Legoll
@ 2018-07-11 15:50       ` Danny Milosavljevic
  2018-07-11 16:34         ` /dev/urandom Vincent Legoll
  0 siblings, 1 reply; 10+ messages in thread
From: Danny Milosavljevic @ 2018-07-11 15:50 UTC (permalink / raw)
  To: Vincent Legoll; +Cc: guix-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: /dev/urandom
  2018-07-11 15:50       ` /dev/urandom Danny Milosavljevic
@ 2018-07-11 16:34         ` Vincent Legoll
  0 siblings, 0 replies; 10+ messages in thread
From: Vincent Legoll @ 2018-07-11 16:34 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2018-07-11 16:34 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-07-10 16:22 /dev/urandom Danny Milosavljevic
2018-07-10 18:28 ` /dev/urandom Leo Famulari
2018-07-10 18:58   ` /dev/urandom Danny Milosavljevic
2018-07-10 22:40     ` /dev/urandom Leo Famulari
2018-07-10 18:43 ` /dev/urandom Mark H Weaver
2018-07-11 14:17   ` /dev/urandom Danny Milosavljevic
2018-07-11 15:07     ` /dev/urandom Vincent Legoll
2018-07-11 15:50       ` /dev/urandom Danny Milosavljevic
2018-07-11 16:34         ` /dev/urandom Vincent Legoll
2018-07-10 22:18 ` /dev/urandom Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).