I have a sinking feeling in my chest. If the suspicions are true, we may be at a pivotal moment here.
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://en.wikipedia.org/wiki/AMD_Platform_Security_Processo...
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.
Well, robbery is theft under threat of force, so it would be very hard to be robbed and remain unaware of it.
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.
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.
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.
[0] https://www.techspot.com/news/93006-intel-sgx-deprecation-im...
[1] https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...
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.
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.
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...
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)