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.