8 ms·
It 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 m
by nonrandomstring 4y ago
It 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.
- femto 4y agoThen you have to worry about any "management" modes on the FPGA. https://www.cl.cam.ac.uk/~sps32/Silicon_scan_draft.pdf https://www.cl.cam.ac.uk/~sps32/Silicon_scan_draft.pdf
- jgtrosh 4y agoWhat's left, RISC-V? https://en.wikipedia.org/wiki/RISC-V https://en.wikipedia.org/wiki/RISC-V
- pjmlp 4y agoNot really, because most deployments use UEFI alongside them. https://github.com/riscv-admin/riscv-uefi-edk2-docs https://github.com/riscv-admin/riscv-uefi-edk2-docs So if it isn't from door A, door B will do.
- yjftsjthsd-h 4y agoHow is UEFI like ME/PSP? I thought it was just for booting.
- robotnikman 4y agoIts surprisingly more complex than that. You can run Doom in UEFI https://github.com/Cacodemon345/uefidoom https://github.com/Cacodemon345/uefidoom
- yjftsjthsd-h 4y agoOkay, but that doesn't really bother me; running arbitrary payloads is the point of a bootloader. The only reason I would be worried by UEFI on RISC-V is if the UEFI firmware in question stays running in the background after the OS boots, and isn't properly inspectable. That might be the case - I have some vague notion of UEFI providing post-boot services, and for all that the EDK version is FOSS you could certainly make a closed version - but I'm not seeing any reason to panic just yet.
- derefr 4y agoUEFI can provide post-boot services, but only in the same sense that a DOS-era BIOS did: by providing memory-mapped code that UEFI applications can call into, exokernel style. The UEFI framework isn't a hypervisor; it has no capacity to have ongoing execution threads "behind" the OS kernel. Rather, the OS kernel just receives a memory+PCIe map from UEFI at startup that contains some stuff UEFI left mapped; and it's up to the OS kernel whether to keep it mapped and make use of it; or just to unmap it. And no production OS kernel really uses any of the code that UEFI maps, or keeps any of said code mapped. It may keep the data-table pages (e.g. ACPI sections) mapped, for a while; but usually only long enough to copy said data into its own internal data structures. (Which is a shame, actually, as an OS kernel that did take advantage of UEFI services like UEFI applications do, would be able to do things that modern kernels currently mostly can't — like storing startup logs and crash dumps in motherboard NAND space reserved for that function, to provide on-device debugging through a separate UEFI crash-log-viewer app in case of startup disk failure, rather than needing to attach a separate serial debugger.)
- greggsy 4y agoIt’s not a backdoor until it’s proven that it’s used for that propose. Until the it’s just (yet another) potential side channel.
- CoastalCoder 4y agoI don't understand that logic. It's like saying I haven't been robbed until I discover that my stuff is missing.
- atq2119 4y agoThat's literally true, though? To make the analogy work for you, you have to add something about doors being unlocked, or somebody else having the key to your home.
- bee_rider 4y agoI think in the original analogy, the actual robbery is just used as an event which may occur without our knowledge. Your analogy is better, the mapping makes more sense. Something like: The locksmith has made a copy of your keys without notifying you. They could hypothetically use those keys to enable a robbery, but you won't know definitively either way until you find something stolen. But it is a pretty weird thing for them to do, right?
- na85 4y ago>That's literally true, though? There's no Schrodinger's Burglar. You've been robbed once I take your wallet, whether you've discovered it or not.
- oasisbob 4y ago> It's like saying I haven't been robbed until I discover that my stuff is missing. Well, robbery is theft under threat of force, so it would be very hard to be robbed and remain unaware of it.
- jsjohnst 4y ago
- _kbh_ 4y agoAt least for AMD the PSP isn’t externally exposed which means the attack surface is drastically reduced.
- rkangel 4y agoThis is not about the management engine. Microcode is part of the actual core processor itself, but an updatable layer. One sort off correct mental model might be to think of x64 hardware as being a RISC-ish processor that runs microcode that runs your code.
- yjftsjthsd-h 4y agoWhat about POWER?
- alophawen 4y agoAMD have much the same thing. https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor#Security_history https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo...
- astrange 4y agoThis is about microcode, not the Intel ME. AMD does also have updatable microcode though.
- deleted 4y ago[deleted]
- markus_zhang 4y agoCan you please elaborate on the "To protect the media conglomerates." part?
- mschuster91 4y agoIntel's SGX was at least partially intended to implement DRM [0], and its various-ish predecessor technologies such as old-school Palladium/TPM was expected to do the same [1] (but was ultimately cancelled because of wide backlash). [0] https://www.techspot.com/news/93006-intel-sgx-deprecation-impacts-drm-ultra-hd-blu.html https://www.techspot.com/news/93006-intel-sgx-deprecation-im... [1] https://en.wikipedia.org/wiki/Next-Generation_Secure_Computing_Base https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...
- markus_zhang 4y agoThanks, didn't know these are pretty hardcore protection. Just curious maybe these protection layers and protetion-protection layers may introduce more vectors for attackers?
- nonrandomstring 4y ago> Can you please elaborate... Certainly. Intel (amongst others) supply consumer grade CPUs for a "multimedia" market, to service music and movie playback. The movie and music industry apply intense pressure and lobbying against the computing industry to protect their profits. They see users having control over media, and thus ability to copy, recode, edit or time-shift content as a threat, which they dub "piracy". Under this pressure to implement "Digital Rights/Restriction Management" within their hardware, semiconductor manufacturers have been making microprocessors increasingly hostile to end users, since if users were able to access and examine device functions they would naturally disable or reject what is not in their interests. Hiding undocumented functionality to take over, examine or exfiltrate data from systems via backdoors etc is a natural progression of this subterfuge and tension between manufacturer and user. This situation of cat-and-mouse hostility should not exist in anything recognisable as a "free market", and hence I deem it "protectionism". Now the real problem is that these same "multimedia" processors are used in other areas, automotive, aviation, health and even military applications. The "risk-tradeoffs" bought by big media bleed into these sectors. Therefore it's clear to me that measures for the protection of "intellectual property" are directly at odds with computer security generally, and are increasingly leading to problems for the sake one relatively small sector. Sure, the digital entertainments industry is worth many trillions of dollars, but pales within the larger picture of human affairs. At some point we may have to choose. Hollywood or national security?
- dncornholio 4y agoe-waste? how come? I already assumed my hardware is insecure.
- userbinator 4y agoForced obolescence FUD. Nothing more, nothing less.
- jcranmer 4y ago> Putting encrypted microcode into consumer CPUs was always a dumb idea. Serious question: which consumer CPUs have unencrypted microcode? AMD processors have had theirs encrypted for a decade, Intel for even longer, and nothing I've seen indicates that any ARM models have unencrypted microcode updates floating about.
- Enginerrrd 4y agoBasically none these days. But therein lies the problem. The actors can't be trusted. In part because the state-actors in which they reside can't be trusted and they can (and do) issue gag-orders to shove backdoors down their throat. But the problem with backdoors has always been that other people will likely eventually figure out how to use them too. If you can't audit the microcode, you have a massive gaping security problem.
- deleted 4y ago[deleted]
- formerly_proven 4y agoWhich ARM cores have loadable microcode to begin with?
- cogburnd02 4y agoIf it can't be done on a MC68000 (or thousands in parallel), then does it really need to be done?
- dkasak 4y agoIt may be a serious question, but I don't see how it relates to the part you quoted. It still is a dumb idea, regardless of the answer to your question.
- Klonoar 4y agoDo the Raptor systems (POWER-based) fit here?
- classichasclass 4y ago
- gjs278 4y ago