[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141102171700.GJ10829@port70.net>
Date: Sun, 2 Nov 2014 18:17:01 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Re: magic constants in some startup code
* Rich Felker <dalias@...c.org> [2014-10-31 19:14:58 -0400]:
> On Fri, Oct 31, 2014 at 03:27:37PM -0700, Andy Lutomirski wrote:
> > > Is best-effort ever useful? My feeling is that either you need
> > > cryptographic quality entropy, in which case it's not acceptable to
> > > get something fake, or you don't, in which case you can use something
> > > like the clock. Maybe I'm misunderstanding what you mean by
> > > best-effort. My impression was that getrandom was equivalent to
> > > /dev/urandom, not the tin-foil-hattery that is /dev/random.
> >
> > The clock really sucks for entropy. There are systems on which it's
> > entirely plausible that two different processes will start in rapid
> > succession and get exactly the same value out of the clock.
>
> Are you sure? AFAIK Linux has at least microsecond resolution on all
> major archs and nanosecond on x86 and some other important ones, and
> fork takes over 1000ns and exec a lot more still. So I don't see how
> you could get duplicates.
>
i'm interested in why clock might be bad source of entropy too
(it is not usable for key generation and there are some devices with
broken clock, but otherwise it should be a good source to avoid collisions
in some name space)
> > The problems with AT_RANDOM and with getrandom(2) involve early boot.
> > Newer kernels (especially on ARM, apparently) can boot quickly enough
> > that the RNG is in terribly shape when userspace starts. AT_RANDOM will
> > contain something, regardless, but it might have rather little entropy.
> > getrandom(2) will refuse to operate at all until the kernel thinks it
> > has 128 bits or so of entropy.
> >
> > So, if you want entropy at process start, AT_RANDOM is the best you can
> > do. But you should seed a per-process csprng with it if you can avoid
> > it, or at least you should reseed with getrandom, since the kernel RNG
> > will eventually end up being cryptographically secure.
> >
> > IOW, there isn't really a great solution here.
>
> Well, this sounds like a good reason not to have code that depends on
> entropy in pid 1.... :-)
>
> Maybe there are situations here where you'd want best-effort, but I
> can't think of any except initializing the stack protector canary
> (which already uses AT_RANDOM) for init or other very-early processes
> which should not be exposed to any input, much less untrusted input.
> And on a machine with insufficient initial entropy, the first thing
> the init sequence does should be getting the hardware to get you some
> entropy, no?
>
if early boot here means init then i dont think it's reasonable to assume
good entropy at that point
anyway entropy quality should not be libc resposibility at all, libc uses
whatever the kernel gives
it used to be infeasible to get new entropy from the kernel on demand
without introducing difficult to handle failure paths, but in new kernels
eg the temp file name generation could easily use getrandom and then the
quailty is kernel side issue
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
