Hacker News Reader

Comment by trengrj | Hacker News Reader

Does an Open Compute Future include Intel's ME?

Intel's Management Engine (which is on all modern Intel chips) acts as a unverifiable second processor with memory and network access running closed proprietary software. Its existence prevents any sort of security from state level actors.

View on HN

Woah, I didn't know this existed! This is really serious. Why aren't people talking more about this?

Discussions about it do exist. I first read about the dangers of it via the Libreboot website. As for why it hasn't had mainstream coverage, your guess is as good as mine.

In case anyone wants a CPU + FPGA combination without this type of security risk, check out Zynq.

I'm not convinced Zynq is much better. They just move the MElike functions on-die and call it TrustZone.

TrustZone is not equivalent to Intel ME. Software must be designed to work with TrustZone extensions, and that software is under the control of the user (as long as you run open-source operating systems). If the software you're running doesn't use any TrustZone extensions, then the TrustZone hardware will not be used.

Intel ME on the other hand is baked into the hardware, and AFAIK can't be properly switched off, it appears the best you can do is set up a fake Intel MPS Server to point it to:

https://software.intel.com/en-us/forums/intel-business-clien...

There was a CCC talk about it recently https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor... and there is a good write up about it on Libreboot site https://libreboot.org/faq/#intelme.

With regards to why people aren't talking more about this, maybe fatalism is involved as it seems there is a certain inevitability that whoever controls the silicon also controls to some extent computers. There have been some interesting developments in people trying to create open hardware like lowRISC http://www.lowrisc.org/ and also using ARM so there is some hope in this area.

Intel ME has very useful legitimate purposes for existing. It's a very powerful tool for some people, and most people would call you a conspiracy theorist for suggesting that Intel, or someone who manages to get security creds from Intel, would misuse them break into your computer. I have also had allegedly advanced system engineers tell me that there is really no risk for an outside party being able to compromise your system with this technology, but I remain pretty skeptical of that claim.

In short, the overlap between people who know about it and are also security conscious is pretty small. There's also dozens of other things people should be more concerned about in terms of a corporate or state actor gaining unauthorized access to your computer.

I am much more afraid of non-state actors that would get access to back doors than state actors. The people at the NSA might not be angels but they have some sense of ethics and some controls, other people out there don't. What if someone like Snowden or the Walker brothers get access to it and make it open source or sell it to ISIS?

Well, AMT has been around since about 2005, and vPro since 2007. It's a favorite topic for some people on Slashdot to bring up. There's a hackaday article from about 2 months ago [1]. My theory is that it's a combination of factors.

- Introduced a long time ago; it's old news.

- It is talked about, but only in certain circles

- Confusion over the relationship between vPro, IME, and AMT, or at least unfamiliarity with those terms making articles/discussions related to them less likely to pop out as interesting topics.

- Some of the people who know about it consider it the normal, boring, status quo, and they react to anyone shocked by it as an alarmist.

[1]: http://hackaday.com/2016/01/22/the-trouble-with-intels-manag...

Is that anything like the "secure enclave" we've heard so much about re: Apple iPhone, at least the current versions? Not sure how much benefit or utility that would add to a server vs. phone CPU, but it's interesting anyway.

IIRC the secure enclave equivalent on x86 is the TPM module, and/or Intel SGX and AMD's Secure Processor (using a secondary CPU running ARM TrustZone); both are independent of Intel's ME.

Confused yet?

The TPM (where present) is analogous to the secure enclave, although the mechanism is a bit different. The ME is more of an "insecure exclave": it has a lot of access to the rest of the system, but the OS and userland cannot use it for anything useful. It's designed to allow access from outside over the network connection. Useful for ILM systems, but very frustrating for people who aren't in a datacenter and don't like it being there.

No, it's IPMI on Desktop processors

Thanks for the clarifications. Indeed is confusing for those of us not so hardware savvy.

Implement x86 on FPGA; what now NSA! :D

Backdoor the FPGA...

When in doubt, backdoor the compiler.

FPGAs have something akin to a bootloader which is used to download the bitstream. There has to be some intelligence in order to reconfigure the hardware on it. That something is firmware running on a tiny core. So basically it's already backdoored :-).

Covertly backdooring arbitrary hardware on an FPGA seems orders of magnitude more complex than sneaking a backdoor into a feature designed to have DMA and network access.

IMHO, it's not significantly harder, at least in principle, than on other platforms - in fact, albeit intuitively, I suspect it's easier.

Most high-end FPGAs aren't "burned" the way you would with a logic array by burning fuses. Configuration data (i.e. the connections between the FPGA's tiny components) is stored in a non-volatile memory and is loaded when the device starts. Altering the design is simply a matter of altering this configuration data, which is easy to do dynamically, seeing how there's a closed piece of code running on a closed module which has access to every bit of it.

The problem ends up being boiled down to problems that we're already aware of: authenticating configuration data (which is akin to the problem of authenticating the OS running on a general-purpose CPU), ensuring that the FPGA's configuration matches that which was programmed in the non-volatile memory an so on.

The configuration data loader is, to the best of my knowledge, a pretty trivial piece at the moment, with the exception of high-end devices for sensible applications (which do include things like encryption, so that the bitstream cannot be retrieved in a useful form). But real-world requirements will soon provide a good excuse for inflating it to a level of complexity where backdoors can be hidden.

It's also important to realize that much of the hardware that ends up on an FPGA isn't really arbitrary data, it's in the form of vendor-supplied IPs that are probably pretty easy to recognize. Implementing your own cryptography hardware is as bad an idea as writing your own cryptography code. It don't think it would be too hard to backdoor a loader that alters the bitstream so that its crypto modules are weak, under specific circumstances.

Some FPGAs might. All the Xilinx ones that I have used need to be explicitly programmed from outside, usually via SPI.

Not sure which Xilinx parts you've used (older ones?), but all of the modern ones can be strapped to load a bitstream from various types of flash on powerup. See Xilinx UG380 for details for the Spartan-6 family:

http://www.xilinx.com/support/documentation/user_guides/ug38...

This is the master plan, but replace x86 with RISC-V to make it more efficient. It's impractical for economical reasons to backdoor the FPGA (where's the IO? You don't know.) nor the compiler (Hey, all I see is a netlist, my AI isn't that clever).

Reply on news.ycombinator.com