undefined | Better HN

0 pointszkms8y ago0 comments

> I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there.

> If they were more transparent, then they could be used by normal users for remote administration as well.

The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious. There aren't even any robust specifications for it (like those for ISAs); it's literally a black box -- and one granted terrifying access to both the system's internals and external network interfaces.

It's 10PM. Do you know if your ME has been provisioned by evil malware?

I don't care much about whether its source code is public or not, I care about the fact that I have no verifiable and irreversible way to disable that little implant's function. It's not an innocent housekeeping microcontroller, it's one hell of a remote-access-tool, plain and simple. That intelligence agencies have demanded that Intel provide a bit to neuter the ME after its bringup is testament to that.

My personal computer isn't part of an enterprise/corporate network, and I don't want any RAT (nor an auxiliary CPU with network access that is waiting to be provisioned to act like a RAT) installed on it, the same way my house-lock isn't keyed with a master key that the police holds.

I (and most other end-users) do not need any sort of remote-management capability. We need trustworthy and robust computers that are capable of not leaking secrets and losing control to adversaries -- and "remote management" hardware is a severe step backwards from that.

0 comments

6 comments · 2 top-level

jordigh8y ago· 4 in thread

> The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious.

Erm, your fundamental objection is exactly the same objection as it being non-libre. You presented the same argument while trying to distance yourself from it. Maybe you don't like the words "non-libre" or "proprietary" but you certainly seem to be arguing for the same thing that they are arguing for.

> I don't care much about whether its source code is public or not, I care about the fact that I have no verifiable and irreversible way to disable that little implant's function.

Having source code is but a tool towards having the freedom to do what you want with your hardware. I can't see another tool that would also work and give the verifiability that you want.

Again, maybe you don't like the way people argue for it, but you're arguing for the same freedom that others want.

timonovici8y ago

The source code won't give you shit. Even if you have it all, right here, right now:

1. you cannot disable it completely - there's an image of Intel ME, burned into the chipset, which checks for the presence of the ME + AMT in the SPI flash, and it checks for signature. (There's an exception to this, with skylake and above)

2. you cannot run a modified or reverse engineered version of it, unless you have Intel's private key to sign your own binary.

Basically the hardware is tivoized.

jordigh8y ago

Well, source code under GPLv3 would prevent this too. The source code is one building block, but it's not the only one. It does seem like a necessary building block to begin with, though. Otherwise, how could you make the hardware do what you want it to do if you don't even have access to modify what it's currently doing?

userbinator8y ago

Having source code is but a tool towards having the freedom to do what you want with your hardware. I can't see another tool that would also work and give the verifiability that you want.

Access to the firmware binary running on the ME processor and documentation for the latter would be even better than having source, since the latter assumes you trust the toolchain too.

kazagistar8y ago

Auditability and modifyability are different.

rlucas8y ago

If you live in a city apartment, it’s likely locked (at least in part) with a key that the fire department holds. In Seattle in the mid 2000s we had a spate of hundreds of breakins due to ill secured fire dept master keys (in cheap lock boxes).

j / k navigate · click thread line to collapse