Comment by londons_explore

3 days ago

Unclear why there is a 1 second timeout at all.

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

The author’s take on this in the Mitigations section makes sense to me:

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

system management mode does a lot of stuff, some of which is time critical. If your system is overheating and one of the cores is stuck off in the weeds, it's probably better to get on with the thermal response rather than waiting forever.

Also, the System Management Interrupts are supposed to return to normal processing in some finite timespan; a timeout bounds the wait time.

  • If it is critical it should not be running on same cores

    • Using the example above, if a CPU core is overheating, can you down clock that core using and instruction run on another core? I don't actually know that much about how the hardware actually works at that level, so I am genuinely asking.

      1 reply →

    • There's a hardwired emergency shutoff but you probably want the BIOS to set the fans to maximum long before the computer just shuts off.

  • It could also react to hitting the timeout with a hard reset. Annoying perhaps, but at least safe. Ancient principle of system design is that when you must fail, it is better to fail safe than fail deadly even when it's annoying in the short term.

I would expect a way to interrupt super-long-running instructions would be the better option, even if it was not fully backwards-compatible (say your process executing long-running instructions gets killed).

Can this be patched? Is there a chance it's a hw watchdog that you can't fix in microcode?