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
I wonder whether a Thunderbolt accessory can cause arbitrarily long IO operations. What's the upper bound before some other layer gives up and causes the instruction to fault?
> 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.
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?
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.
If I’ve understood correctly, what your missing here is that the first core in SMM tells the second to join it in SMM, times out on the wait, does its thing and exits, but then the second core joins SMM after the first has exited, so now the first core is running outside SMM, second core in SMM, so first core can attack the second.
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.
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?
Yep there are links as far back as 11 years ago posted here. But I’m saying why suddenly in four days is this GitHub profile linked in lots of front page threads?
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?
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.
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.
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
ARM has EL3, which is basically the same thing. There's nothing inherently wrong with the CPU having multiple privilege levels. The problem with SMM has always been its user-hostile opaque implementation, not that the technical mechanism exists.
> 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."
Is it really a long running instruction? I mean, obviously yes, but what makes it slow is that it's doing an MMIO copy from a slow source. It's like a read(2) system call being "slow" because the fd is associated with a socket to the moon.
It's an instruction in the sense that timing boundaries are x86 instruction boundaries, which is what the security model bases itself on. So yeah, not an instruction in the strict CPU sense (microcode + micro-ops), but in the useful sense.
A read that happens to touch a particular torment nexus fd is still a long-running syscall, even if the syscall servicing routine itself is not long-running. The underlying problem is that program code that is "in a syscall" or "in an instruction" is in a special state for which interruption might not be possible or implemented well[0].
Given that you can connect essentially PCIe devices thru USB it is probably exploitable?
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
The designers of the firmware anticipate this attack but punt it to the vendor, apparently:
I wonder whether a Thunderbolt accessory can cause arbitrarily long IO operations. What's the upper bound before some other layer gives up and causes the instruction to fault?
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!
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?
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.
If I’ve understood correctly, what your missing here is that the first core in SMM tells the second to join it in SMM, times out on the wait, does its thing and exits, but then the second core joins SMM after the first has exited, so now the first core is running outside SMM, second core in SMM, so first core can attack the second.
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.
Do you think a short instruction is okay or does it need to be long? The instructions were a bit unclear in that regard :D
Only if the short instruction is incredibly long.
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?
DEFCON the fun hacking conference in las Vegas that happened last weekend.
This rosenbridge repos commits claim to be 8 years old https://github.com/xoreaxeaxeax/rosenbridge
Yep there are links as far back as 11 years ago posted here. But I’m saying why suddenly in four days is this GitHub profile linked in lots of front page threads?
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?
Unclear why there is a 1 second timeout at all.
Presumably the patch for that will be to make it an infinity timeout.
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.
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.
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?
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
ARM has EL3, which is basically the same thing. There's nothing inherently wrong with the CPU having multiple privilege levels. The problem with SMM has always been its user-hostile opaque implementation, not that the technical mechanism exists.
> 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.
...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?!
Is it really a long running instruction? I mean, obviously yes, but what makes it slow is that it's doing an MMIO copy from a slow source. It's like a read(2) system call being "slow" because the fd is associated with a socket to the moon.
It's an instruction in the sense that timing boundaries are x86 instruction boundaries, which is what the security model bases itself on. So yeah, not an instruction in the strict CPU sense (microcode + micro-ops), but in the useful sense.
A read that happens to touch a particular torment nexus fd is still a long-running syscall, even if the syscall servicing routine itself is not long-running. The underlying problem is that program code that is "in a syscall" or "in an instruction" is in a special state for which interruption might not be possible or implemented well[0].
[0] Remember ITS and the PC2 problem?
Maybe with vfio/igb_uio/uio_pci_generic? Still root level access.
Given that you can connect essentially PCIe devices thru USB it is probably exploitable?
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