By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), August 11, 2019 12:13 pm
Room: Moderated Discussions
@never_released (none.delete@this.none.none) on August 11, 2019 11:10 am wrote:
>
> Why does the kernel rely on RDRAND instead of Intel ME/TXE or AMD PSP or maybe even a TPM
> in those cases? What are the advantages of having RNG instructions right into a processor
> instead of them being available as a coprocessor or a separate device as they should be?
Performance.
Performance matters. A lot.
TPM is a joke, plus why should you trust TPM in the first place, when we know there are broken implementations? Going over a slow bus to get a random number from an untrusted entity is beyond garbage.
Intel ME is another joke - known broken backdoors, undocumented, not architected. Why would you want to use that? People literally try to disable those things because they don't trust them.
Just say no.
If you want external chips doing external security, pick an actual external vendor you trust (and have a reason to trust), and work with that. Not that people really do (they do exist, but people who have trust issues tend to want to not have external random numbers, but external key generation and validation, eg yubikey or similar).
But if what you need is real random numbers, you often need a lot of them, and going over a bus is much much too slow. If you have to go outside the CPU, you'll just have to generate your own instead, and use the insanely slow (and generally not very standardized or widely available) external hardware only to fill your internal pool in order to then do everything else in software.
And whenever you do that, you are just fooling yourself if you think you're "more secure" by going to that external entity.
So an actually architected rdrand instruction is very much the right thing to do. But you'd wish that the CPU vendors had verified it better. Intel apparently did do a good job. Nobody has shown any patterns in their rdrand implementation, and it's been available for a longish while.
But again: the lack of verification on the part of one CPU vendor doesn't mean that anything else is any better. Just google the Infineon TPM key fiasco.
I'd rather trust a documented and architected instruction in a common CPU architecture than the complete random external hardware that may or may not be available, and that is guaranteed to be slow.
Look how quickly this particular AMD bug got caught. Then go look how long it took to notice the Infineon TPM bug... Specialized hardware is usually objectively worse in just about every possible way.
Linus
>
> Why does the kernel rely on RDRAND instead of Intel ME/TXE or AMD PSP or maybe even a TPM
> in those cases? What are the advantages of having RNG instructions right into a processor
> instead of them being available as a coprocessor or a separate device as they should be?
Performance.
Performance matters. A lot.
TPM is a joke, plus why should you trust TPM in the first place, when we know there are broken implementations? Going over a slow bus to get a random number from an untrusted entity is beyond garbage.
Intel ME is another joke - known broken backdoors, undocumented, not architected. Why would you want to use that? People literally try to disable those things because they don't trust them.
Just say no.
If you want external chips doing external security, pick an actual external vendor you trust (and have a reason to trust), and work with that. Not that people really do (they do exist, but people who have trust issues tend to want to not have external random numbers, but external key generation and validation, eg yubikey or similar).
But if what you need is real random numbers, you often need a lot of them, and going over a bus is much much too slow. If you have to go outside the CPU, you'll just have to generate your own instead, and use the insanely slow (and generally not very standardized or widely available) external hardware only to fill your internal pool in order to then do everything else in software.
And whenever you do that, you are just fooling yourself if you think you're "more secure" by going to that external entity.
So an actually architected rdrand instruction is very much the right thing to do. But you'd wish that the CPU vendors had verified it better. Intel apparently did do a good job. Nobody has shown any patterns in their rdrand implementation, and it's been available for a longish while.
But again: the lack of verification on the part of one CPU vendor doesn't mean that anything else is any better. Just google the Infineon TPM key fiasco.
I'd rather trust a documented and architected instruction in a common CPU architecture than the complete random external hardware that may or may not be available, and that is guaranteed to be slow.
Look how quickly this particular AMD bug got caught. Then go look how long it took to notice the Infineon TPM bug... Specialized hardware is usually objectively worse in just about every possible way.
Linus
