lkml.org 
[lkml]   [2019]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Linux 5.3-rc8
    From
    Date
    16.09.2019 22:21, Theodore Y. Ts'o пишет:
    > On Mon, Sep 16, 2019 at 09:17:10AM -0700, Linus Torvalds wrote:
    >> So the semantics that getrandom() should have had are:
    >>
    >> getrandom(0) - just give me reasonable random numbers for any of a
    >> million non-strict-long-term-security use (ie the old urandom)
    >>
    >> - the nonblocking flag makes no sense here and would be a no-op
    >
    > That change is what I consider highly problematic. There are a *huge*
    > number of applications which use cryptography which assumes that
    > getrandom(0) means, "I'm guaranteed to get something safe
    > cryptographic use". Changing his now would expose a very large number
    > of applications to be insecure. Part of the problem here is that
    > there are many different actors. There is the application or
    > cryptographic library developer, who may want to be sure they have
    > cryptographically secure random numbers. They are the ones who will
    > select getrandom(0).
    >
    > Then you have the distribution or consumer-grade electronics
    > developers who may choose to run them too early in some init script or
    > systemd unit files. And some of these people may do something stupid,
    > like run things too early, or omit the a hardware random number
    > generator in their design, even though it's for a security critical
    > purpose (say, a digital wallet for bitcoin). Because some of these
    > people might do something stupid, one argument (not mine) is that we
    > must therefore not let getrandom() block. But doing this penalizes
    > the security of all the users of the application, not just the stupid
    > ones.

    On Linux, there is no such thing as "too early", that's the problem.

    First, we already had one lesson about this, regarding applications that
    require libraries from /usr. There, it was due to various programs that
    run from udev rules, and dynamic/unpredictable dependencies. See
    https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/,
    almost all arguments from there apply 1:1 here.

    Second, people/distributions put unexpected stuff into their initramfs
    images, and we cannot say that they have no right to do so. E.g., on my
    system that's "cryptsetup" that unlocks the root partition, but manages
    to read a few bytes of uninitialized urandom before that. A warning here
    is almost unavoidable, and thus will be treated as SPAM.

    No such considerations apply to OpenBSD (initramfs does not exist, and
    there is no equivalent of udev that reacts to cold-plug events by
    running programs), that's why the getentropy() design works there.

    If we were to fix it, we should focus on making true entropy available
    unconditionally, even before /init in the initramfs starts, and warn not
    on the first access to urandom, but on the exec of /init. Look -
    distributions are already running "haveged" which harvests entropy from
    clock jitter. And they still manage to do it wrong (regardless whether
    the "haveged" idea is wrong by itself), by running it too late (at least
    I don't know any kind of stock initramfs with either it or rngd
    included). So it's too complex, and needs to be simplified.

    The kernel already has jitterentropy-rng, it uses the same idea as
    "haveged", but, alas, it is exposed as a crypto rng algorithm, not a
    hwrng. And I think it is a bug: cryptoapi rng algorithms are for things
    that get a seed and generate random numbers by rehashing it over and
    over, while jitterentropy-rng requires no seed. Would a patch be
    accepted to convert it to hwrng? (this is essentially the reverse of
    what commit c46ea13 did for exynos-rng)

    >
    >> getrandom(GRND_RANDOM) - get me actual _secure_ random numbers with
    >> blocking until entropy pool fills (but not the completely invalid
    >> entropy decrease accounting)
    >>
    >> - the nonblocking flag is useful for bootup and for "I will
    >> actually try to generate entropy".
    >>
    >> and both of those are very very sensible actions. That would actually
    >> have _fixed_ the problems we had with /dev/[u]random, both from a
    >> performance standpoint and for a filesystem access standpoint.
    >>
    >> But that is sadly not what we have right now.
    >>
    >> And I suspect we can't fix it, since people have grown to depend on
    >> the old behavior, and already know to avoid GRND_RANDOM because it's
    >> useless with old kernels even if we fixed it with new ones.
    >
    > I don't think we can fix it, because it's the changing of
    > getrandom(0)'s behavior which is the problem, not GRND_RANDOM. People
    > *expect* getrandom(0) to always return secure results. I don't think
    > we can make it sometimes return not-necessarily secure results
    > depending on when the systems integrator or distribution decides to
    > run the application, and depending on the hardware platform (yes,
    > traditional x86 systems are probably fine, and fortunately x86
    > embedded CPU are too expensive and have lousy power management, so no
    > one really uses x86 for embedded yet, despite Intel's best efforts).
    > That would just be a purely irresponsible thing to do, IMO.
    >
    >> Does anybody really seriously debate the above? Ted? Are you seriously
    >> trying to claim that the existing GRND_RANDOM has any sensible use?
    >> Are you seriously trying to claim that the fact that we don't have a
    >> sane urandom source is a "feature"?
    >
    > There are people who can debate that GRND_RANDOM has any sensible use
    > cases. GPG uses /dev/random, and that was a fully informed choice.
    > I'm not convinced, because I think that at least for now the CRNG is
    > perfectly fine for 99.999% of the use cases. Yes, in a post-quantum
    > cryptography world, the CRNG might be screwed --- but so will most of
    > the other cryptographic algorithms in the kernel. So if anyone ever
    > gets post-quantum cryptoanalytic attacks working, the use of the CRNG
    > is going to be least of our problems.
    >
    > As I mentioned to you in Lisbon, I've been going back and forth about
    > whether or not to rip out the entire /dev/random infrastructure,
    > mainly for code maintainability reasons. The only reason why I've
    > been holding back is because there are (very few) non-insane people
    > who do want to use it. There are also a much larger of rational
    > people who use it because they want some insane PCI compliance labs to
    > go away. What I suspect most of them are actually doing in practice
    > is they use /dev/random, but they also use a hardware random number
    > generator so /dev/random never actually blocks in practice. The use
    > of /dev/random is enough to make the PCI compliance lab go away, and
    > the hardware random number generator (or virtio-rng on a VM) makes
    > /dev/random useable.

    Please don't forget about people who run Linux on Hyper-V, not on KVM,
    and thus have no access to virtio-rng ;)

    >
    > But I don't think we can reuse GRND_RANDOM for that reason.
    >
    > We could create a new flag, GRND_INSECURE, which never blocks. And
    > that that allows us to solve the problem for silly applications that
    > are using getrandom(2) for non-cryptographic use cases. Use cases
    > might include Python dictionary seeds, gdm for MIT Magic Cookie, UUID
    > generation where best efforts probably is good enough, etc. The
    > answer today is they should just use /dev/urandom, since that exists
    > today, and we have to support it for backwards compatibility anyway.
    > It sounds like gdm recently switched to getrandom(2), and I suspect
    > that it's going to get caught on some hardware configs anyway, even
    > without the ext4 optimization patch. So I suspect gdm will switch
    > back to /dev/urandom, and this particular pain point will probably go
    > away.
    >
    > - Ted
    >

    Well, at this point, I see that there is a lot of disagreement about how
    getrandom() should behave, aggravated by the baggage of existing
    applications and libraries with contradictory requirements regarding
    getrandom(0) (so not really solvable). I am almost convinced that we
    might want to return -ENOSYS unconditionally, and create a different
    system call with sane flags.

    --
    Alexander E. Patrakov

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