> On Sep 20, 2019, at 11:15 AM, Alexander E. Patrakov <patrakov@xxxxxxxxx> wrote: > > 20.09.2019 22:52, Andy Lutomirski пишет: >> I think that, given existing software, we should make two or three >> changes to fix the basic problems here: >> 1. Add GRND_INSECURE: at least let new applications do the right thing >> going forward. >> 2. Fix what is arguably a straight up kernel bug, not even an ABI >> issue: when a user program is blocking in getrandom(..., 0), the >> kernel happily sits there doing absolutely nothing and deadlocks the >> system as a result. This IMO isn't an ABI issue -- it's an >> implementation problem. How about we make getrandom() (probably >> actually wait_for_random_bytes()) do something useful to try to seed >> the RNG if the system is otherwise not doing IO. >> 3. Optionally, entirely in user code: Get glibc to add new *library* >> functions: getentropy_secure_blocking() and getentropy_insecure() or >> whatever they want to call them. Deprecate getentropy(). >> I think #2 is critical. Right now, suppose someone has a system that >> neets to do a secure network request (a la Red Hat's Clevis). I have >> no idea what Clevis actually does, but it wouldn't be particularly >> crazy to do a DH exchange or sign with an EC key to ask some network >> server to help unlock a dm-crypt volume. If the system does this at >> boot, it needs to use getrandom(..., 0), GRND_EXPLICIT, or whatever, >> because it NEEDS a secure random number. No about of ABI fiddling >> will change this. The kernel should *work* in this case rather than >> deadlocking. > > Let me express a little bit of disagreement with the logic here. > > I do agree that #2 is critical, and the Clevis use case is a perfect example why it is important. I doubt that it is solvable without trusting jitter entropy, or without provoking a dummy read on a random block device, just for timings, or maybe some other interaction with the external world - but Willy already said "it seems fishy". However, _if_ it is solved, then we don't need GRND_INSECURE, because solving #2 is equivalent to magically making secure random numbers always available. > > I beg to differ. There is a big difference between “do your best *right now*” and “give me a real secure result in a vaguely timely manner”. For example, the former is useful for ASLR or hash table randomization. The latter is not.
