this post was submitted on 08 Aug 2023
208 points (98.6% liked)

Linux

48234 readers
490 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

cross-posted from: https://lemmy.world/post/2852886

For those out of the loop, some AMD users have been suffering from stuttering issues caused by the AMD fTPM random number generator. A firmware/BIOS update appears to fix the issue for some users, but not others, leading to more bug reports being sent in. Last week, Linus Torvalds said "let's just disable the stupid fTPM hwrnd thing", and, as of today the Linux kernel has gone ahead and blanket disabled RNG use for all current AMD fTPMs.

top 22 comments
sorted by: hot top controversial new old
[–] [email protected] 30 points 1 year ago

This is the best summary I could come up with:


As a follow-up to the first-on-Phoronix article last month that highlighted Linus Torvalds' frustrated views on the AMD fTPM random number generator continuing to cause problems for users even with updated firmware/BIOS, as of today the Linux kernel has gone ahead and blanket disabled RNG use for all current AMD fTPMs.

Mario summed up in that commit: tpm: Disable RNG for all AMD fTPMs

The TPM RNG functionality was previously disabled on a subset of AMD fTPM series, but reports continue to show problems on some systems causing stutter root caused to TPM RNG functionality.

Expand disabling TPM RNG use for all AMD fTPMs whether they have versions that claim to have fixed or not.

Thus over the next few days this change in behavior for modern AMD Ryzen systems will be rolling out in the next set of stable kernel point releases.

Hopefully this will lay to rest the various AMD stutter issues that continue to be reported by Linux users on recent kernel versions.


I'm a bot and I'm open source!

[–] [email protected] 20 points 1 year ago (1 children)

I am glad that I have not been bitten by this bug. Seems quite annoying.

[–] [email protected] 4 points 1 year ago (1 children)

I assume there's a kernel boot param that allows for disabling it if you get affected in a kernel older than the one they'll be disabling this.

[–] kogasa 2 points 1 year ago

They're backporting to 6.1 but you can always just disable fTPM.

[–] [email protected] 12 points 1 year ago (3 children)

Just to add a perspective from the other side of the fence, I have a gaming laptop running Windows 11 (yes I know) where this (or a very similar) issue has been plaguing Ryzen users for at least a year and a half. The issue is that TPM per se is not causing issues if turned on, but if BitLocker encryption is on it will cause occasional audio stutters and intermittent complete system halts. The only thing that reliably helps is completely turning off Bitlocker, the TPM chip can stay on and is of course needed for W11. OEMs and AMD have been digging their heads in the sand like ostritches and they have released the odd fix that does nothing to fix the underlying issue. I can't see MS doing anything to reverse course on requirements and am getting a bit fed up with their BS lately, browsing what distro might suit me best and might pull the trigger and finally switch...

[–] kogasa 6 points 1 year ago* (last edited 1 year ago)

TPM is not necessary for Windows 11.

I have a Windows 11 partition and fTPM is disabled in UEFI. Windows complains that "My computer doesn't meet the requirements to update to Windows 11" on the update menu, but there's no issue.

[–] [email protected] 1 points 1 year ago (1 children)

Have a look at Tumbleweed with KDE.

[–] [email protected] 1 points 1 year ago

Thanks for the heads up, I'm distro hopping these days and looking for options on where to settle

[–] [email protected] 1 points 1 year ago

Do it. Doooo iiiit...

[–] [email protected] 8 points 1 year ago
[–] [email protected] 8 points 1 year ago (2 children)

Does this affect older Ryzens as well? I've noticed some periodic hitching in games/videos cropping up on occasion.

[–] [email protected] 9 points 1 year ago* (last edited 1 year ago)

Hard to say. It's a firmware problem so presumably it could be affecting all of them. The CPUs aren't involved. My guess given the details mentioned by Linus is that it could affect some boards and not others, depending on what else is going on in the boards' firmware at the time when the rand call to is made. In other words, there might be other bugs present in the firmware of say ASUS that trigger this, which aren't present on MSI. And then there might be bugs present in this or that particular model's firmware. It's a whackamole which is why they decided to disable it altogether.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

