SoylentNews is people
SoylentNews
Submitted via IRC for TheMightyBuzzard
Since 2008, most of Intel's chipsets have contained a tiny homunculus computer called the "Management Engine" (ME). The ME is a largely undocumented master controller for your CPU: it works with system firmware during boot and has direct access to system memory, the screen, keyboard, and network. All of the code inside the ME is secret, signed, and tightly controlled by Intel. Last week, vulnerabilities in the Active Management (AMT) module in some Management Engines have caused lots of machines with Intel CPUs to be disastrously vulnerable to remote and local attackers. While AMT can be disabled, there is presently no way to disable or limit the Management Engine in general. Intel urgently needs to provide one.
[...] EFF believes that Intel needs to provide a minimum level of transparency and user control of the Management Engines inside our computers, in order to prevent this cybersecurity disaster from recurring. Unless that happens, we are concerned that it may not be appropriate to use Intel CPUs in many kinds of critical infrastructure systems.
It's a crying shame the what the EFF says doesn't hold a whole lot of weight.
Source: The Electronic Frontier Foundation
(Score: 3, Informative) by butthurt on Monday May 15 2017, @07:45AM (4 children)
Correct me if I'm wrong, but I'm assuming these are fine:
https://libreboot.org/docs/hardware/#list-of-supported-hardware [libreboot.org]
(Score: 3, Informative) by The Mighty Buzzard on Monday May 15 2017, @11:05AM
They've got large bits of the ME disabled but not by any means all of it.
My rights don't end where your fear begins.
(Score: 4, Informative) by Hairyfeet on Monday May 15 2017, @11:10AM (2 children)
There is also all AMD chips up to Ryzen (haven't had a chance to look closely at the Ryzen arch layout so I can't say one way or another with those) except for AM1 if you wanted to be ultra paranoid. But the security module in AM1 is disabled, in the hardware itself IIRC (socket AM1 chips are simply the original PS4 and Xbone chips so the security module was for the DRM baked into the consoles) and no software exists that can access the security module on PC so I doubt it would be a threat.
All the rest? No CPU security module and AFAIK there are no AMD motherboards that have any kind of extra modules, the closest that I know of is the Asus gamer boards have an ARM CPU baked on the board to control OCing and power saving called the EPU but it doesn't have any security settings, its strictly power control.
ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
(Score: 0) by Anonymous Coward on Monday May 15 2017, @04:59PM
I thought AMD DASH / AMD PSP was a thing. http://developer.amd.com/tools-and-sdks/cpu-development/tools-for-dmtf-dash/ [amd.com]
(Score: 0) by Anonymous Coward on Monday May 15 2017, @08:03PM
A few earlier chipsets had an lm32 in the SBxx0 southbridge offering the features of the PSP. Don't remember if those were signed or unsigned.
ALL current chips that were produced after sockets G34, C32, AM3+, and I believe the original FM2 have ARM TrustZone based PSPs baked into them, with manufacturer only signed firmware.
Clipper/Palladium/etc is real and has been rolled out into all processors since 2008 or so (When did trustzone first roll out? Earlier if TZ was earlier.)
Having said that: There is a PicoRV32 project that has a a RISC-V core in under 2100 6LUTs, and should be sythesizable in under 4k 4LUTs (IE an iCE40 FPGA). It won't replace an x86/arm for mobile or high performance desktop purposes, but it could be the first step in freeing our systems and ensuring possession plus ownership gives control of the hardware and firmware, even if doing so requires wiping a signing key (this should have always been a write protect jumper feature, just like with flash prior to SPI. Hint: Go read the datasheets on many SPI flash chips (like used in modern computers) many of them implement write protect in software and require software ENABLE of the Write Protect pin on initialization in order for write protection to be active... Kind of defeats the point, doesn't it?