Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's like saying you can't call Linux open source because it bundles closed firmware for WiFi, for example...

The ME could certainly still be active, that is true, but with modern x86 platforms attempting to disable the ME or PSP using the documented method is the best that can be done.

A very large amount of the work the firmware does is done by open source code in either Coreboot, EDK2, or the System76 firmware applications. It is my opinion that this definitely does count as open firmware.



With nonCPU blobs there is (usually) a memory boundary. Would the bus between the devices be exploitable? Perhaps, but at least it could be hardened, which is not the case with the ME controller. How much the ME controller actually participates in the boot process is irrelevant as long as its position within it can completely and undetectably compromise the entire system.

You should look at the libreboot project and read their blurb on why they do not support post-2013 processors.

Trying to sell the devices described as open is harmful to the term. They're not. Perhaps the only devices which are at this time are the IBM POWER processors and the Raptor CS motherboards, discounting any silicon backdoors, and in the case of the Raptor motherboard, the ASpeed BMC.


Anything that you connect to the system bus can compromise the system.

Of course, ME has easier time doing that. But any ROM you can't inspect, any binary blob you load can do that.

I suppose that if you want this level of impenetrability, you have to go with everything custom. Could your memory controller scheme against you and alter RAM contents when a backdoor pattern is encountered? Do you trust IBM to not put a backdoor or a kill switch in your POWER9?

Implement your CPU, memory, bus, and disk controllers, NIC logic, etc, in FPGA. Build your own RAM with controllers you program, don't trust DIMM manufacturers. Write your own or adopt open booting software, same with firmware for the peripheral devices.

You'll get a very high security computer where a backdoor has basically nowhere to hide.

Alas, it won't fit the restrictions of a laptop.


This might be a stupid question, but would adoption of RISC V help fix this issue?


> would adoption of RISC V help fix this issue?

If you're in the market for some slow CPU, maybe. For high performance stuff the creator will likely have to license some function blocks that come with strings attached.

I'd love to see a fully open RISC-V core with a DDR4 interface (and USB2/3 for all kinds of interfaces), but somehow I just don't see that happening before DDR4 is all but obsolete: those interfaces aren't trivial to build (so that they work with all kinds of stuff) and few folks have the equipment to test their Verilog (or whatever) that would implement these high speed controllers against real devices.


For my secure computer, yes please. I don't care how many extra milliseconds (or minutes) it takes to make a cryptocurrency transaction.

I do care that the in-memory key can not be read and transmitted without my OS' knowledge.

I have other computers for games and development and servers, and the NSA can have my steam password and already have my work email.


Not really. Closed firmware exists for reasons that aren't x86-specific so almost all ARM and RISC-V systems will have some form of closed firmware. One problem with x86 is that it's limited to ~3 companies while any company can use ARM or RISC-V so more diversity is possible.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: