10 ms·
I have a sinking feeling in my chest. If the suspicions are true, we may be at a pivotal moment here.
by cowtools 4y ago
I have a sinking feeling in my chest. If the suspicions are true, we may be at a pivotal moment here.
- pyinstallwoes 4y agoCan you expand on that as someone who is learning more about low-level architectures in relation to the hardware and microcode layer?
- fragmede 4y agoIt's never been publicly clear how much is done in hardware, and how much is actually done via microcode. This blows the doors open and reveals that there's actually a lot more being done in microcode than previously suspected. What's pivotal, is how much more possible this makes microcode-based attacks against Intel-based systems.
- pyinstallwoes 4y agoYeah if they can ship code that fixes "critical security" faults in a physical product, then it's probably at the software level all the way down.
- astrange 4y agoIt's more like they can patch any instruction to become microcoded, but that doesn't mean it shipped that way originally.
- saagarjha 4y agoThis makes microcode more auditable to most people. Relying on the “security” of most people being unable to inspect their microcode is not really a good position to have.
- blacklion 4y agoIt is true ("lot more being done in microcode than previously suspected"), but only for Atom cores. Which are much simpler than "Core" cores, and, to be honest, it should be expected for small, simple and slow core - as microcoded execution is much simplier and make sense for these cores. On the other hand, most of 12-series CPUs contains them :-(
- ac29 4y ago> On the other hand, most of 12-series CPUs contains them :-( E cores in Alder Lake are not listed as vulnerable to this attack.
- jsjohnst 4y ago> as microcoded execution is much simplier and make sense for these cores Say what? Can you explain what you are basing that on?
- AnimalMuppet 4y agoIf you build a simple, lower-end chip, you do so by giving it fewer hardware resources - fewer things where the implementation is via gates. That means that, in order to implement the same instruction set, you have to implement more via microcode. I think that's what's being referred do. Microcoded execution is much simpler in terms of the hardware that you have to implement.
- jsjohnst 4y ago> Microcoded execution is much simpler in terms of the hardware that you have to implement. That’s contrary to everything I’ve ever heard.
- blacklion 4y agoLets take it to extreme: you need very little resources (transistors) to implement Turing Machine, but providing enough microcode (which is very simple structure on silicon - it is ROM, which is trivial and very dense comparing to complex logic) you could emulate any complex ISA on this machine. For real world example, you could have divider as very complex logic device or as small patch of ROM implementing "school" algorithm in terms of (hardware implemented) additions, shifts and subtractions.
- mjg59 4y agoI don't think it's true that there's more being done in microcode than previously suspected? The microcode updates for various CPU vulnerabilities clearly demonstrated that microcode is able to manipulate internal CPU state that isn't accessible via "normal" CPU instructions.
- sroussey 4y agoBasic CPU design in 1990 undergrad had everything as microcode, so I’m not sure there was much of any question or any conspiracy other that EE is much harder than CS and attracts far fewer people to it, and thus less information gets spread around, I guess.
- nonrandomstring 4y agoIt could go both ways. Let's be optimistic - say, after lengthy, rigorous expert analysis it turns out there are no backdoors or prepared traps for potential malware within Intel CPUs. That's a big boon for security everywhere, and for Intel's share price. If on the other hand, it turns out against Intel, the evidence is literally baked into silicon within billions of devices in the wild which will become e-waste overnight. With this TikTok thing in the wind the Chinese will ban Intel... etc. The stakes are high. The problem was always lack of transparency. Putting encrypted microcode into consumer CPUs was always a dumb idea. And why? To protect the media conglomerates. Another reason we need to re-examine the role and value of "intellectual property" in society.
- ihalip 4y ago> billions of devices in the wild which will become e-waste overnight Not just e-waste, they can also become a huge liability. In a presentation, the authors mention that one of the CPU families which have this vulnerability were used in Tesla cars. Tesla apparently switched to AMD APUs around December 2021.
- stefan_ 4y agoAMD processors have much the same backdoor-"management" coprocessors. Just about the only processors without this stuff is your own softcore design running on an FPGA.
- adrian_b 4y agoFor now, the decryption keys have been obtained only for older Atom CPUs (e.g. Apollo Lake, Denverton, Gemini Lake). While these are reasonably widespread in the cheapest personal computers and servers, the impact of examining their microcode is much less than if the decryption keys for some of the mainstream Core or Xeon CPUs would have been obtained. In a more decent world, the manufacturers of CPUs would have been obliged to only sign their microcode updates, without also encrypting them, to enable the owners of the CPUs to audit any microcode update if they desire so, in order to ensure that the update does not introduce hidden vulnerabilities.
- asah 4y agoAtom and Core/Xeon don't share microcode? e.g. vulnerabilities in one would never work on the other?
- adrian_b 4y agoNo, the microinstruction formats are very different, so also the microprograms must be different. Even the newer Atom cores, e.g. the Tremont cores from Jasper Lake/Elkhart Lake/Snow Ridge/Parker Ridge/Lakefield have a different microinstruction format than that which has been published now. For every generation of Intel CPUs, reverse-engineering the microcode requires all the work to be done again, what has been discovered for another generation cannot help much.
- rurban 4y agoThis is only the microcode, not the deeper level minix, accessing all the IO and memory, where all the backdoors are suspected. Think of run-time patched CPU code to patch HW errors.
- mjg59 4y agoThe microcode runs on the CPU, and has the (theoretical) ability to directly modify anything running on the CPU simply by executing different instructions. The Management Engine (the component that runs the Minix kernel) is on the external chipset, and has no direct visibility into the state of the CPU. The OS that runs on the Management Engine has also been decodable for years, and while bugs have been identified nobody has found anything that's strong evidence of a back door.
- throwawaylinux 4y agoWhat's the sinking feeling suspicions? This XuCode execution engine is not a new or unknown thing - https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/xucode-implementing-complex-instruction-flows.html https://www.intel.com/content/www/us/en/developer/articles/t... We can lament the state of computer security but that feeling is surely sunken, past tense.
- rst 4y agoEven if, well... some intelligence service has developed microcode-level "implants"/malware, they wouldn't necessarily want it to be part of the standard build that gets shipped to all customers, precisely because of the risk of exposure. It's at least as likely that they'd install it on targets as updates, having first secured access by other means (as they'd have to anyway to exploit a backdoor that did ship with the chips). It's possible that some agencies would even be able to access signing keys if that helped simplify "implanting" procedures -- though it might not be necessary, if (like the OPs here) they can arrange microcode-level execution by other means.
- jari_mustonen 4y agoPlease explain your worst fears?
- midislack 4y agoI think we can all assume the suspicions are true.