5 ms·
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 mem
by trengrj 11y ago
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.
- jrapdx3 11y agoIs 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.
- creshal 11y agoIIRC 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?
- pjc50 11y agoThe 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.
- windowsworkstoo 11y agoNo, it's IPMI on Desktop processors
- jrapdx3 11y agoThanks for the clarifications. Indeed is confusing for those of us not so hardware savvy.
- Ericson2314 11y agoImplement x86 on FPGA; what now NSA! :D
- Natanael_L 11y agoBackdoor the FPGA...
- creshal 11y agoWhen in doubt, backdoor the compiler.
- notalaser 11y agoFPGAs 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 :-).
- tlrobinson 11y agoCovertly 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.
- notalaser 11y agoIMHO, 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.
- moonbug 11y agoThis place is sounding more like Slashduh every day.
- Dylan16807 11y agoDo you have an actual criticism of the comment?
- eloff 11y agoMore so with your contribution.
- winter_blue 11y agoWoah, I didn't know this existed! This is really serious. Why aren't people talking more about this?
- ZenoArrow 11y agoDiscussions 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.
- subway 11y agoI'm not convinced Zynq is much better. They just move the MElike functions on-die and call it TrustZone.
- ZenoArrow 11y agoTrustZone 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-client-software-development/topic/563988 https://software.intel.com/en-us/forums/intel-business-clien...
- trengrj 11y agoThere was a CCC talk about it recently https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops 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 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/ http://www.lowrisc.org/ and also using ARM so there is some hope in this area.