Rendered at 20:40:07 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
codedokode 23 hours ago [-]
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.
monocasa 20 hours ago [-]
It's interesting to keep this in historical context, IMO.
You're Intel. The year is somewhere around 1989. Your hardware interface that you export to regular software has gotten complex enough that you want to implement some of it in some kind of software that you can implement at a higher level than just logic. You also maybe want your hardware partners (ie. motherboard and system manufacturers) to be able to change parts for their implementations. Additionally some of this code might eventually end up being hard real time with the possibility of damaging the chip if it doesn't run at the correct window (think power management). You don't have the area budget for rewritable microcode of the size you'd want; this code has to live in DRAM.
You look around at the system software people are running on x86. At the highest quality you've got OS/2, and it goes downhill fast from there. Most end users are running DOS (from several vendors). So you write a higher privilege mode that runs underneath DOS, can actually be pretty close to a tiny RTOS kernel, and document it. But the whole point is to be relatively transparent, and definitely inaccessible to kernel mode, which you don't trust to pull its own pants up after it uses the bathroom.
Then later, when your corporate vendors are asking you to secure the boot chain, it only makes sense that this mode is also cryptographically signed.
And I think this is a more interesting story (and probably closer aligned to the truth). That is, we can get to an anti-user feature that can't be truly owned by the final customers through small steps where each felt like a pro-user customer product decision.
emily-c 20 hours ago [-]
On commodity PC platforms there are both upsides and downsides of having runtime firmware in a special mode like SMM (or the secure world on ARM64 which is a whole other topic). For hardware errors (e.g. mapping row/bank/column to PA), platform workarounds, certain platform power states, power fail notifications, backwards compat, (unfortunately) extending AML by writing to port B2, etc it can be beneficial for hardware+firmware vendors to have a runtime execution environment that doesn't require shipping OS drivers. Lately the downsides of this are growing and historically security hasn't been great.
That being said, there are benefits of having SMM protect firmware integrity from a malicious/compromised kernel. On most AMD64 platforms, SPI flash can only be written to by SMM and that is a foundational piece of the PC security model (FW update, authenticated UEFI variables, etc). This has nothing to do with copy protection, DRM, or backdoors.
userbinator 19 hours ago [-]
SMM was originally conceived for power management, as it first appeared in the laptop-oriented 386SL. Then it was used for seamless backwards compatibility e.g. peripheral emulation. Unlike e.g. TPMs or other DRM-ish schemes, IMHO SMM was never hostile from the beginning.
octoberfranklin 18 hours ago [-]
I disagree. If it were not user hostile the days before BIOSes were cryptographically signed the SMM code would have no reason to disallow the kernel modifying or replacing it. Like `insmod` lets root-in-userspace modify kernel-privilege-level code.
In fact the whole situation is very much analogous to Kernel Lockdown, which is controversial.
With signed bootcode you can give a reason for not letting the userspace modify the SMM code. But when all this stuff was designed there were no bootcode signatures.
userbinator 15 hours ago [-]
the SMM code would have no reason to disallow the kernel modifying or replacing it
Don't forget that SMM code started out in A0000 --- the area of RAM that would've otherwise been inaccessible and wasted anyway, because it was usually decoded to the VGA. Also, this was the era of DOS; there was no difference between "kernel" and "application".
inigyou 8 hours ago [-]
It's like that for reliability and compatibility. The kernel on a 386 wants to stomp over everything, so if we want the kernel to not stomp on something we'd better hide it.
matheusmoreira 20 hours ago [-]
> Why do CPU vendors implement a mode that cannot be controlled by the user?
It's even worse than that. It's gotten to the point that "operating systems" aren't actually operating the system anymore. Linux is just the "user OS", a tiny blip on the overall system schematics. Just some app to be sandboxed away from the real system.
I have to agree with your overall take (only caveat being that I know too little about hardware to know if it's well-founded).
The incentives are such that if it's possible to make hardware that's cryptographically locked into being aligned against the interests of its supposed owner, that's exactly what will be, which is why we now have two fully-closed systems (Google Play Services and iOS), one 99%-closed one (macOS -- Apple controlling the 'notarization' signing and showing their willingness to use it for petty reasons proves macOS is closed), and one clearly marching toward the same basic idea (Windows).
What's more depressing is, even if suddenly every court agreed with me, we'd just transition overnight into a leasing paradigm, where vendors would cease to sell devices, only rent them to us. "As the device owner, should we not have the right to govern its use to only responsible purposes and protect it from 'mAlWaRe'?" And the devices would be quickly 'accepted' by the market, as "unmanaged" devices would be locked out of everything, just like you can't use banking apps, streaming apps, or even the McDonald's app, on a rooted/jailbroken phone today.
inigyou 8 hours ago [-]
SMM was designed for purposes like emulating the PS/2 keyboard interface when the keyboard is actually USB, or controlling fan speeds. It has to be invisible for compatibility reasons only.
pjc50 8 hours ago [-]
I would also note that "SMM requires a context switch across all cores" is also imposing a pretty heavy performance penalty when invoked.
kazinator 17 hours ago [-]
> Why do CPU vendors implement a mode that cannot be controlled by the user?
Devil's Advocate: can you control every transistor in a good old Z80?
Of course, that's not where the goalposts are. Any piece of hardware will necessarily have limits as to the amount of introspection and manipulation that it allows in the programming model.
What Intel have done is built a "grotto" in the chip that is extraneous and deliberately inaccessible.
inigyou 8 hours ago [-]
The Z80 actually has two hidden registers, called Z and W. They are used for holding the halves of 16-bit jump targets before copying them to the PC.
octoberfranklin 18 hours ago [-]
It certainly is a vulnerability, because SMM is a higher privilege level than root.
(The fact that there is such a thing as a higher privilege level than root is what annoys people).
codedokode 9 hours ago [-]
"Vulnerability" has a negative meaning, so let's name it in a positive way, like "jailbreak", "liberation" or something.
surajrmal 5 hours ago [-]
Murder has a negative meaning. Let's name it "neutralization" or "sending to a higher place".
Giving it a new name doesn't mean the original name is less correct. Vulnerability is a relative definition. It's a vulnerability in the context of the chipmakers security model but not necessarily yours. It could be a hidden feature in your world.
crest 9 hours ago [-]
That says more about your lack of both knowledge and imagination than the vendors.
Intel added SMM for software backward compatibility so DOS didn't have to learn how to suspend and resume on early laptops. Instead of waiting for operating systems to grow support for power management the SMM firmware took over when the user closed the lid. The operating systems of the time didn't know or care and user were happy it worked out of the box. Only later when hardware and software became even more complicated did it stop working reliably.
It was also used to emulate devices in firmware on cheap low-end systems so they looked like well known hardware to existing software.
You can claim it's an evil hack and I would agree, but it wasn't malicious. Also I think you can reasonable assume nobody at the time expected that this hack would last so long or that PC compatible laptops would ever have multiple CPUs.
mike_hearn 1 days ago [-]
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
wtallis 1 days ago [-]
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?
M95D 13 hours ago [-]
No need. Thunderbolt is usually susceptible to DMA attacks.
> 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!
inigyou 8 hours ago [-]
And already posted to HN a few days ago which is surely where this post originated from.
nazgulsenpai 1 days ago [-]
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.
BadBadJellyBean 1 days ago [-]
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
nazgulsenpai 1 days ago [-]
Only if the short instruction is incredibly long.
1 days ago [-]
hyperhello 1 days ago [-]
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.
mirashii 1 days ago [-]
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.
cheschire 1 days ago [-]
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?
rft 20 hours ago [-]
Chris just has some fun projects. Sandsifter was pretty well known back then due to finding that VIA x86 opcode, the movfuscator is just an amazing piece of mostly useless engineering and the fun reverse engineering psychological warfare was my first contact with his projects. I guess someone stumbled on one of his projects and others clicked through to his other projects. Many of them are a perfect fit for HN, no wonder they got posted.
fotta 18 hours ago [-]
Chris used to publish all sorts of fun wacky exploits and then stopped when he joined Intel. Putting the LinkedIn puzzle pieces together, he recently left Intel so it looks like he’s back to publishing fun wacky exploits again.
inigyou 8 hours ago [-]
Oh and he's surely got all sorts of juicy trade secrets he can't tell us but can make use of in his projects.
dnautics 21 hours ago [-]
xoreax has a famous video showing how to find hidden x86 secret instructions that... who knows who asked the manufacturer to put there. the story of the hardware setup (pxe booted via terminal pos iirc) to find it is epic because certain opcode faults could brick the machine under normal automation conditions so each pos had to be monitored and have its physical on/off tapped to do a "manual" hard reboot
ironhaven 1 days ago [-]
DEFCON the fun hacking conference in las Vegas that happened last weekend.
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?
bri3d 17 hours ago [-]
He gave a talk at Defcon.
NooneAtAll3 13 hours ago [-]
I also noticed clustering of topics lately
londons_explore 1 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.
justusthane 19 hours ago [-]
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.
inigyou 8 hours ago [-]
Reads like AI.
justusthane 3 hours ago [-]
Not to me, but who knows
toast0 1 days ago [-]
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.
PunchyHamster 1 days ago [-]
If it is critical it should not be running on same cores
inigyou 8 hours ago [-]
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.
Geezus_42 1 days ago [-]
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.
userbinator 19 hours ago [-]
IIRC clock control doesn't need to be done in SMM, especially PROCHOT which is a hardwired thermal shutdown. That said, power management is one of the things SMM was originally designed for, so it may be used for some of that.
quotemstr 1 days ago [-]
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.
cryptonector 16 hours ago [-]
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).
xxpor 1 days ago [-]
Can this be patched? Is there a chance it's a hw watchdog that you can't fix in microcode?
ramses0 1 days ago [-]
Looks like it's ~4 billion (2^32) crossover counter?
engzaanin 24 hours ago [-]
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?
inigyou 8 hours ago [-]
Someone would definitely notice if SMM took a long time. It would look like the core hung. The exploit is hanging another core outside SMM.
Liftyee 1 days ago [-]
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
PunchyHamster 1 days ago [-]
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
inigyou 8 hours ago [-]
To be fair it originates from 386. Cores didn't get much smaller and you don't want your CPU to be 1.5 times as expensive.
quotemstr 1 days ago [-]
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.
kmeisthax 1 days ago [-]
...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?!
tptacek 1 days ago [-]
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.
tuetuopay 1 days ago [-]
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.
kmeisthax 1 days ago [-]
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?
EvanAnderson 21 hours ago [-]
For other people who didn't immediately recognize "ITS and the PC2 problem" and want the backstory it starts in the last paragraph of page 312: https://web.mit.edu/~simsong/www/ugh.pdf
inigyou 8 hours ago [-]
The explanation is pretty bad. I believe this is about Unix signals. If a signal occurs, the kernel will push a signal stack frame on the user-mode stack and send the CPU to user mode to run the signal handler. When it returns it returns to the point the signal occurred. There is probably some glue to restore register values.
But if a signal comes inside a syscall the user-mode program counter is the syscall instruction, not the exact position in kernel mode within the syscall. What should the kernel push on the stack? Obviously it can't push the kernel PC as that would be a huge vulnerability, and it would lose all the state on the kernel stack anyway. If the syscall is a quick one like getpid, it can just finish the syscall and then do the signal, but if it's read, then it's a problem.
The proper solution is for read to somehow save its state, store the user PC of the syscall instruction, then exit the syscall and do the signal, and when the signal is done it goes back to the syscall. This is doable enough for read, since you just advance the buffer and decrease the length, though you still need a way to return the correct total number of bytes. It's completely infeasible for anything more complicated than that, like many ioctls.
So instead the worse-is-better solution was used. If read gets a signal, it turns itself into a "quick" syscall by just giving up on waiting for more bytes and returning whatever it has already read, which may be 0 bytes. It finishes immediately, does the syscall and returns to the syscall's caller. It is the application's problem to deal with the fact this can happen.
On Windows NT they can actually mix kernel and user stack frames arbitrarily. User code can call into kernel code that can call into user code that can call into kernel code, etc, and kernel debuggers can see the whole thing. I have no idea how they do this. Unix doesn't - Unix is strictly user code calling into kernel code via syscalls.
touisteur 23 hours ago [-]
I have a reproducible way to have a pwrite syscall on a specific SSD on a specific machine take 15+ seconds and completely block any syscall related to that SSD by any other thread or core during that amount of time. I tried and couldn't preempt it either (sched_fifo and preempt kernel options). I should have a look soon with Intel PT to check whether it's on the same instruction every time :)
inigyou 8 hours ago [-]
Won't be the same instruction. It'll be waiting for a hardware interrupt without properly preparing to handle signals at the same time because someone assumed it was fast. Kernel code isn't held together with any less duct tape than user code, although we hope it crashes less.
In Linux, any thread running in the kernel is unkillable unless that section of kernel code made arrangements to be killable. When kernel code blocks, you can get unkillable processes. They show as D state (uninterruptible wait).
tptacek 23 hours ago [-]
Oh, it totally is, it just doesn't prompt the same sense of glee and wonderment.
doc_ick 17 hours ago [-]
So we’re in agreement
xxpor 1 days ago [-]
Maybe with vfio/igb_uio/uio_pci_generic? Still root level access.
codedokode 23 hours ago [-]
You need to be root.
PunchyHamster 1 days ago [-]
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
Nextgrid 21 hours ago [-]
Until very recently, creating arbitrary USB/PCIe devices has been out of reach of hobbyists, as a result the device drivers (running with kernel privileges and written in memory-unsafe languages) generally have no hardening against a malicious device. You wouldn't need this exploit to get root (for that matter, this exploit _already_ requires root).
quotemstr 1 days ago [-]
> 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.
wtallis 16 hours ago [-]
> failing after arbitrary timeouts introduces hard-to-debug failures under load
What needs to fail here is the instruction doing insanely slow MMIO. That's not going to be too hard to debug; none of the examples of suitably slow instructions are anywhere close to reasonable, and a fault on a vmovdqu in MMIO address space is a big red flag.
And this attack requires enough ridiculous behavior from coordinating software beyond just the single super-slow instruction that it's hard to imagine any reasonable workload being affected if this case starts causing a fault.
neerajsi 13 hours ago [-]
I initially agreed with your idea, but realized the problem.
At the bus/inter agent communication level, the CPU has sent a read request and is expecting a response. These protocols are usually synchronous with no clear cancellation semantics. There are probably core resources tracking then expected response and if you just freed one of those up and ended the instruction with an exception, you could later have what appears to be an unsolicited response.
This dynamic probably repeats between the core and the pci root complex and then again between the root complex and the device implementing the mmio. Severing the request from the response is probably too complicated for such an unusual case.
inigyou 8 hours ago [-]
The MMIO itself is probably so slow because it's not implemented at some level and the level before it is timing out.
You're Intel. The year is somewhere around 1989. Your hardware interface that you export to regular software has gotten complex enough that you want to implement some of it in some kind of software that you can implement at a higher level than just logic. You also maybe want your hardware partners (ie. motherboard and system manufacturers) to be able to change parts for their implementations. Additionally some of this code might eventually end up being hard real time with the possibility of damaging the chip if it doesn't run at the correct window (think power management). You don't have the area budget for rewritable microcode of the size you'd want; this code has to live in DRAM.
You look around at the system software people are running on x86. At the highest quality you've got OS/2, and it goes downhill fast from there. Most end users are running DOS (from several vendors). So you write a higher privilege mode that runs underneath DOS, can actually be pretty close to a tiny RTOS kernel, and document it. But the whole point is to be relatively transparent, and definitely inaccessible to kernel mode, which you don't trust to pull its own pants up after it uses the bathroom.
Then later, when your corporate vendors are asking you to secure the boot chain, it only makes sense that this mode is also cryptographically signed.
And I think this is a more interesting story (and probably closer aligned to the truth). That is, we can get to an anti-user feature that can't be truly owned by the final customers through small steps where each felt like a pro-user customer product decision.
That being said, there are benefits of having SMM protect firmware integrity from a malicious/compromised kernel. On most AMD64 platforms, SPI flash can only be written to by SMM and that is a foundational piece of the PC security model (FW update, authenticated UEFI variables, etc). This has nothing to do with copy protection, DRM, or backdoors.
In fact the whole situation is very much analogous to Kernel Lockdown, which is controversial.
With signed bootcode you can give a reason for not letting the userspace modify the SMM code. But when all this stuff was designed there were no bootcode signatures.
Don't forget that SMM code started out in A0000 --- the area of RAM that would've otherwise been inaccessible and wasted anyway, because it was usually decoded to the VGA. Also, this was the era of DOS; there was no difference between "kernel" and "application".
It's even worse than that. It's gotten to the point that "operating systems" aren't actually operating the system anymore. Linux is just the "user OS", a tiny blip on the overall system schematics. Just some app to be sandboxed away from the real system.
https://youtu.be/36myc8wQhLo
The incentives are such that if it's possible to make hardware that's cryptographically locked into being aligned against the interests of its supposed owner, that's exactly what will be, which is why we now have two fully-closed systems (Google Play Services and iOS), one 99%-closed one (macOS -- Apple controlling the 'notarization' signing and showing their willingness to use it for petty reasons proves macOS is closed), and one clearly marching toward the same basic idea (Windows).
What's more depressing is, even if suddenly every court agreed with me, we'd just transition overnight into a leasing paradigm, where vendors would cease to sell devices, only rent them to us. "As the device owner, should we not have the right to govern its use to only responsible purposes and protect it from 'mAlWaRe'?" And the devices would be quickly 'accepted' by the market, as "unmanaged" devices would be locked out of everything, just like you can't use banking apps, streaming apps, or even the McDonald's app, on a rooted/jailbroken phone today.
Devil's Advocate: can you control every transistor in a good old Z80?
Of course, that's not where the goalposts are. Any piece of hardware will necessarily have limits as to the amount of introspection and manipulation that it allows in the programming model.
What Intel have done is built a "grotto" in the chip that is extraneous and deliberately inaccessible.
(The fact that there is such a thing as a higher privilege level than root is what annoys people).
Giving it a new name doesn't mean the original name is less correct. Vulnerability is a relative definition. It's a vulnerability in the context of the chipmakers security model but not necessarily yours. It could be a hidden feature in your world.
Intel added SMM for software backward compatibility so DOS didn't have to learn how to suspend and resume on early laptops. Instead of waiting for operating systems to grow support for power management the SMM firmware took over when the user closed the lid. The operating systems of the time didn't know or care and user were happy it worked out of the box. Only later when hardware and software became even more complicated did it stop working reliably.
It was also used to emulate devices in firmware on cheap low-end systems so they looked like well known hardware to existing software.
You can claim it's an evil hack and I would agree, but it wasn't malicious. Also I think you can reasonable assume nobody at the time expected that this hack would last so long or that PC compatible laptops would ever have multiple CPUs.
> 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!
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?
Presumably the patch for that will be to make it an infinity timeout.
> 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.
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?
But if a signal comes inside a syscall the user-mode program counter is the syscall instruction, not the exact position in kernel mode within the syscall. What should the kernel push on the stack? Obviously it can't push the kernel PC as that would be a huge vulnerability, and it would lose all the state on the kernel stack anyway. If the syscall is a quick one like getpid, it can just finish the syscall and then do the signal, but if it's read, then it's a problem.
The proper solution is for read to somehow save its state, store the user PC of the syscall instruction, then exit the syscall and do the signal, and when the signal is done it goes back to the syscall. This is doable enough for read, since you just advance the buffer and decrease the length, though you still need a way to return the correct total number of bytes. It's completely infeasible for anything more complicated than that, like many ioctls.
So instead the worse-is-better solution was used. If read gets a signal, it turns itself into a "quick" syscall by just giving up on waiting for more bytes and returning whatever it has already read, which may be 0 bytes. It finishes immediately, does the syscall and returns to the syscall's caller. It is the application's problem to deal with the fact this can happen.
On Windows NT they can actually mix kernel and user stack frames arbitrarily. User code can call into kernel code that can call into user code that can call into kernel code, etc, and kernel debuggers can see the whole thing. I have no idea how they do this. Unix doesn't - Unix is strictly user code calling into kernel code via syscalls.
In Linux, any thread running in the kernel is unkillable unless that section of kernel code made arrangements to be killable. When kernel code blocks, you can get unkillable processes. They show as D state (uninterruptible wait).
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
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.
What needs to fail here is the instruction doing insanely slow MMIO. That's not going to be too hard to debug; none of the examples of suitably slow instructions are anywhere close to reasonable, and a fault on a vmovdqu in MMIO address space is a big red flag.
And this attack requires enough ridiculous behavior from coordinating software beyond just the single super-slow instruction that it's hard to imagine any reasonable workload being affected if this case starts causing a fault.
At the bus/inter agent communication level, the CPU has sent a read request and is expecting a response. These protocols are usually synchronous with no clear cancellation semantics. There are probably core resources tracking then expected response and if you just freed one of those up and ended the instruction with an exception, you could later have what appears to be an unsolicited response.
This dynamic probably repeats between the core and the pci root complex and then again between the root complex and the device implementing the mmio. Severing the request from the response is probably too complicated for such an unusual case.