Exploiting System Management Mode with a very long interrupt

The designers of the firmware anticipate this attack but punt it to the vendor, apparently:

    //
    // Platform implementor should choose a timeout value appropriately:
    
    [snip]

    // - The timeout value must be longer than longest possible IO operation in the system

Technically this is not a vulnerability because you need to be root. I would rather call it "taking back control of your hardware". SMM is an evil thing because the user cannot control it or look into SMM memory region. Why do CPU vendors implement a mode that cannot be controlled by the user? Obviously to use it in user-hostile purposes (software copying prevention and reporting, DRM, government access backdoors, etc.), I see no other explanation.

Related repo from them, mentioned in the readme as well: https://github.com/xoreaxeaxeax/asm-hall-of-shame

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

I'm amused at the lengths the readme goes to in order to drive home the fact that this needs to be a LOOOOOOOOOOOOOOOOOOOONG instruction, including the unnecessarily long code block illustration. The topic is interesting anyway, but that makes it way more entertaining.

SMM calls for a timeout because it wants everything to be between instructions pro forma. So there’s a very long instruction on a core, but after it completes, the core does stop, right? It seems like to make this into an attack you’d have to a very long instruction that also somehow interacts with the thing the SMM is doing, while it’s doing it.

Almost nothing from this GitHub profile posted until the last four days.

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?

Unclear why there is a 1 second timeout at all.

Presumably the patch for that will be to make it an infinity timeout.

The timeout idea is interesting. If firmware can strictly bound SMM execution time, would that actually eliminate this class of attack, or just turn it into a crash/DoS instead?

I don't know much about the specifics of CPU architecture apart from the existence of assembly and different modes. Either way the explanation was still entertaining and interesting. smiiiiiiii

It's nice to see SMM is as terrible idea now as it was at moment of conception.

All coz they can't be arsed to put a tiny management core separate from the rest and save a penny

...huh, I was wondering why serial machine code prankster xoreaxeaxeax was keeping lists of extremely long-running instructions.

Hopefully this is at least only possible in kernel mode, right?

Right?!

> The code waits for all cores to enter SMM, or for up to 1 second, whichever occurs first.

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.

Well, shit.