Re: Linux 5.3-rc8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: smime.p7s
Description: Криптографическая подпись S/MIME


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux