Intel Microcode Decryptor
github.com
github.com
Two Hidden Instructions Discovered in Intel CPUs Enable Microcode Modification
Is it even possible to fully decode that language with publicly available information/tools?
Given that microcode is an internal mechanism of CPUs, I would expect its language to be impossible to decode for regular people because there is zero knowledge on how it works?
And even if there is some knowledge on it, won't Intel change the machine language around a lot among CPU generations because the lack of public usage means it can be changed constantly, thus rendering the existing knowledge useless quickly?
I have a couple of quarks, never used them.
Changing things around is expensive, even if they don't have external compatibility obligations.
Seems logical that it would be mostly be standard machine code, since there are instructions which translate 1:1 to microcode (I assume) no use translating everything, that’d require more space and be harder on everyone for little reason.
Though there might be privileged instructions which would only be available in microcode (would be rejected by the frontend), and which you would have to reverse-engineer separately.
The mirocode is generally a sequence of uOps. But in Intel's case, there seems to be a more complex mechanism, called XuCode, that generates the uOps sequence. The XuCode ISA seems to be based on x86-64, as Intel says [1]:
> XuCode has its own set of instructions based mostly on the 64-bit Instruction Set, removing some unnecessary instructions, and adding a limited number of additional XuCode-only instructions and model specific registers (MSRs) to assist with the implementation of Intel SGX.
PS: Decoding of the XuCode microcode can potentially give precious information about uops encoding
PS2: You can find more information on uops encoding in another work from the same team [2].
[1]: https://www.intel.com/content/www/us/en/developer/articles/t...
https://www.intel.com/content/www/us/en/developer/articles/t...
What this seems to be is:
- Intel CPUs with SGX have an additional CPU mode that understands and runs XuCode, "XuCode is implemented as a variant of 64-bit mode code, running from protected system memory, using a special execution mode of the CPU."
-- I know that "ring" terminology is used to describe CPU modes, e.g. calling a hypervisor setup ring -1, SMM ring -2, and the Intel management engine ring -3. Seems like this mode is something like ring -2.5.
- "It is authenticated and loaded as part of a microcode update and is installed into a Processor Reserved Memory (PRM) range, typically allocated by system firmware. The memory range itself is protected from software and direct memory accesses by the Processor Reserved Memory Range Registers (PRMRRs)."
So the BIOS steals a bit of your RAM (which the ME already does), sets it up to be the PRM, and a microcode update unpacks XuCode now contained in the microcode data, and puts it in this PRM. I guess some SGX instructions are essentially a specialized form of INT instructions that "exception out" specifically to this special CPU mode/PRM space.
So I'm under the impression XuCode is essentially called by the microcode when certain SGX instructions are encountered.
Weird ...
Each microinstruction is composed of many bit fields, which contain operation codes, immediate constants or register addresses.
The format of the microinstruction is changed at each CPU generation, so, for example, the microinstructions for Skylake, Tiger Lake, Gemini Lake or Apollo Lake have different formats.
Therefore, someone who discovers the microinstuction format for one of them has to repeat all the work in order to obtain the format for another CPU generation.
In the presentation from
https://www.youtube.com/watch?v=V1nJeV0Uq0M
the authors show the microinstruction format for Apollo Lake, which is a kind of VLIW (very long instruction word) format, encoding 3 simultaneous micro-operations, each of which can contain three 6-bit register addresses and a 13-bit immediate constant.
For Apollo Lake, the microinstruction encoding is somewhat similar to the encoding of an instruction bundle (containing 3 instructions) in the Intel Itanium processors.
It is likely that in the mainstream Intel Core or Xeon CPUs the micro-instruction format is significantly more complex than this.
The team which reverse-engineered the microinstruction format was able to do this because they have exploited a bug in the Intel Management Engine for Apollo Lake/Gemini Lake/Denverton to switch the CPU into a mode in which it allows JTAG debugging.
Using JTAG they could read the bits from some internal busses and from the microcode memory. The bits read were intially meaningless, but by executing many test programs and comparing what the CPU does, with the bits read at the same time via JTAG, they eventually succeeded to guess the meaning of the bits.
For most Intel CPUs, there is no chance to switch them into the debugging mode, unless you receive a secret password from an Intel employee (which probably is within the means of some 3-letter agencies).
Once switched into the debugging mode, it is possible to do things as complex as making the CPU to replace the normal execution of a certain instruction with the execution of an entire executable file hidden inside the microcode update (and you can also update the microcode directly, bypassing the normal signature verification step).
However, for most motherboards, it is likely that switching to the debugging mode also requires physical access to change the connection of some pin, not only the secret password, though exceptions are known, where the MB manufacturers have forgotten to disable the debugging mode on the PCB.
Phone calls are easier.
Getting a dump means getting access to a memory controller of sorts and asking it to read you back the contents of addresses, right?
But you’re really getting what the memory controller decides to give you. There could be more indirection or sneakiness, right? Ie. I could design a memory controller with landmines, as in “if you ask for 0x1234 I will go into a mode where I send back garbage for all future reads until power is cycled.”
Is this a thing?
However the way they obtained these dumps is by going deep into debugger mode of the cpu which makes me doubt anything spooky would be going on.
Someone screwing some C code and creating a vulnerability isn’t that interesting to me, but going on such low level and fundamental stuff makes me giddily, if not a bit scared.
Last time something like this caught my eye was that iMessage[1] NSO thing, not because they managed to escaped the sandbox, but because of the insanely clever way they did it.
[1] https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
I was so excited to try out sandsifter I spent an entire night shift compiling everything on a raspberry pi or rockchip.
Sandsifter is an x86 instruction dumper. Sometimes I wonder if the head injuries I took as a teen affected me in a subtle way, because I did watch the entire sandsifter presentation where he repeatedly says x86.
He also has a cool presentation about ring -1, -2, and beyond, of which the reader for that stuff was what I figured was used to find the actual OP.
Yes, here the memory is read through a debug bus.
> I could design a memory controller with landmines, as in “if you ask for 0x1234 I will go into a mode where I send back garbage for all future reads until power is cycled.”
Yes, it basically looks like a backdoor, and you can do it the other way around: The memory read through the debug bus is exactly the content of the ROM, but the memory controller is made so that when the processor reads a specific address or data it doesn't return the value in memory but something else.
This way even a person who would use a visual or an intrusive memory extraction method would not notice the backdoor. The only way to discover it is to do a full inspection of the logic, which probably nobody will do.
> Is this a thing?
Yes, sometimes some addresses in a memory system are effectively not readable (write only). As for example with some memory-mapped configuration registers, a 0-value may be returned instead of the register contents.
But your question sounds to me more about mechanisms to hide a backdoor.
Regarding hardware backdoors, they are always theoretically and practically possible, and almost always undetectable. Since nothing prevents the designer from introducing logic that has malicious behaviour and it's nearly non-observable.
This is the problem with theories about backdoors in modern processors. Without evidence, these theories fall into the realm of conspiracy theories. But it's almost impossible to have evidence and no-one can say that it doesn't exist.
except for intel, if they publish how their hardware and microcode works internally? aka, opensourcing their internal design?
Of course, they can't since it will allow competitors to copy it, but would that work theoretically?
Even if they released absolutely everything, there's no way to verify that the chips they actually make and sell conform to a design that they release without inspecting the actual chip. If you're really paranoid, you'd have to inspect every chip, and that's usually a destructive operation.
And here's the million dollar idea, to verify you'd need to destructively inspect your chips at EOL to verify you haven't been screwed over. Anyone wants to start a business?
it only protects against backdoor injection by the fab (or the company that produces your masks)
And there are other solutions such as logic-locking.
The idea of logic-locking is to add XOR gates (or a more complex type of gate) to the circuit on well-chosen logic paths. To make the circuit behave correctly, it's required to know the value to be sent to each inserted XOR. These values may be generated by an RNG circuit that is seeded by a secret key.
At manufacturing time the key is kept secret, so it's not possible for the fab to reverse engineer your circuit logic to introduce a backdoor.
Once production is complete, the key is loaded into circuits for sale
If I'm understanding correctly, this allows us to view (previously obfuscated) code that runs on certain (recent-ish) Intel processors?
What are the consequences of this?
Yes, but this "code" is the Intel microcode.
In a modern processor, instructions are translated in a sequence of micro-operations (uOps) before execution; These uOps are small instructions that the processor can execute with more ease. Ultimately, this allows to build more performant processors.
But some instructions require translation into a uOps sequence that is too complex to be handled like other instructions. Modern processors therefore feature a "microcode sequencer", and the "microcode" is the configuration of this component.
And this work allows us to interpret a previously misunderstood part of the microcode.
> What are the consequences of this?
There are no real direct consequences for users.
But this helps to better understand how modern Intel processors work; Especially security researchers will be able to better understand how some security instruction works (mainly the SGX extension). In the long term, they may find Intel errors (as has already happened previously) which will be fixed in next Intel processor generation.
Although security issues may be detected in Intel processors, this will probably have no impact for normal users, but it could affect some companies.
As in, there may a possibility for almost every computer being vulnerable to a RCE that bypasses even the OS.
Intel microcode can be loaded at runtime. If there's a backdoor in the microcode then it can, by definition, be patched.
h0t_max’s research means that future attacks — once your local machine has been infiltrated by some other means — can do a lot more damage than simply encrypting your filesystem or sending spam. They can rewrite the way your CPU works.
When your OS gets attacked by malware it is attacking the layer above the bare metal on which your OS runs. The base hardware remains untouched. You can at least clean things up by installing a new OS on the bare metal.
If malware attacks the bare metal itself, then you are stuck out of luck.
If the malware shuts that patching off...
Reality: nobody cares.
I'd like to talk about how we patch this pervading cynicism and replace it with a model that's actually useful.
It isn't true on face value. Consider the course of the Cov19 pandemic. Two things spread. One was a virus. The other was an idea, news about a virus. The latter spread much faster than the former. It spread because people love "doom". Any story about the impending "end of everything" is lapped up, relished and shared by the public.
There are well understood stages to information propagation. After "Is this real?" and "Am I affected?" comes the question of "what to do?"
I think this is where your assertion about "care" comes in. Some events will blow-up and burn out fast. People run around like headless chickens enjoying the drama about something remote to their lives, but ultimately nobody can do anything, so focus recedes. Wars and famines are like that. Curtis calls this "Oh Dearism".
Alternatively, if there is any residual effect, new events connected to the initial story, it feeds and grows. The initial "All the chips are broken!" story that would die after a 24 hour news cycle becomes an ongoing "situation". Then people care, because it's cool to care. It gets a catchy handle "Evil-Inside" and a news slogan "The chips are down". And then it won't go back in the bottle.
To reformulate your "Nobody cares" - as a question - "Do people have sensible cares that are proportionate to the threat?" No. But if the media tells them to care because cars are running off the road and there's a massive uptick in cybercrime, which nobody can ignore and is directly attributable to a single cause, then the "care" (hysteria) can get worse than the problem (which may have happened with Cov19 to some degree).
Finally, they may care, but about completely the wrong thing. One suspects, if it turns out there is indeed some serious drama in Intel chips, then Intel and the US government will try to paint the security researchers as irresponsible hackers who unleashed this upon the world.
(*) first commercial architecture I know of...
There are a bunch of privilege levels in Intel CPUs (https://en.wikipedia.org/wiki/Protection_ring, relatively boring), used for memory protection and user/kernel mode separation (IIUC, I think I'm correct). They can be controlled by whatever code boots the CPU ("gets there first"), because the CPU boots in the most trusting state.
Over time the set of available levels proved insufficient for security and new levels were added with negative numbers so as not to disrupt the existing status quo. Ring -1 is used for virtualization and can also be controlled by whatever boots first (ie, outer code can create VMs and enter them, but the CPU faults if inner code attempts to access the virtualization instruction set), but Ring -2 and Ring -3 are used by the CPU itself.
Essentially, in the same way whatever the bootloader loads gets control over a bunch of interesting functionality because that code got there first, Ring -2 and -3 are controlled by code running directly on the CPU that gained control of the system before the bootloader and in some cases even UEFI was started. The significant elements are that a) this code can theoretically be altered by system (microcode) updates; b) these components run *completely* independently of the operating system - IIRC, the Management Engine is based on Minix running on a tiny 486-class core somewhere on the CPU die; and c) this invisible functionality has the ability to read and write all of system RAM. What's that? A glitch? A couple of bytes of RAM just got modified? That made the running Linux kernel suddenly think a process's effective UID is 0? Must have been the butterfly effect!
A bit of Googling found this overview of Ring -1 to -3 which I'd say is really good, definitely worth clearing your cookies to read if Medium is yelling at you about subscribing:
https://medium.com/swlh/negative-rings-in-intel-architecture...
I've been getting a lot of mileage out of "scribe.rip" that was posted a while back (https://news.ycombinator.com/item?id=28838053)
https://scribe.rip/swlh/negative-rings-in-intel-architecture...
Old ones though are open book (of a sort).
The 6502 for the apple II was obviously hand generated so it microcode is weird, but the 68k for the original Mac was pretty normal microcode as we would think of it today.
I wouldn't be so sure...
After hearing that American nuclear launch codes were all zeroes for decades, nothing surprises me.
I don't think Intel has such problems and I assume they are keen on keeping their microcode update process from being abused - it is not as if they don't have enough problems as it is.
edit: there was this piece interesting headway mentioned elsewhere in comments: https://news.ycombinator.com/item?id=32149210
Nothing of that level on Intel so far.
Over time, these instructions have gotten more and more complicated. Now there are "instructions" like "Enter Virtual Machine Monitor" which actually complex manipulations of tons of different registers, memory translations, and subsystems inside of the CPU.
And, even simple, primitive instructions like call, jump, and return actually need to check the state of various pieces of the processor and edit lots of internal registers, especially when we start to consider branch prediction and issues like Spectre.
It wouldn't be very plausible to hard-wire all of these complex behaviors into the CPU's silicon, so instead, most instructions are implemented as meta-instructions, using "microcode." "Microcode" is just software that runs on the CPU itself and interprets instructions, breaking them down into simpler components or adding additional behaviors. Most CPUs are really emulators - microcode interprets a higher level set of instructions into a lower level set of instructions.
Historically, Intel and more recently AMD have encrypted this "microcode," treating it as a trade secret. This makes people who are worried about secret hidden backdoors _very_ worried, because their CPU's behavior is depending on running code which they can't analyze or understand. This has led to all sorts of mostly unfounded speculation about secret back doors, CPUs changing the behavior of critical encryption algorithms, and so on and so forth.
Decrypting this microcode will theoretically allow very skilled engineers to audit this functionality, understand the implementation of low-level CPU behaviors, and find bugs and back-doors in the CPU's interpretation of its own instructions.
Replacing this microcode silently would be absolutely catastrophic security-wise, because an attacker could silently change the way the CPU worked, right out from under running software. But, there is no evidence this is possible, as the microcode is digitally signed and the digital signature implementation, so far, seems to be correct.
If you have the means to use this, then you already have the means to do 500 other simpler and more useful things.
It's like replacing the locks on someone's car so that you can make your own key work in it too. Sure, cool, but you already stole their entire car or at least had access to it in the shop, and could just copy their normal key if you want access again later, for much cheaper, in much less time, and much less risk of detection.
Edit: I'm also definitely not saying that paper voting is better than urna eletrônica. Both methods have big attack surfaces.
There is no valid argument for trusting electronic voting machines.
While they are still closed source like now, it is flatly impossible and not even slightly rational to trust them. If they ever become open and auditable and verifyable, well then you are no longer trusting them.
Talking about "large, coordinated" is an irrelevant distraction. Maybe there have been and maybe there haven't been any such attempted to date, but you have no way to know and so your awareness means nothing, and on top of that, every minute is a new minute.
There is no valid argument for trusting these things as they currently exist.
Whether you think any elections have been changed doesn't even matter.
'Trust' is a strong word. It can be the case that the best electronic vote-tallying system offered to an electoral authority is better than the best paper-based vote-tallying system.
Generally, one should judge the system as a whole, and vote-system and cyber-security experts did judge the 2020 elections and found the allegations of fraud to be without basis, even though many of those same experts are generally critical of electronic voting machines.
Perhaps it is unwise to inhibit the spread of ideas which lead to auditable systems.
RC4 had already been busted wide open when the two generations of CPUs (Gemini Lake and Apollo Lake) this affects were released.
Why would they use a known insecure cipher?
Edit: Oh, you mention the encryption. Big companies love obfuscating everything they create, because they're afraid something commercially sensitive will exist there and someone will copy it and outcompete them. I agree that this is ridiculous, but I don't think it's evidence of any sort of nefarious activity.
Or do you mean.
- the TXE vulnerability and / or undocumented debugging mode (so microcode wouldn’t have been extracted)
- microcode encryption so the microcode would always have been completely readable
- x86
- Intel itself
?
I can see why they would sign/encrypt it so that things got safer, but then they should have done a much better job of it. If it was encrypted to hide something that could not stand the light of day then that's an entirely different matter altogether.
Time will tell.
Then AMD PSP did the same starting in 2013.
"In a statement, Intel officials wrote: ... we do not rely on obfuscation of information behind red unlock as a security measure."
(BTW, I work on Linux at Intel, I'm not posting this in any official capacity)
Oh, great! Isn't there a way where intel could provide keys so we could get rid of IME even if it means we won't be able to play DRM'ed content?
It's one thing to have that and be up front and open on it. Get secretive, and you're creating a massive source of unknown unknowns for everyone involved.
And like it or not, if you won't/can't be transparent about it, either
A) It'd take too long to document, which suggests there may be room for simplification
B) you're doing something that if it saw the light of day, would cause outrage, likely because you shouldn't be doing it
C) You're holding back the state-of-the-art for the sake of securing a revenue stream.
Edit: I assume this threat has existed as long as updatable microcode has.
Basically, the easier route is usually to just find a way to bypass the check once, and use that to install a more permanent bypass.
It may be possible through power fault injection to flip the bits of the public key such that you could get it to accept microcode signed with your own private key, but I would be very surprised if the public key weren't burned into the structure of the CPU itself in a manner that renders it immune to such attacks.
Of course, power fault injection may still allow you to bypass the verification routine altogether instead of modifying the key it verifies with.
Especially considering how they gained this knowledge:
"Using vulnerabilities in Intel TXE we had activated undocumented debugging mode called red unlock and extracted dumps of microcode directly from the CPU. We found the keys and algorithm inside."
And looking further down, some X86 instructions (that people would usually call low-level) actually trigger execution of an entire ELF binary inside the CPU (implemented in XuCode). Just wow.
On the other hand, most of 12-series CPUs contains them :-(
E cores in Alder Lake are not listed as vulnerable to this attack.
Say what? Can you explain what you are basing that on?
I think that's what's being referred do. Microcoded execution is much simpler in terms of the hardware that you have to implement.
That’s contrary to everything I’ve ever heard.
For real world example, you could have divider as very complex logic device or as small patch of ROM implementing "school" algorithm in terms of (hardware implemented) additions, shifts and subtractions.
Can you show one example of a commercially produced general purpose CPU that does that, let alone a fairly mainstream x86_64 one? In a purely theoretical sense, what you say is plausible, but in the “real world” it’s simply not done.
(its successor the 80186 already had a divider in hardware)
I'm not following this doesn't the microcode control the gates?
- only three instruction decoders
- max IPC of 3
- no AVX, AVX2, AVX512
- vector registers are limited to 128bit
- generally tops out below 2ghz as base clock with turbo boost into the mid 2s at best
- very basic integrated GPU on non-server versions running at 200-600mhz
Less registers, less IPC, lower clock frequencies, and less execution units = cheaper cost.
So explain how microcode had something to do with that again?
[0] https://web.archive.org/web/20210117163607/https://www.extre...
Let's be optimistic - say, after lengthy, rigorous expert analysis it turns out there are no backdoors or prepared traps for potential malware within Intel CPUs. That's a big boon for security everywhere, and for Intel's share price.
If on the other hand, it turns out against Intel, the evidence is literally baked into silicon within billions of devices in the wild which will become e-waste overnight.
With this TikTok thing in the wind the Chinese will ban Intel... etc.
The stakes are high. The problem was always lack of transparency. Putting encrypted microcode into consumer CPUs was always a dumb idea. And why? To protect the media conglomerates. Another reason we need to re-examine the role and value of "intellectual property" in society.
Not just e-waste, they can also become a huge liability. In a presentation, the authors mention that one of the CPU families which have this vulnerability were used in Tesla cars. Tesla apparently switched to AMD APUs around December 2021.
https://github.com/riscv-admin/riscv-uefi-edk2-docs
So if it isn't from door A, door B will do.
And no production OS kernel really uses any of the code that UEFI maps, or keeps any of said code mapped. It may keep the data-table pages (e.g. ACPI sections) mapped, for a while; but usually only long enough to copy said data into its own internal data structures.
(Which is a shame, actually, as an OS kernel that did take advantage of UEFI services like UEFI applications do, would be able to do things that modern kernels currently mostly can't — like storing startup logs and crash dumps in motherboard NAND space reserved for that function, to provide on-device debugging through a separate UEFI crash-log-viewer app in case of startup disk failure, rather than needing to attach a separate serial debugger.)
[1] https://en.wikipedia.org/wiki/System_Management_Mode
[2] https://en.wikipedia.org/wiki/Advanced_Configuration_and_Pow...
Mostly for dynamic powermanagement and voltage regulation, monitoring temperatures, hotplugging, etc. That's just the way it is (now).
I remember when this first made the rounds over a decade ago with some mainboards from CENSORED Apple supplier which were pretty usable, except when running under something else than Microsoft Windows. IIRC it wasn't malice, only implemented in a way which made this hard to interface with from Linux, or the likes. Of course undocumented. Later, but about the same timeframe the first so called open source/security 'zealots' damning ACPI in general for those reasons.
It may be called differently on other platforms, but similar/equivalent mechanisms exist on almost everthing which is not in a museeum or landfill.
Before giving control to the operating system for the first time, the UEFI firmware can configure various peripherals to generate SMI (System Management Interrupts) on various types of events and it can ensure that the SMI requests will be handled in the future by itself and not by the operating system. The UEFI firmware can lock this configuration, so that the operating system will not be able to change it.
When a SMI request happens, the UEFI firmware handles the event with the CPU in SMM (System Management Mode), which is a mode with more privileges than any operating system or hypervisor and which has access to everything, including to things that are protected from accesses by the operating system, e.g. a memory area reserved for SMM use.
The ARM CPUs may also have a mode equivalent with the Intel SMM, named EL3 (Exception Level 3), so, on ARM CPUs that implement EL3, the UEFI firmware can also run concurrently with the operating system or hypervisor, overriding them whenever it wants.
In theory, the UEFI firmware should use SMM only to handle benign events, for which Microsoft was too lazy to write handlers and Intel obliged by creating the ugly SMM, passing this event handling task to the motherboard manufacturers (forcing thus also the other operating systems to use the BIOS/UEFI handlers, even if they could have handled those events better themselves), such as powering up and down peripherals or changing the clock frequency of the CPU.
Nevertheless, the writer of the UEFI firmware could easily do much more than that, e.g. inspecting the content of the memory, the data written or read on storage devices or sent and received through the network. (Full memory, storage and network traffic encryption could prevent this.)
The SMM could also be used to implement a remote control of the computer that cannot be detected or prevented by the operating system, but for this an even more powerful facility has been introduced by Intel and AMD, many years later after SMM, in the form of the auxiliary CPU from ME/PSP.
It's like saying I haven't been robbed until I discover that my stuff is missing.
To make the analogy work for you, you have to add something about doors being unlocked, or somebody else having the key to your home.
Something like: The locksmith has made a copy of your keys without notifying you. They could hypothetically use those keys to enable a robbery, but you won't know definitively either way until you find something stolen. But it is a pretty weird thing for them to do, right?
There's no Schrodinger's Burglar. You've been robbed once I take your wallet, whether you've discovered it or not.
Well, robbery is theft under threat of force, so it would be very hard to be robbed and remain unaware of it.
https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo...
[0] https://www.techspot.com/news/93006-intel-sgx-deprecation-im...
[1] https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...
Certainly. Intel (amongst others) supply consumer grade CPUs for a "multimedia" market, to service music and movie playback.
The movie and music industry apply intense pressure and lobbying against the computing industry to protect their profits. They see users having control over media, and thus ability to copy, recode, edit or time-shift content as a threat, which they dub "piracy".
Under this pressure to implement "Digital Rights/Restriction Management" within their hardware, semiconductor manufacturers have been making microprocessors increasingly hostile to end users, since if users were able to access and examine device functions they would naturally disable or reject what is not in their interests.
Hiding undocumented functionality to take over, examine or exfiltrate data from systems via backdoors etc is a natural progression of this subterfuge and tension between manufacturer and user. This situation of cat-and-mouse hostility should not exist in anything recognisable as a "free market", and hence I deem it "protectionism".
Now the real problem is that these same "multimedia" processors are used in other areas, automotive, aviation, health and even military applications. The "risk-tradeoffs" bought by big media bleed into these sectors.
Therefore it's clear to me that measures for the protection of "intellectual property" are directly at odds with computer security generally, and are increasingly leading to problems for the sake one relatively small sector. Sure, the digital entertainments industry is worth many trillions of dollars, but pales within the larger picture of human affairs. At some point we may have to choose. Hollywood or national security?
So basically it happened because users see the feature and don't realize how hostile it is until they actually try to access their media in an "unsupported" way.
Of course if everyone else resisted streaming services would likely have launched anyways, but that is classic prisoners dilemma.
(They dropped SGX which is needed for the DRM)
https://www.whathifi.com/news/intel-discontinues-support-for...
Intel's executives would show up to play golf, and find out that nobody wanted to play with them. They might even be no longer welcome at the country club. Power structures coalesce, because powerful people identify with each others' authoritarian desires.
I think you could refine your point here.. markets include adverse negotiation, secure applications are a thing, and for that matter, weapons making is a thing. You can't "wish away" that part.
I have a colleague who makes secure DRM for FAANG since long ago, and has a large house and successful middle-class life from it.
Where is the commerce ? the market? the reality, in your dream solutions ?
edit as a sound designer and open software advocate, with a book published by MIT Press, please know that some people in the USA try to make the arts life, and some of the emphasis here is the empty hands and pockets that follow. Let's agree, no mafia sound sellers, but also "no" to complete free flow of all digital material no matter what.
Serious question: which consumer CPUs have unencrypted microcode? AMD processors have had theirs encrypted for a decade, Intel for even longer, and nothing I've seen indicates that any ARM models have unencrypted microcode updates floating about.
But the problem with backdoors has always been that other people will likely eventually figure out how to use them too.
If you can't audit the microcode, you have a massive gaping security problem.
While these are reasonably widespread in the cheapest personal computers and servers, the impact of examining their microcode is much less than if the decryption keys for some of the mainstream Core or Xeon CPUs would have been obtained.
In a more decent world, the manufacturers of CPUs would have been obliged to only sign their microcode updates, without also encrypting them, to enable the owners of the CPUs to audit any microcode update if they desire so, in order to ensure that the update does not introduce hidden vulnerabilities.
Even the newer Atom cores, e.g. the Tremont cores from Jasper Lake/Elkhart Lake/Snow Ridge/Parker Ridge/Lakefield have a different microinstruction format than that which has been published now.
For every generation of Intel CPUs, reverse-engineering the microcode requires all the work to be done again, what has been discovered for another generation cannot help much.
This XuCode execution engine is not a new or unknown thing - https://www.intel.com/content/www/us/en/developer/articles/t...
We can lament the state of computer security but that feeling is surely sunken, past tense.
This isn't a correct characterization of the suspicion that Intel microcode has backdoors in it. The suspicion isn't just based on distrust of authority, like flat Earth, etc, but also on the org having means, method, and opportunity to remotely modify the operation of a CPU. And it operates within the domain of the USG, who have demonstrated a keen interest in weaponizing 0-day exploits.
What better way to acquire a novel 0-day than to simply write one known only to you and distribute it from the source? This is a good plan, but it comes with a substantial risk to Intel, or any company who wishes to maintain a trust relationship with its customers.
That said, I don't think anyone doing this is stupid, and for safety they would not install microcode malware on everyone, just some. This means we will find nothing in general CPUs, and anecdotal reports finding "something" can easily be dismissed as malicious or noise.
The truly paranoid need not worry, even if the microcode is seen to be harmless, there is always the possibility that hardware you buy is interdicted, modified, and sent onward, such that your paranoia can remain intact.
In this thread, I see implications about big media controlling microcode (which doesn't seem to be impacting piracy — if anything, it's easier than ever before), about governments imminently finding backdoors and trashing an entire generation of chips, and other extreme outcomes that seem wholly out of step with reality. (Not in the "Everyone else is dumb but we few are smart" way; in the "I have not interacted with a business or government ever" way)
I'm sure the 2600 crowd will have their next "Yes but what about the *Long form* birth certificate"-style goalpost shift if there are no backdoors found.