Fed-up Torvalds suggests disabling AMD’s 'stupid' performance-killing fTPM RNG Ongoing issues with Linux and AMD's fTPM – the chip designer's firmware-based TPM – appear to be wearing on kernel overseer Linus Torvalds' nerves, who has suggested switching off the module's random number generator altogether. "Let's just disable the stupid fTPM hwrnd thing," Torvalds said on the open source kernel's …
That's just reflexively built in by Microsoft's 'programmers' (I use the term loosely here).
They may know sod all about security, but they're world leading experts when it comes to automated user harassment, and it's hard to switch off when you've been doing it for literally decades. Force of habit and all that.
My home PC has installations of both Win10 and Win11 on it, yet the Win10 installation is still nagging me to "upgrade" it to Win11. There'd be blessed little point in having two separate Win11 installations, and the only reason I have one is so that I can "test-drive" it to make sure that nothing has problems when Win10 is finally end-of-lifed.
I get to periodically enjoy two sets of massive Windows updates for my trouble. At least the Win11 installation is on a fast NVMe drive and not spinning rust, so I don't have to sit there for hours looking at the good old "100% complete" messages as it writes massive amounts of data slowly to disk.
edit - That has reminded me to boot it into Win11 for the first time in 4 months and apply the updates, while I'm working...
BitLocker supports password-only full disk encryption of the operating system disk, even on Windows 11. The real reason Microsoft wants to use the TPM so badly is to bodge a solution to the unsalted MD4 password hash issue (required for compatibility) as well as to prevent the unauthorised export of authentication tokens.
Today I learn that after boasting TPM as "secure because it's hardware" now they have reverted to a "software" TPM implementation. LOL!
Fortunately I DON'T USE TPM at all. And I actually believe that disk encryption that relies on TPM is inherently wrong. It should rely on the user's credentials to work, not on some secret that's stored on the PC and can be hacked out of it if you really want it, or can be lost in a glitch of the horrendously complex pile of shit that is the whole TPM mess.
This doesn’t make sense.
You want one entropy source that is entirely physically unpredictable. That’s what this thing should provide. And that kind of thing is known to be expensive.
Once you got that you want a cryptographically secure generator that creates a sequence of random numbers, that are unpredictable _based on your initial entropy source_. That’s mathematics. It is well-known mathematics. It’s not cheap, but not very expensive either. There is no reason at all to use the entropy source again. All you need to do is to keep the state of that random number generator secret, so nobody can copy the state and produce the same random numbers.
(And on top there are many situations where you want random numbers very fast without any requirement for cryptographic security).
So what they are doing only makes sense if they can’t keep the state of their cryptographic random number generator safe and have to destroy/recreate it repeatedly.
But we always must remember that we are asking a hardware device created to be predictable - always come out with the same [correct] answers - to be unpredictable when generating "random numbers".
THAT'S the hard part. Forcing a system that is intentionally rational to be...unrational. To *not* give an answer that we expect. That's harder than it seems, so TPM: a subsystem intentionally designed to break the paradigm. And look - even then, AMD botched it.
When you control the actual hardware.
There are several well-known ways of creating nearly perfect entropy using actual hardware components.
A warm diode, for example.
However, a given design produces entropy at a specific rate, so will stall if a system consumes it faster than it can be created.
The real issue is often that the hardware rng won't tell the kernel how many bits it has available.
"And look - even then, AMD botched it."
How? How did AMD botch it?
Are you claiming that AMD's RNG isn't giving back good results? If so, what do you base that on?
Or did you just miss where the article describes how the RNG inside the fTPM is simply too slow to be usefully invoked as many times as is happening at the moment, because it is accessing NVRAM across an SPI link (which is simply not going to achieve data rates even vaguely comparable to system RAM)? Which is all quite reasonable behaviour for the TPM hardware but isn't anything you want your code to continually do.
So far, I have not found any spec for TPM that says the RNG should be running faster than the AMD implementation.
Did you miss the bit in the article, where the problem is actually described? It isn't the slowness of RNG, it's the fact that it stalls the processor while it waits. If I wrote a bit of software that stalls the whole system while it does some processing, especially on a modern system that is multi-threaded and multi-core, I'd rightly get a kicking for it.
A bottleneck in RNG should only be a bottleneck for RNG, and not for the whole system.
It's like having your house wired so that the lights don't work unless the dishwasher is running...
Ugh, this brings back memories of trying to understand the FIPS-140 rules on entropy. If you ever need that certification (which you will if you're selling cryptographically secure systems to governments) the test labs are very, very picky. As they should be, of course, but it's a PITA when you're on the other end of the design process. Linus probably needs to talk to the experts before arbitrarily changing anything, he could land his customers with 6-figure recertification bills.
As far as I can tell, baseline Linux has never claimed to be FIPS-140 capable: Linus removing a performance hog won't affect that.
For anyone who *does* need to certify themselves against FIPS they can get old of a replacement RNG and either use it to replace the kernel routine or just use it within their compliant code.
Or buy the required mods & support from a third-party.
true random generators are pretty much impossible to make in silicon chips
It's actually pretty easy, look up ring oscillator for the basic circuit and more detailed papers like this IEEE paper on TRNGs on FPGAs for how to use the idea. The biggest problem is that the output is usually biased and needs whitening. That's often done by passing the raw output through something cryptographic like AES, which is why it can be slow.
Hard to produce true random data in simple math or simple programming, but there are lots of ways to produce random data in silicon -- lots of thermal noise with a quantum mechanics basis, and circuits that detect and use that have been around for decades (I recall ham radio circuits in the 1970s pulling noise off diode junctions). CPUs and support chips with access to thermal noise sensors have been around for well over a decade.
Another trick in a multitasking system is to use random data for as many things as possible. Even if you know the seed and current state of the RNG (which hopefully you don't) and the algorithm, if you don't know how many other tasks grabbed some random data since you last looked, you don't have much clue as to what is coming when you ask.
“and all subject to bias output, not true rng.”
All you need is entropy. Once you have n bits of entropy, you can turn it into an unbiased n bit random number. Throw a dice and write down whether each throw showed a six or not. Less than one bit of entropy per throw (I think) but easy to turn into an unbiased random number.
It part of the TPM functionality, which as well and random number generator can be used to store secure things like private keys, so NVRAM is required
It's not so much a serial port, but one of the access methods of the TPM chip is via a serial interface
The TPM was never designed to be high performance, so i am not sure why someone would access the random number generator continually. Sure, seed the generator using it, but for most situations that is as much as you need, and the standard chip based ones are adequate. If you need high performance random number generation (say a high end server) then install a dedicated entropy hardware
> so i am not sure why someone would access the random number generator continually.
There is a long history of squabbling over the RNG in Linux (and quite probably in other places) about what "must" be included in the RNG in order to "obviously make it better". This is not the first time that something has been added at one time and then pulled out later.
Without checking the commits (which anyone can do) we don't know if the too-high polling was in there at start of the fTPM support or if someone just saw a call that could read the value, without understanding it would be slow, and whacked it into (what we now know to be) the wrong place.
I don't believe that Linus has claimed to be a mathematician and able to judge on those issues on the RNG, he (his lieutenants) check the code for programming errors and has to accept the originators claims of usefulness. Then real life usage shows up problems that *do* fall into Linus wheelhouse and he speaks out...
This post has been deleted by its author
This post has been deleted by its author
This post has been deleted by its author
What "duff kit"?
Do you have any evidence that the fTPM is not correctly functioning as a TPM?
Did you understand that the 'f' in 'fTPM' stands for firmware? I.e. this is a bit of code (in the BIOS AFAIK) that provides, basically, a cheap'n'cheerful implementation of TPM.
Ryzen motherboards can (and mine certainly does)[1] provide a connector for a hardware TPM - but even that is unlikely to be a speed demon (although, as a separate piece of hardware, it will run in parallel with the CPU so its slowness won't block everything and cause this stuttering (probably). Still, calling into an TPM more frequently than you really need to seems like it'd slow down your kernel's RNG.
[1] had to check the manual, I know I haven't bothered to buy a h/w TPM.
and RUST snake oil sales men ? At least AMD has no h(ij)acked Boeing 777 airplanes on its list of 'achievements'. In 2014 things went sour for Boeing (MH370)(MH17). On the Boeing planes were then the latest Intel Lake CPUs installed. In August 2014 Intel issued an emergency microcode update :
https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
