lkml.org 
[lkml]   [2019]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2()
From
Date
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.

--
Alexander E. Patrakov

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2019-09-20 20:15    [W:0.153 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site