> Unfortunately, Linus is dangerously incompetent at cryptography. As was the case with getrandom(2).

I beg to differ. Of all people I know of, Linus is one of the most competent person when it comes to cryptography, more so than any of those Twitter celebrities. I suggest you dig into LKML archives. Exactly what in the case of getrandom(2) do you think makes him incompetent?

> I don't think you understand or correctly recall the scenario in which Linus nearly broke getrandom(2). The bug Linus was attempting to fix by breaking getrandom(2) was not a security bug. It was an availability bug, in userspace, caused by broken userspace code deadlocking itself.

I recall correctly. Optimizations in ext4 unveiled broken design of previous getrandom(2). 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. Another would have been to keep the bug hidden and revert any optimization that lowers early entropy pool. In the end, the solution at which the community arrived is best compromise given the constraints. The kernel is one of the few places where you can real software engineering to take place.

I think your comment is driven more by personal hatred for a great mind rather than technical merit.

> 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.

Alas most people are incompetent when it comes to cryptography. It's another of those situations when if you don't know why something has to be done a certain way, you shouldn't be included in that decision making progress.