The AMD microcode dillemma is about to get real - what to do?
- Login o registrati per inviare commenti
So it turns out that AMD produced a bunch of Zen2 CPU's with a flaw that's now discovered to be exploitable via javascript. AMD is now producing some microcode to protect server CPU's, and later this year they will ship out some updated microcode to protect laptop and desktop CPU's.
Given that we've had all these debates about the ethics of proprietary cpu microcode updates - now that a microcode update may be necessary to protect from real live exploits, I'm wondering where everyone's thinking will fall on this AMD Zen2 dillemma.
Of course, it's possible that free software changes to the kernel will protect systems against the exploits, so this AMD situation might still not be such a crucial dillemma. But we are quickly approaching that point where free software advocates might have to make a decision - use an exploitable CPU without protection, or swallow the proprietary microcode pill?
I haven't fallen either way on this debate - I'm thinking each individual will probably have to make the choice that works for them. Some people may use these computers for business and may be required to have taken verified security measures. Others may use their computers only for browsing, and by using extensions like LibreJS can avoid any javascript exploits.
Anyway, it's a good point for discussion. If your cpu was clearly exploitable without a microcode update, what would you do?
I am a translator!
Do these AMD processors have things similar to the IME and the FSP of Intel processors?
Besides, I wonder about ARM processors. I have never heard of the possibility for a user to use a microcode update. There might be no microcode or it may not be possible to do any update to it after the processor is sold to users. Do ARM processors have no flaw?
We have to migrate away from CISC ISAs, such as AMD64, which date back to the Intel 8086. Most RISC ISAs do not have any microcode at all. Libre-SOCs Micro-Architecture dates back to the 1960s, and is more elegant than anything CISC: https://www.crowdsupply.com/libre-risc-v/m-class/updates/modernising-1960s-computer-technology-learning-from-the-cdc-6600
“Others may use their computers only for browsing, and by using extensions like LibreJS can avoid any javascript exploits.”
Is LibreJS enough?
A more radical solution is to completely disable JavaScript.
I am a translator!
If the browser would only execute JavaScript from the distro repositories, that could be ok.
Hi Andy, Thank you for bringing up this topic.
This isn't unprecedented; we've seen similar issues, such as Spectre and Meltdown. For a deeper understanding, this article might be enlightening: http://www.fsfla.org/ikiwiki/blogs/lxo/pub/who-is-afraid-of-spectre-and-meltdown.en.html.
Turning to nonfree software is never the answer. While the immediate practicality might be tempting, it's crucial to remember the underlying principles of software freedom: The very essence of free software is to ensure that users are in control of their computing - that can't happen with nonfree software, by definition. The developer of that software may promise they'll make you more "secure" somehow in exchange for giving up your control but it's a lure, a trap. A ruinous compromise: https://www.gnu.org/philosophy/compromise.en.html.
Let's think about this differently. If the CPU were a pile of circuits that somebody could not alter without making a new one, we would be forced to find other solutions. In this context, if we can't change the circuits, we must focus on looking for different hardware or working on (free) software solutions at the operating system level to mitigate the issues within the CPU's circuitry. An example of this can be seen in how GCC has workarounds for known processor bugs and it generates code that avoids triggering the bug. Turning to nonfree software to fix the problem is never the answer, just as it wasn't the solution during the Spectre and Meltdown incidents.
>"Turning to nonfree software to fix the problem is never the answer, just as it wasn't the solution during the Spectre and Meltdown incidents."
I've thought about Spectre and Meltdown recently in regards to this current AMD cpu vulnerability. Isn't it true that we can simply disable hyperthreading and then all of these speculative execution side channel vulnerabilities disappear?
I've run my system without hyperthreading in the past and didn't notice a difference unless I was compiling a large package. But for my routine daily computer activities it didn't make any noticeable difference at all.
I think that a purely librebooted system without microcode updates and without hyperthreading enabled might be a good libre software solution all the way around. And if the user wanted to enable hyperthreading to do some package compilation, a simple security solution would be to take that computer off-line during the period that hyperthreading is enabled, and if it is online simply disable javascript which is the potential attack vector.
Any thoughts about this jxself?
For me the only option is moving to a free microarcitecture, such as libre-soc's CDC6600 based one.
If there is microcode, it will be free. POWER9 for example does not have any microcode at all.
The Raptor folks state that there is a free microcode for POWER9.
- Login o registrati per inviare commenti