> Of all people I know of, Linus is one of the most competent person when it comes to cryptography
This statement strikes me as bizarre because it's just so off-base. It seems you relate to Linus as some kind of personal hero, which is fine, but then use that as a reality-distortion field, which is probably unhelpful for you. (It's just confusing to others.)
To the best of my knowledge, Linus has not done any significant work in cryptography, nor is he regarded by any practitioner as an expert in the field. I would love to learn about any work he has done; I am just not aware of any, and I have some experience in the field.
> Exactly what in the case of getrandom(2) do you think makes him incompetent?
getrandom(2) is the only good random number ABI in Linux. It is the only way to request real random numbers that blocks until initial seeding and never blocks afterwards (i.e., BSD /dev/random behavior). It has a flag that can be used to avoid blocking.
Linus seriously proposed changing the ABI for getrandom() with flags specifying "please block until real random numbers are available" to silently ignore those flags if the routine would block, and instead return garbage. This would break all existing software that used getrandom() correctly and would be especially egregious for anything using getrandom(2) for cryptographic keys — which is a good and correct use of the interface.
His proposal was fundamentally similar to, for example, changing the ABI of /dev/random to silently return /dev/zero output instead of blocking.
> I recall correctly. Optimizations in ext4 unveiled broken design of previous getrandom(2).
Nope, you've still got it wrong. https://lwn.net/Articles/800509/
1. The design of the getrandom(2) API was and continues to be fine. It is exactly what was missing on Linux, and has room for future expansion via additional flag bits. It is not broken.
2. The getrandom(2) ABI had been in the kernel for five years at the time Linus proposed breaking it.
3. The bug was in GNOME Display Manager, which ran early in boot on the particular system that lead to the report, and GDM managed to deadlock itself by incorrectly invoking getrandom(2) with a blocking request for entropy that it did not need.
4. (Broken user code can also deadlock itself by calling, say, sleep(99999).)
5. Yes, an ext4 optimization lead to slightly reduced initial entropy on that particular machine and the sighting of the underlying deadlock condition in GDM. But that latent condition was always present.
> To keep backward compatibility an easy choice could have been to supply early userspace with possibly predictable random numbers, which, of course would be a security issue.
This (1) does not keep backwards compatibility, and (2) is exactly the approach Linus initially proposed and had to be talked down from. This is the proposal that was dangerously incompetent. From the thread at the time:
Andy Lutomirski:
There are programs that call getrandom(0) *today* that expect secure
output… We can't break this use case. Changing the semantics of
getrandom(0) out from under them seems like the worst kind of ABI
break -- existing applications will *appear* to continue working but
will, in fact, become insecure.
Matthew Garrett (various emails):
We've been recommending that people use the default getrandom() behaviour for key generation since
it was merged. Github shows users, and it's likely there's cases in internal code as well. …
The semantics many people want for secure key generation is urandom, but
with a guarantee that it's seeded. getrandom()'s default behaviour at
present provides that, and as a result it's used for a bunch of key
generation. Changing the default (even with kernel warnings) seems like
it risks people generating keys from an unseeded prng, and that seems
like a bad thing? …
In one case we have "Systems don't boot, but you can downgrade your
kernel" and in the other case we have "Your cryptographic keys are weak
and you have no way of knowing unless you read dmesg", and I think
causing boot problems is the better outcome here.
The getrandom(2) saga was a long thread of Linus repeatedly ignoring the knowledge and concerns of the his own security deputies.
> In the end, the solution at which the community arrived is best compromise given the constraints.
Yes, catastrophe was avoided and in the end a happy resolution was reached — in spite of Linus, not because of him.
> I think your comment is driven more by personal hatred for a great mind rather than technical merit.
Nope.