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.
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?
Looks like it's ~4 billion (2^32) crossover counter?