From: Andy Lutomirski <luto@amacapital.net>
To: musl@lists.openwall.com
Subject: Re: magic constants in some startup code
Date: Sun, 02 Nov 2014 11:10:54 -0800 [thread overview]
Message-ID: <545681BE.1080808@amacapital.net> (raw)
In-Reply-To: <20141102171700.GJ10829@port70.net>
On 11/02/2014 09:17 AM, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.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
prev parent reply other threads:[~2014-11-02 19:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-31 13:31 Richard Gorton
2014-10-31 14:18 ` Rich Felker
2014-10-31 14:31 ` Richard Gorton
2014-10-31 16:09 ` Rich Felker
2014-10-31 20:19 ` Andy Lutomirski
2014-10-31 21:05 ` Rich Felker
2014-10-31 21:29 ` Andy Lutomirski
2014-10-31 21:39 ` Rich Felker
2014-10-31 22:27 ` Andy Lutomirski
2014-10-31 23:14 ` Rich Felker
2014-11-02 17:17 ` Szabolcs Nagy
2014-11-02 19:10 ` Andy Lutomirski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545681BE.1080808@amacapital.net \
--to=luto@amacapital.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).