Conversation

🤦‍♂️ For when you don’t trust your CPU and you want to defend against it by running code on it.

Quote Tweet

Aug 27, 2018

New Linux Kernel feature to distrust CPU’s Random Number Generator, that may have been compromised by “Nation State’s Intelligence or law enforcement agencies”

182

This Tweet was deleted by the Tweet author. Learn more

Daniel Micay

@DanielMicay

Aug 28, 2018

Yeah, and they do use this functionality whether or not it's considered to be trusted based on the configuration option. The trust option is only about whether it's credited as providing entropy. If it's credited, the CSPRNG will be initialized right away and won't need to block.

Replying to

and

Many environments (embedded, virtual machines) don't provide other good sources of entropy so not crediting the CPU CSPRNG results in getrandom(...) blocking for a long time in early boot. It can stall the booting process for minutes, hours, etc.

Replying to

and

Crediting it puts full trust in it working properly. It could be AES-CTR based on very poor entropy and it would still appear to be totally fine externally. It could be negligence or cost cutting that results in it not working properly. It doesn't need to be malicious.

1:02 AM · Aug 28, 2018Twitter Web Client

Replying to

and

On a modern desktop / laptop, there's not much advantage to trusting it since there's plenty of other entropy to credit. In many other environments, that's not a reasonable choice. It hurts everyone if projects avoid using getrandom(...) or make it non-blocking with a fallback.

Replying to

and

Even if it's trusted / credited, it stops mattering after early boot once the other sources of entropy have provided enough input anyway. Similarly, any sane userspace is supposed to load saved entropy from the previous boot and that solves most problems.