Another recent article on HN https://news.ycombinator.com/item?id=8813029 on Intel Management Engine.
CPU Backdoors
31–40 of 51 posts
Re: CPU Backdoors
#32While the main point of the article is interesting, some of the details don't really make sense. For example, it would be difficult to make an instruction like fyl2x or fadd cause a privilege level change. The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. This unit would not have the means to communicate back information such as "change privilege level"…
The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. I don't think that has been true for a very long time. If the backdoor depends on some "magic values", it would be relatively easy to spot just by looking at the microcode. The problem with both your theory and the article's theory is that nobody outside the chip companies themselves really knows how the…
There are so many people involved in the design and manufacturing of a processor, that I don't see how it's possible to hide a backdoor, either in the microcode or during manufacturing. We're not talking about some secret government agency, we're taking about a place with many workers around the world, with different agendas. Eventually someone will find about about the backdoor and leak information about its existence.
Re: CPU Backdoors
#33Wow..light involved in the lithography process causes wear on the lenses? To what degree?
This video, mentioned here, from HOPE, is amazing: https://m.youtube.com/watch?v=NGFhc8R_uO4
Wow, that's like the entire microelectronics class I took in undergrad compressed into an hour, just without any of the math and (obviously) light on theory. Impressive.
Re: CPU Backdoors
#34It seems very unlikely that someone would be able to "apply the edit to a partially finished chip". The adding of a fix like this is probably some of the most scrutinized processes in hardware design. After spending years designing and verifying chip functionality and getting the timing exactly right before production starts there is a very high bar for getting these fixes in to the production flow because if the fix screws anything else up you are FUBARed. Given that, it is probably the hardest place you could ever try and put a back door.
Re: CPU Backdoors
#35While the main point of the article is interesting, some of the details don't really make sense. For example, it would be difficult to make an instruction like fyl2x or fadd cause a privilege level change. The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. This unit would not have the means to communicate back information such as "change privilege level"…
It's not that they're decoded by a seperate unit but that they're executed by it. Still, the values of the two operands aren't going to be available anywhere except that FPU. If the entire design team was in on it you could probably run a signal back from the FPU to the decoder to issue an instruction to do privilege escalation. As for the idea of looking at the value of multiple registers, well, modern OoO CPUs don'…
> having a floating point uOp look at more than two operands would have humungous implications for the architecture.
Actually, in HSW and later all FP ops can have 3 register inputs, they added one to support FMA.
However, this is irrelevant. The scenario basically everyone has been talking about is exploiting a microcoded instruction. In case you are unfamiliar with the term, when the CPU frontend reads in an instruction it deems microcoded, it will stop decoding normally, and instead reads a sequence of ops from the microcode buffer that corresponds to the microcoded instruction you just executed. These ops can be anything the cpu can run -- it would be completely possible to emit a bunch of floating point compares, instructions to and their results, then take this result to the integer flags and do compare and jump on them. And for the longer microcoded ops like fp transcendentals, it would probably be possible to hide all these ops in the shadow of the normal ops, so that there would be no increase in latency.
Re: CPU Backdoors
#36Earlier quoted context omitted.
The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. I don't think that has been true for a very long time. If the backdoor depends on some "magic values", it would be relatively easy to spot just by looking at the microcode. The problem with both your theory and the article's theory is that nobody outside the chip companies themselves really knows how the…
There are so many people involved in the design and manufacturing of a processor, that I don't see how it's possible to hide a backdoor, either in the microcode or during manufacturing. We're not talking about some secret government agency, we're taking about a place with many workers around the world, with different agendas. Eventually someone will find about about the backdoor and leak information about its existen…
> There are so many people involved in the design and manufacturing of a processor, that I don't see how it's possible to hide a backdoor, either in the microcode or during manufacturing. We're not talking about some secret government agency, we're taking about a place with many workers around the world, with different agendas.
However, the end result of both CPU design and the microcode team is essentially unreadable.
No-one outside Intel can read their microcode updates, as they are obfuscated in some way, possibly encrypted. This means that compromising just the last step, the people or tools doing the obfuscating, means you can output whatever you want with no-one on the team being able to find it out.
The same is true for the CPU design. Created masks are generally not looked at, other than to verify small spots if it seems there are bugs. Because of this, compromising the last step between the model and the mask would allow you to output whatever you want with no-one of the thousands of the people working on it ever finding out.
Re: CPU Backdoors
#37Earlier quoted context omitted.
It's not that they're decoded by a seperate unit but that they're executed by it. Still, the values of the two operands aren't going to be available anywhere except that FPU. If the entire design team was in on it you could probably run a signal back from the FPU to the decoder to issue an instruction to do privilege escalation. As for the idea of looking at the value of multiple registers, well, modern OoO CPUs don'…
> having a floating point uOp look at more than two operands would have humungous implications for the architecture. Actually, in HSW and later all FP ops can have 3 register inputs, they added one to support FMA. However, this is irrelevant. The scenario basically everyone has been talking about is exploiting a microcoded instruction. In case you are unfamiliar with the term, when the CPU frontend reads in an instru…
Oh, I see. I hadn't recognized that fyl2x was a microcoded instruction. Looking at the page again I totally missed the footnote and he's completely right.
However, for FMA I assume that they break the FMA instruction into two uOps that have to be issued back to back to the same execution unit. The changes to the reorder register renaming logic would be just too painful otherwise, especially since Intel uses a unified scheduler which also handles the integer ops.
EDIT: I suppose that I tend to forget about microcoded instructions since none of the instruction sets I've worked with directly has really had them.
Re: CPU Backdoors
#38An obvious place for a backdoor is in remote management CPUs embedded in the network card. http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf Network cards which support RMCP/IPMI protocol are obvious points of attack. They can reboot machines, download boot images, install a new OS, patch memory, emulate a local console, and control the entire machine. CERT has some warnings: https://www.us-cert.gov/ncas/alerts…
Absolutely. NICs in general are a very fruitful vector for persistence, and had been extensively studied by the NSA. Generally, anything with a microcontroller that might run firmware (BIOS or UEFI), access DMA (via PCI, PCIe, FireWire) or be a storage peripheral that might pass code to the boot process (HDD/SSD/CD/DVD/BD/Flash drive/memory card firmware, including USB) or input (USB) is a potential problem. That is…
Supply chain integrity is a huge, possibly unsolvable problem.
One of the arguments for domestic manufacture of at least some keystone parts, and one of the reasons IBM is still in the fab business.
Re: CPU Backdoors
#39While the main point of the article is interesting, some of the details don't really make sense. For example, it would be difficult to make an instruction like fyl2x or fadd cause a privilege level change. The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. This unit would not have the means to communicate back information such as "change privilege level"…
It's not that they're decoded by a seperate unit but that they're executed by it. Still, the values of the two operands aren't going to be available anywhere except that FPU. If the entire design team was in on it you could probably run a signal back from the FPU to the decoder to issue an instruction to do privilege escalation. As for the idea of looking at the value of multiple registers, well, modern OoO CPUs don'…
If the entire design team was in on it...
If that's the case you could probably do just about anything...
Re: CPU Backdoors
#40Earlier quoted context omitted.
1. You design your CPU so whenever you execute an add instruction with $r1 = x, $r2 = y (say these are the add inputs), the next add instruction will switch to ring-0 mode and run code at address which is the result of the add. 2. You don't need access to the box. You just get the target to load a site with JS that sets x and y to those specfic values and adds them, and then adds zero to some address you want to exec…
If you're really being nasty you can potentially do this even without JS - say, by using CSS layout.
But can one predict how CSS will look to the CPU? Or do you assume a memcpy will happen at some point, and catch it then?