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