> on the good side of things, getting an Intel CPU to enter the red state is not easy to accomplish. In fact, it should never happen unless there are vulnerabilities in the Intel Management Engine (ME), an almost undocumented subsystem present in all Intel CPUs since 2008 that Intel says is required to provide full performance.<p>"unless there are vulnerabilities or backdoors in the Intel Management Engine (ME)".<p>There, fixed it for you.
My initial guess was "WRMSR, and the 64-bit version of WRMSR". Fortunately, this appears to be an actually new finding rather than the memorable case a few years back of someone claiming to have discovered something that was clearly documented in the datasheet.<p>The whole idea that there's a "red state" and a bunch of others on a CPU, normally hidden, should immediately raise the attention of many who wonder what those extra modes can do, and more interestingly, why they're hidden. From the (very little!) research I've done, it appears this is not unlike SGX where <i>only Intel</i> has the key[1] to some part of the hardware you bought from them, and based on some leaked internal documents, it's very plausible that this is indeed a backdoor which only they can use. Ostensibly, for debugging purposes. Here's a previous comment I made on this: <a href="https://news.ycombinator.com/item?id=26521359" rel="nofollow">https://news.ycombinator.com/item?id=26521359</a><p>[1] If these keys were leaked, which I very much hope will happen at some point, no doubt the "security" community will be heavily against it and spread plenty of FUD about how it makes everyone's computers insecure. But IMHO it should be eagerly awaited and received with the same optimism as the other DRM key leaks (HDCP, HDDVD, etc.) --- it is a path to freedom.
It's interesting that they submitted a paper for a talk at BLACK HAT USA 2021 but were rejected [0]. Looks like geopolitics (and politics) has permeated every aspect of technology.<p>[0] <a href="https://twitter.com/h0t_max/status/1397441062705057793" rel="nofollow">https://twitter.com/h0t_max/status/1397441062705057793</a>
The article is based on the same tweet as this discussion from 3 months ago:
<a href="https://news.ycombinator.com/item?id=26519693" rel="nofollow">https://news.ycombinator.com/item?id=26519693</a><p>I also want to state how impressive their work is.
These are the true undocumented instruction finders as apposed to sandsifter.
Rejected? Not a problem. Upcoming talks on Red Pill for Intel Atom.<p><a href="https://zeronights.ru/en/reports-en/chip-red-pill-how-we-achieved-to-execute-arbitrary-microcode-inside-intel-atom-cpus/" rel="nofollow">https://zeronights.ru/en/reports-en/chip-red-pill-how-we-ach...</a>
In theory this should open possibility to unlock all the market segmentation gated Intel bullshit like ECC, AVX, multiplier change overclocking, etc. Maybe even manipulating CPUID.
TL;DR<p>1. If you control Intel Management Engine (exploit/backdoor/whatever), you have full control over the system.<p>2. That full control comes with, among everything else, the ability to put the CPU in a deep debug state ("Red Unlock")<p>3. In Red Unlock, you can basically play with the CPU's internals at will using a debug cable (just a modified A-A USB3 cable on many modern systems; "DCI").<p>4. It turns out that in Red Unlock state there are also undocumented instructions that let you do the same thing straight from code running on the CPU itself.<p>Notice how the security relevance stops at #1. We already know that if you control ME, you control the system. So there is no security impact to this discovery. The prerequisite is already total control.<p>Also notice how what these instructions let you do isn't new. The same researchers already showed how to do the same thing via an external debugger (CRBUS access) last year. So this does not open any new capabilities for CPU research.<p>What it does do is make things more convenient. Now you can do this without an external debugger, "only" with an ME patch/exploit and code running on the system itself, which means you could e.g. have it apply custom microcode patches on every boot (by patching your UEFI firmware to do it). Also, the USB debug thing doesn't work on all motherboards (some are missing the required connections), while this would work.
> it allows to craft your own persistent microcode patch without external debugger.<p>These are <i>persistent</i>? Meaning they survive reboots? Is it stored in flash memory on the CPU or something? I thought all microcode updates are re-applied on each boot.