5 ms·
Apple might want to talk to IBM about OpenPOWER. The POWER8 chips and chipsets lack known internal micro controllers that have their own flash unlike Intel's ch
by ryao 11y ago
Apple might want to talk to IBM about OpenPOWER. The POWER8 chips and chipsets lack known internal micro controllers that have their own flash unlike Intel's chips that have the Intel management engine. Consequently, there is nothing there to flash with malware. Also, all of the system firmware is open source. That is the motivation behind the Talos workstation board, provided that they get enough interest for an initial run:
https://raptorengineeringinc.com/TALOS/prerelease.php https://raptorengineeringinc.com/TALOS/prerelease.php
If Apple is concerned about tampering enroute, they could have the flash chips for the system firmware provided separately by a trusted party and transported like a bank shipment. Then flash and install them at the datacenter. That should thwart adversaries who cannot do their own manufacturing runs of modified versions of the chips, which is just about everyone. I guess the manufacturer/fabrication plant could do a custom compromised chip, but given that the costs involved are prohibitive, I doubt that would happen.
Apple could do the same with the firmware and flash for every other component in their datacenter that has a microprocessor such as the hard drives, the NICs, etcetera. They are large enough that part manufacturers would likely turn over the source code for their firmware in order to secure their business along with anything else that they need/want.
- avn2109 11y ago>> "...transported like a bank shipment..." If you think the NSA/state level adversaries have not penetrated bank shipments, you are dangerously naive. Instead, maybe transport it like the CIA moves the communication hardware for its quiet rooms, or like the Russians move the bugs destined for US embassies. Apple is interesting because it's one of the few organizations that could plausibly do this.
- ryao 11y agoI said bank shipment because I did not know of a more secure way of transporting a high value target. :/
- zdkl 11y agoICBM-deliveries, guaranteed untampered with if on time!
- hammock 11y agoWhat is a quiet room?
- junto 11y agoI think OP is making a reference to TEMPEST: https://en.m.wikipedia.org/wiki/Tempest_(codename) https://en.m.wikipedia.org/wiki/Tempest_(codename)
- PeCaN 11y agoI think Apple would probably just use ARM chips; they already have the license and they have lots of experience designing their own. OpenPOWER is awesome though. I'm hoping Talos will get enough interest; I'm ready to throw money at them if it succeeds. POWER chips are super good, I don't know how IBM has managed to keep up with Intel's R&D but they're definitely competitive in performance. 1. http://0pf.org/j-core.html http://0pf.org/j-core.html
- ryao 11y agoI doubt Apple would go so far as designing a low volume server processor for their datacenters. It is probably not cost effective. Apple reusing their iDevice SoCs in microservers could work though. The A9 has PCI Express lanes for NVMe flash that could be used to add wired networking and storage while the secure boot and code signing would allow them to build a microserver that only runs their code. This arrangement would also be incredibly cost effective for them. They would want to give their SoCs have properly protected internal data paths and the necessary logic for ECC RAM before using them in micro-servers if those chip features are not already there though. If they are, I doubt that the ECC is being used in their iDevices.
- rdancer 11y ago> I doubt Apple would go so far as designing a low volume server processor for their datacenters. It is probably not cost effective. They have the luxury of having enough cash, and enough profitability, to do things that have negative ROI. The recently concluded lawsuit comes to mind — there was no business case for not settling it at the earliest. They didn't settle at all, and took it to the US Supreme Court. And if a secure architecture requires a custom-designed backend server farm, they can do it, and even probably make it revenue-neutral, by re-introducing the Xserve product line. I don't think they will do a full-blown custom design, and the advantage of having their own hardware stack is that they can leverage existing technology, and make a few tweaks. And they must have been running at least designs on this possibility, because they do want to take notebook/desktop processor manufacture in-house in the medium term, and end reliance on Intel.
- bogomipz 11y agoDoesn't the management engine exist as part of the BIOS on the same NAND? Couldn't Apple simply have Intel give them a custom BIOS that is signed?
- pgeorgi 11y agoGroups more powerful than Apple tried to convince Intel to give them the opportunity to run only their own custom code on those Intel-signed areas of the processors they buy. What seems possible is running code on top of and in addition to the existing system, see CompuTrace. This isn't "simple" except perhaps for some US (and US only, by virtue of Intel being head-quartered there) agency with huge procurement budgets and persuasive legal instruments, and I'd expect push-back even then.
- ryao 11y agoWhy would they need to convince Intel when they could infiltrate them for what they want?
- pgeorgi 11y agoIf you infiltrate, with luck you get a half-assed data sheet. If you coerce them (with those persuasive legal instruments) you get minimum compliance to keep people out of jail. If you actually get some cooperation established, I'll guess that gives a much better support experience.
- ryao 11y agoIf you are willing to throw resources at deciphering things, infiltration could be all you need.
- ryao 11y agoI have been told by the CoreBoot developers that it has its own separate flash inside the chipset. There is definitely something loaded by the BIOS though.
- adrianN 11y agoThis is an interesting talk about Intel's management engine: https://media.ccc.de/v/32c3-7352-towards_reasonably_trustworthy_x86_laptops https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor...