It could go both ways.

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.

> billions of devices in the wild which will become e-waste overnight

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.

AMD have much the same thing.

https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo...

This is about microcode, not the Intel ME. AMD does also have updatable microcode though.

AMD processors have much the same backdoor-"management" coprocessors. Just about the only processors without this stuff is your own softcore design running on an FPGA.

Then you have to worry about any "management" modes on the FPGA.

https://www.cl.cam.ac.uk/~sps32/Silicon_scan_draft.pdf

What's left, RISC-V?

https://en.wikipedia.org/wiki/RISC-V

Not really, because most deployments use UEFI alongside them.

https://github.com/riscv-admin/riscv-uefi-edk2-docs

So if it isn't from door A, door B will do.

It is not just for booting. UEFI has Runtime Services that an OS can call.

How is UEFI like ME/PSP? I thought it was just for booting.

Its surprisingly more complex than that. You can run Doom in UEFI

https://github.com/Cacodemon345/uefidoom

Okay, but that doesn't really bother me; running arbitrary payloads is the point of a bootloader. The only reason I would be worried by UEFI on RISC-V is if the UEFI firmware in question stays running in the background after the OS boots, and isn't properly inspectable. That might be the case - I have some vague notion of UEFI providing post-boot services, and for all that the EDK version is FOSS you could certainly make a closed version - but I'm not seeing any reason to panic just yet.

UEFI can provide post-boot services, but only in the same sense that a DOS-era BIOS did: by providing memory-mapped code that UEFI applications can call into, exokernel style. The UEFI framework isn't a hypervisor; it has no capacity to have ongoing execution threads "behind" the OS kernel. Rather, the OS kernel just receives a memory+PCIe map from UEFI at startup that contains some stuff UEFI left mapped; and it's up to the OS kernel whether to keep it mapped and make use of it; or just to unmap it.

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.)

On X86/AMD64 there is also ACPI and SMM (System Management Mode), which overlap in parts. ACPI calls into code provided by whichever bootloader, running post-boot above to operating system, or behind its back, so to speak. It's complicated.

[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.

In most computers with Intel/AMD CPUs, and especially in most laptops, the UEFI firmware remains running concurrently with the operating system.

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.

A malicious actor can do a lot of things in UEFI, but they can't decrypt my disk, they can't boot into my OS, and they can't mess with my userland environment. If Johnny Blackhat fancies a game of Doom over TTY on my desktop's UEFI environment, he can be my guest.

POWER8 and POWER9 say hi.

Money says bye.

At least for AMD the PSP isn’t externally exposed which means the attack surface is drastically reduced.

When you say externally exposed, do you mean to the network, or physically exposed, or what?

It doesn’t sit on the network (unlike the ME) so an attacker needs to have access to the host already to be able to exploit any vulnerabilities on the PSP.

This is not about the management engine. Microcode is part of the actual core processor itself, but an updatable layer. One sort off correct mental model might be to think of x64 hardware as being a RISC-ish processor that runs microcode that runs your code.

What about POWER?

It’s not a backdoor until it’s proven that it’s used for that propose. Until the it’s just (yet another) potential side channel.

I don't understand that logic.

It's like saying I haven't been robbed until I discover that my stuff is missing.

> It's like saying I haven't been robbed until I discover that my stuff is missing.

Well, robbery is theft under threat of force, so it would be very hard to be robbed and remain unaware of it.

Yep, I assume they just don’t know the difference between robbery and burglary.

Actually, I do know the difference, but forgot the distinction when writing the comment :)

That's literally true, though?

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.

I think in the original analogy, the actual robbery is just used as an event which may occur without our knowledge. Your analogy is better, the mapping makes more sense.

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?

>That's literally true, though?

There's no Schrodinger's Burglar. You've been robbed once I take your wallet, whether you've discovered it or not.

> Putting encrypted microcode into consumer CPUs was always a dumb idea.

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.

Basically none these days. But therein lies the problem. The actors can't be trusted. In part because the state-actors in which they reside can't be trusted and they can (and do) issue gag-orders to shove backdoors down their throat.

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.

Which ARM cores have loadable microcode to begin with?

POWER9 CPUs are in retail hardware and are being used today (including several in this house), so I'd say they qualify.

It may be a serious question, but I don't see how it relates to the part you quoted. It still is a dumb idea, regardless of the answer to your question.

Do the Raptor systems (POWER-based) fit here?

If it can't be done on a MC68000 (or thousands in parallel), then does it really need to be done?

Can you please elaborate on the "To protect the media conglomerates." part?

> Can you please elaborate...

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?

You are absolutely right, and media companies are the evilest of evil. But it's a little unclear why Intel felt it had to cave in. What would have happened if it had told Hollywood to go love itself somewhere? It's not like movie producers are remotely capable of making chips.

If could have been pushed down the chain. The media companies wanted to provide streaming so they talked with Microsoft. Microsoft realized it would be a valuable feature for thier OS and if they resisted but Apple didn't they would lose market share as HD streaming wasn't available. Then they said the same to Intel. If you don't do it people will buy AMD chips for HD streaming.

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.

It’s not like Intel have no competition. They probably figured that if they didn’t cooperate with the media industry, AMD or someone else would, and eat their lunch when suddenly Sony movies can only be played on AMD devices.

I’m not hearing much noice over intels latest chips losing support for 4k Bly-ray disc playback

(They dropped SGX which is needed for the DRM)

https://www.whathifi.com/news/intel-discontinues-support-for...

SGX is only dropped from consumer SKUs for product segmentation purposes.

Well Tbf to intel. The only people I know who use a bluray drive in a pc for 4K content, rip the content anyways bypassing DRM. The masses (in the pc watching moving via a Blu-ray drive space) have moved onto streaming anyways.

Yeah, I’m not saying they made the right call… If they have any business sense they will just open up the microcode after this.

One possibility might be that Intel thought that if they did not do it voluntarily, they might ultimately be forced to by legislation.

wdym cave in, it's not like Intel integrated technologies pushed on them. Intel developed HDCP and co-developed AACS (the Blu-ray encryption scheme). I dunno how much they had their hand in AACS 2, but considering it's literally built on SGX I'm going to claim without evidence that Intel played a significant role in creating AACS 2.

> What would have happened if it had told Hollywood to go love itself somewhere?

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.

"Most people, I think, don't even know what a rootkit is, so why should they care about it?" - Sony BMG

It's called https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content...

> This situation of cat-and-mouse hostility

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.

To be breif and frank with you, I see those views as "part of the problem".

ok - second example is a California woman who went to law school, passed the California Bar Exam (2-day, super difficult) went to work as a junior attorney at a law firm in Los Angeles and worked her way up for more than ten years to get a promotion. That law firm is intellectual property and yes, Digital Rights Management too.. and she now has a successful middle class life with a house. No one had money to buy her a house, she worked for that and she did not have the ability to define the rules.

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.

Intel's SGX was at least partially intended to implement DRM [0], and its various-ish predecessor technologies such as old-school Palladium/TPM was expected to do the same [1] (but was ultimately cancelled because of wide backlash).

[0] https://www.techspot.com/news/93006-intel-sgx-deprecation-im...

[1] https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...

Thanks, didn't know these are pretty hardcore protection. Just curious maybe these protection layers and protetion-protection layers may introduce more vectors for attackers?

Would this kind of functionality not, more likely, be implemented on the behest of the CIA? The media companies could be used as a good cover though.

Why the CIA specifically?

e-waste? how come? I already assumed my hardware is insecure.

Forced obolescence FUD. Nothing more, nothing less.

For now, the decryption keys have been obtained only for older Atom CPUs (e.g. Apollo Lake, Denverton, Gemini Lake).

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.

Atom and Core/Xeon don't share microcode? e.g. vulnerabilities in one would never work on the other?

No, the microinstruction formats are very different, so also the microprograms must be different.

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.

Even if, well... some intelligence service has developed microcode-level "implants"/malware, they wouldn't necessarily want it to be part of the standard build that gets shipped to all customers, precisely because of the risk of exposure. It's at least as likely that they'd install it on targets as updates, having first secured access by other means (as they'd have to anyway to exploit a backdoor that did ship with the chips). It's possible that some agencies would even be able to access signing keys if that helped simplify "implanting" procedures -- though it might not be necessary, if (like the OPs here) they can arrange microcode-level execution by other means.

What's the sinking feeling suspicions?

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 is only the microcode, not the deeper level minix, accessing all the IO and memory, where all the backdoors are suspected. Think of run-time patched CPU code to patch HW errors.

The microcode runs on the CPU, and has the (theoretical) ability to directly modify anything running on the CPU simply by executing different instructions. The Management Engine (the component that runs the Minix kernel) is on the external chipset, and has no direct visibility into the state of the CPU. The OS that runs on the Management Engine has also been decodable for years, and while bugs have been identified nobody has found anything that's strong evidence of a back door.

Can you expand on that as someone who is learning more about low-level architectures in relation to the hardware and microcode layer?

It's never been publicly clear how much is done in hardware, and how much is actually done via microcode. This blows the doors open and reveals that there's actually a lot more being done in microcode than previously suspected. What's pivotal, is how much more possible this makes microcode-based attacks against Intel-based systems.

I don't think it's true that there's more being done in microcode than previously suspected? The microcode updates for various CPU vulnerabilities clearly demonstrated that microcode is able to manipulate internal CPU state that isn't accessible via "normal" CPU instructions.

This makes microcode more auditable to most people. Relying on the “security” of most people being unable to inspect their microcode is not really a good position to have.

It is true ("lot more being done in microcode than previously suspected"), but only for Atom cores. Which are much simpler than "Core" cores, and, to be honest, it should be expected for small, simple and slow core - as microcoded execution is much simplier and make sense for these cores.

On the other hand, most of 12-series CPUs contains them :-(

> On the other hand, most of 12-series CPUs contains them :-(

E cores in Alder Lake are not listed as vulnerable to this attack.

> as microcoded execution is much simplier and make sense for these cores

Say what? Can you explain what you are basing that on?

If you build a simple, lower-end chip, you do so by giving it fewer hardware resources - fewer things where the implementation is via gates. That means that, in order to implement the same instruction set, you have to implement more via microcode.

I think that's what's being referred do. Microcoded execution is much simpler in terms of the hardware that you have to implement.

>"If you build a simple, lower-end chip, you do so by giving it fewer hardware resources - fewer things where the implementation is via gates."

I'm not following this doesn't the microcode control the gates?

I have a distinct feeling that neither of them have even the slightest clue what they are talking about. If they did understand processor design and had seen pages like this[0], they’d realize that a Goldmont cpu is not dramatically different from a other Intel cores and “microcoding” had virtually no bearing on “why it’s cheaper to make”. The real reasons it’s cheaper:

- 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...

> Microcoded execution is much simpler in terms of the hardware that you have to implement.

That’s contrary to everything I’ve ever heard.

Lets take it to extreme: you need very little resources (transistors) to implement Turing Machine, but providing enough microcode (which is very simple structure on silicon - it is ROM, which is trivial and very dense comparing to complex logic) you could emulate any complex ISA on this machine.

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.

> 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.

It was done that way in the original 8086/88: https://www.reenigne.org/blog/8086-microcode-disassembled/

(its successor the 80186 already had a divider in hardware)

I guess I wasn’t explicit, I meant something made in the past decade or two. Going back to 3 decades ago, there’s a handful I can think of, going back almost a half century like the 8086/88, there were even more.

Basic CPU design in 1990 undergrad had everything as microcode, so I’m not sure there was much of any question or any conspiracy other that EE is much harder than CS and attracts far fewer people to it, and thus less information gets spread around, I guess.

Yeah if they can ship code that fixes "critical security" faults in a physical product, then it's probably at the software level all the way down.

It's more like they can patch any instruction to become microcoded, but that doesn't mean it shipped that way originally.

Please explain your worst fears?

I think we can all assume the suspicions are true.