//
// Platform implementor should choose a timeout value appropriately:
[snip]
// - The timeout value must be longer than longest possible IO operation in the systemYou're Intel. The year is somewhere around 1989. Your hardware interface that you export to regular software has gotten complex enough that you want to implement some of it in some kind of software that you can implement at a higher level than just logic. You also maybe want your hardware partners (ie. motherboard and system manufacturers) to be able to change parts for their implementations. Additionally some of this code might eventually end up being hard real time with the possibility of damaging the chip if it doesn't run at the correct window (think power management). You don't have the area budget for rewritable microcode of the size you'd want; this code has to live in DRAM.
You look around at the system software people are running on x86. At the highest quality you've got OS/2, and it goes downhill fast from there. Most end users are running DOS (from several vendors). So you write a higher privilege mode that runs underneath DOS, can actually be pretty close to a tiny RTOS kernel, and document it. But the whole point is to be relatively transparent, and definitely inaccessible to kernel mode, which you don't trust to pull its own pants up after it uses the bathroom.
Then later, when your corporate vendors are asking you to secure the boot chain, it only makes sense that this mode is also cryptographically signed.
And I think this is a more interesting story (and probably closer aligned to the truth). That is, we can get to an anti-user feature that can't be truly owned by the final customers through small steps where each felt like a pro-user customer product decision.
That being said, there are benefits of having SMM protect firmware integrity from a malicious/compromised kernel. On most AMD64 platforms, SPI flash can only be written to by SMM and that is a foundational piece of the PC security model (FW update, authenticated UEFI variables, etc). This has nothing to do with copy protection, DRM, or backdoors.
In fact the whole situation is very much analogous to Kernel Lockdown, which is controversial.
With signed bootcode you can give a reason for not letting the userspace modify the SMM code. But when all this stuff was designed there were no bootcode signatures.
Don't forget that SMM code started out in A0000 --- the area of RAM that would've otherwise been inaccessible and wasted anyway, because it was usually decoded to the VGA. Also, this was the era of DOS; there was no difference between "kernel" and "application".
The incentives are such that if it's possible to make hardware that's cryptographically locked into being aligned against the interests of its supposed owner, that's exactly what will be, which is why we now have two fully-closed systems (Google Play Services and iOS), one 99%-closed one (macOS -- Apple controlling the 'notarization' signing and showing their willingness to use it for petty reasons proves macOS is closed), and one clearly marching toward the same basic idea (Windows).
What's more depressing is, even if suddenly every court agreed with me, we'd just transition overnight into a leasing paradigm, where vendors would cease to sell devices, only rent them to us. "As the device owner, should we not have the right to govern its use to only responsible purposes and protect it from 'mAlWaRe'?" And the devices would be quickly 'accepted' by the market, as "unmanaged" devices would be locked out of everything, just like you can't use banking apps, streaming apps, or even the McDonald's app, on a rooted/jailbroken phone today.
It's even worse than that. It's gotten to the point that "operating systems" aren't actually operating the system anymore. Linux is just the "user OS", a tiny blip on the overall system schematics. Just some app to be sandboxed away from the real system.
Devil's Advocate: can you control every transistor in a good old Z80?
Of course, that's not where the goalposts are. Any piece of hardware will necessarily have limits as to the amount of introspection and manipulation that it allows in the programming model.
What Intel have done is built a "grotto" in the chip that is extraneous and deliberately inaccessible.
(The fact that there is such a thing as a higher privilege level than root is what annoys people).
> Instruction latency analysis usually focuses on performance optimization—making code run as fast as possible. The Assembly Hall of Shame takes the opposite approach: searching for the absolute floor of single-instruction performance.
Fun stuff!
From a meta perspective what is going on? What am I missing? Why is this GitHub profile suddenly getting massive attention and making front page so frequently?
Is it just that one thread brought attention and several people are slowly digesting the other repos on that profile? Or is there another meta reason?
Presumably the patch for that will be to make it an infinity timeout.
> Remove the timeout, and a legitimately stuck core hangs the platform on the first SMI. Increase the timeout, and you kill performance on many-core platforms that are forced to quiesce all cores every SMM entry. It's not clear what the best path forward is, or if there is even a path forward at all.
Also, the System Management Interrupts are supposed to return to normal processing in some finite timespan; a timeout bounds the wait time.
All coz they can't be arsed to put a tiny management core separate from the rest and save a penny
Hopefully this is at least only possible in kernel mode, right?
Right?!
[0] Remember ITS and the PC2 problem?
Find out which device is accessible to user and does MMIO, emulate it on FPGA, make it slooooooooow. All it needs to do is for driver to trigger a "right" access". GPU comes to mind
See, this is why the mantra that all blocking operations should have a timeout is stupid and short-sighted no matter how many times junior devs and AIs bleat it in code review. Continuing after arbitrary timeouts usually violates invariants, and failing after arbitrary timeouts introduces hard-to-debug failures under load.
Better for the system to hang so you can debug it --- and maybe reboot as a whole via a watchdog --- than for the code to say "Oh, this operation is supposed to be done after one second, but isn't. Situation normal, everything fine. We continue."
No. That situation is very much not fine.
What needs to fail here is the instruction doing insanely slow MMIO. That's not going to be too hard to debug; none of the examples of suitably slow instructions are anywhere close to reasonable, and a fault on a vmovdqu in MMIO address space is a big red flag.
And this attack requires enough ridiculous behavior from coordinating software beyond just the single super-slow instruction that it's hard to imagine any reasonable workload being affected if this case starts causing a fault.
At the bus/inter agent communication level, the CPU has sent a read request and is expecting a response. These protocols are usually synchronous with no clear cancellation semantics. There are probably core resources tracking then expected response and if you just freed one of those up and ended the instruction with an exception, you could later have what appears to be an unsolicited response.
This dynamic probably repeats between the core and the pci root complex and then again between the root complex and the device implementing the mmio. Severing the request from the response is probably too complicated for such an unusual case.