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?
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.
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.
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.
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.
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
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
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?
> 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!
Presumably the patch for that will be to make it an infinity timeout.
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