[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 02 Nov 2014 11:10:54 -0800
From: Andy Lutomirski <luto@...capital.net>
To: musl@...ts.openwall.com
Subject: Re: magic constants in some startup code
On 11/02/2014 09:17 AM, Szabolcs Nagy wrote:
> * 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)
I don't know the details, but I've heard of this being a real problem on
MIPS routers, for example.
>
>>> 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
>
Actually, temp file name generation is probably a decent example of
wanting best effort. And getrandom either blocks or fails in very early
boot.
--Andy
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.
