Custom Processing Unit: Hook, patch, and trace microcode at the software level | Hacker News Reader

Custom Processing Unit: Hook, patch, and trace microcode at the software level

github.com

75 pointstodsacerdoti18 comments

One of my first paid gigs was to write a debugger for a RIP implemented in 2900 bitslice. It was a specialized SIMD architecture. The debugger was written in C and ran on the bootloader processor, which I recall being a 68k. Having taken an architecture course as an undergrad I sort of knew what I was doing, and microcode is inherently simple compared to, for example, 64-bit x86. I recall thinking "this is what a really wide PDP-11 would be like." The project was also interesting in that my customer was one person: The guy who designed the processor and who was writing the microcode.

I sometimes wonder if not these CPUs are just waiting to have their power unleashed. Almost like FPGAs, they could be reprogrammed to have custom instructions by someone skilled.

This wouldn't actually help in common workloads, because the instructions that already exist are typically better than what you can achieve with microcode.

The reason for the RISC revolution was the understanding that there are fairly strict limits of what you can achieve in a single instruction if you want your cpu to be fast. An instruction that does some complex task that you need done is not really going to be any faster than composing the same action out of RISC instructions because, thanks to pipelining, the limiting factor on the speed of your cpu is going to be the actual work anyway.

Microcode on modern x86 cpus is typically slower (takes longer to output uops, outputs less per clock than the uop cache) than simple instructions, and only exists for legacy and doing some complex operations (like context switches) where being uninterruptible and having a bit of extra scratch space is useful.

It makes sense what you say, but I still have doubts. Are you saying that not all x86 instructions are implemented in microcode? And wouldn't shader language be a perfect target for custom microcode, etc.

> Are you saying that not all x86 instructions are implemented in microcode?

If you look at discussions about the instruction decoder of Intel processors, you often see it mentioned that they have something like three "simple" decoders and one "complex" decoder. The main difference is that the "complex" decoder is the only one which can decode instructions implemented in microcode (dispatching micro-operations from the microcode ROM), while the "simple" decoders can only output micro-operations directly (using something similar to hard-wired pattern matching on the instruction). So yes, many x86 instructions are not implemented in microcode.

The term microcode has become muddled in that you have microcode for implementing highly complex instructions and "microcode" as-in an internal target that X86 instructions are translated into.

The internal instruction format is commonly called micro-ops / uops. But easy to confuse those terms.

I know, however lots of people make it up as they go along.

Could one add the AES-NI instruction to Intel CPUs that lacked it using purely microcode? Would it be a speedup compared to encoding one round of AES using regular instructions?

These already exist in niche markets, they've stayed niche for a reason

I assume this does not support AMD? Or even a broader & better question: does AMD even have such undocumented instructions that allow the 'takeover' of the CPU?

This, like also some reverse engineering of the CPU microcode that has been discussed previously on HN, is supported only on certain Intel Atom CPUs with Goldmont cores, i.e. Apollo Lake, Gemini Lake, maybe also Denverton.

The reason is that only for these cores there is a known exploit that can switch the CPU of any computer with this kind of core into a debugging mode that gives access to the microcode.

Similar debugging modes certainly exist on all Intel and AMD CPUs, but there is no public knowledge about how they can be activated and no known bugs that enable that. Moreover, this debugging mode is normally disabled on the PCB in production motherboards. So even for someone who would know how to do it for other kinds of Intel cores or for AMD, it is expected that physical access to the motherboard is needed, to make modifications on the PCB.

While this new information about the internals of the Intel Goldmont cores is very interesting, it does not increase the chances of any similar hacking of the other more modern Intel cores.

It is likely that Intel will be more careful in the future to avoid such a reverse engineering of the microcode and of the debugging mode, even if that does not really matter much, either for security or for competitors.

There has been some older work on reversing AMD K8 and K10 that lets you do something vaguely similar. This work is just way more generalized, with more options available in the Intel way of things. https://www.usenix.org/conference/usenixsecurity17/technical...

Seems like you can't really trace the AMD CPUs like the reversing of that Intel Microcode allows, but you can still do a lot.

Does this help us getting rid of IME?

You meant ME? Maybe, they do refer the use of HAP mode on the linked article (Goldmont's Red Unlock) BUT I think the ME platform is required for useful, needed things along the unneeded ones, so I think in the end, you always need a subset of Intel ME working.

You want to inspect the management engine not replace it.

The management engine does do useful stuff the issue is that we don't know what else it does too.

Can someone please explain to me like I'm a 5yo; Why, if at all, this is significant? It "seems" significant, but no real idea, TBH.

NOTE: I just skimmed very quickly the article and the linked article referring JTAG.

I believe it is providing tools which allow running the Intel CPU in a way equivalent to running a regular program on GDB. It may be possible to use a JTAG but not sure if it is a requirement.

Reply on news.ycombinator.com