I believe it's only older Ryzen that is affected. If you have a newer gen Ryzen you are good (for now).

Edit - I'm a sleep deprived dumb dumb, I thought this was about the new Ryzen "bleed" vulnerability. 😩

[–] [email protected] 7 points 1 year ago (1 children)

Sweet. I'm switching to Ryzen next week and was hoping to see this resolved just in case.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago) (2 children)

You'll need to use a bleeding edge kernel to get this patch unless it's backported to older kernels by your distro's maintainers. I doubt this will happen for say Debian or Ubuntu. Instead, you'd have to wait for a new HWE that has this new kernel or whatever the equivalent in Debian is.

[–] [email protected] 5 points 1 year ago

Yep. This system will be running Arch so I'm not too worried.

[–] [email protected] 4 points 1 year ago (1 children)

You can also solve this problem by disabling the TPM in the BIOS settings, assuming your motherboard has such a setting. No TPM, no problem.

[–] [email protected] 2 points 1 year ago (1 children)

Yeah. I think I disabled it the day I built my system.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

This is the way. Besides these stuttering issues, the TPM is owner-disobedient (there is no way for the owner to extract keys stored in it) and an unnecessary attack surface (which, if breached, gives the attacker unfettered, persistent, and irrevocable access to the entire machine).

[–] [email protected] 3 points 1 year ago (1 children)

👁 Imagine using any commercial firmware/hardware RNGs. snowden

[–] [email protected] 6 points 1 year ago* (last edited 1 year ago) (1 children)

Well Linux is using rdrand in place of the fTPM one so .. from firmware to hardware. Then again even if you generate random numbers using pure software, is your CPU or firmware FOSS and without bugs (cough .. Debian OpenSSL maintainers, cough) or exploits (Ken Thompson says hi)? If not, and you assume you can't trust the firmware and hardware - all your random numbers are belong to us. Gotta draw the line somewhere, unless you're building your machine from diodes and solder. Personally, I live in a Five Eyes country so I'm alright using the hardware the NSA/GCHQ/CSIS/etc use. If I'm fucked, they're fucked.

Relevant meme.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Well Linux is using rdrand in place of the fTPM one so .. from firmware to hardware.

That depends on your distribution's setting of the CONFIG_RANDOM_TRUST_CPU compile-time configuration option and the random.trust_cpu sysctl setting. I'm not sure what the major distributions are doing with that at the moment.

Then again even if you generate random numbers using pure software, is your CPU or firmware FOSS and without bugs (cough .. Debian OpenSSL maintainers, cough ..)? If not, and you assume you can't trust the firmware and hardware - all your random numbers are belong to us.

Like you said, it is impossible to be completely safe. But using proprietary cryptographic hardware/firmware, the inner workings of which are known only to Intel, introduces a lot of risk. Especially when we know the NSA spends hundreds of millions of dollars on bribing companies to introduce backdoors into their products. At least when it's an open source cryptographic library they have to go to great lengths to create subtle bugs or broken algorithms that no one notices.

Our CPUs are certainly backdoored too, beyond RDRAND. But it's way more complicated to compromise any arbitrary cryptographic algorithm running on the CPU with a backdoor than making a flawed hardware RNG. Any individual operation making up a cryptographic algorithm can be verified to have executed properly according to the specification of the instruction set. It would be very obvious, for example, if XORing two 0s produced a 1, that something is very wrong. So a backdoor like this would have to only activate in very specific circumstances and it would be very obvious, limiting its use to specific targets. But a black box that produces random numbers is very, very difficult to verify.

Ultimately, the real solution is the dissolution of the American security state and the computer monopolies.

If I'm fucked, they're fucked.

Not if they're the only ones who know about the backdoors.

Edit: I started writing that before your edit about the "Ken Thompson hack". An element of any good backdoor would include obfuscation of its existence, of course. The issue is it is impossible to predict every possible permutation of operations that would result in discovery of the backdoor and account for them. Maybe if you had a sentient AI dynamically rewriting its own code... anyway, backdoors in tooling like compilers is very concerning. But I'm not too concerned about a Ken Thompson type attack there just because of how widely they're used, how many different environments they run in, and how scrutinized the outputted code is.