7 ms·
> 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 m
by 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.)
- LargoLasskhyfv 4y agoOn X86/AMD64 there is also ACPI and SMM (System Management Mode), which overlap in parts. ACPI calls into code provided by whichever bootloader, running post-boot above to operating system, or behind its back, so to speak. It's complicated. [1] https://en.wikipedia.org/wiki/System_Management_Mode https://en.wikipedia.org/wiki/System_Management_Mode [2] https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface https://en.wikipedia.org/wiki/Advanced_Configuration_and_Pow... Mostly for dynamic powermanagement and voltage regulation, monitoring temperatures, hotplugging, etc. That's just the way it is (now). I remember when this first made the rounds over a decade ago with some mainboards from CENSORED Apple supplier which were pretty usable, except when running under something else than Microsoft Windows. IIRC it wasn't malice, only implemented in a way which made this hard to interface with from Linux, or the likes. Of course undocumented. Later, but about the same timeframe the first so called open source/security 'zealots' damning ACPI in general for those reasons. It may be called differently on other platforms, but similar/equivalent mechanisms exist on almost everthing which is not in a museeum or landfill.
- zekica 4y agoIt is not just for booting. UEFI has Runtime Services that an OS can call.
- classichasclass 4y agoPOWER8 and POWER9 say hi.
- LargoLasskhyfv 4y agoMoney says bye.
- 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]