Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploiting System Management Mode with a very long interrupt

github.com

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Exploiting System Management Mode with a very long interrupt

#31

Post by mirashii »

hyperhello wrote: post #14

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.

Re: Exploiting System Management Mode with a very long interrupt

#32

Post by [deleted] »

quotemstr wrote: post #28

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

[deleted]

Re: Exploiting System Management Mode with a very long interrupt

#34

Post by codedokode »

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.

Re: Exploiting System Management Mode with a very long interrupt

#36

Post by touisteur »

kmeisthax wrote: post #23
tptacek wrote: post #12

Earlier quoted context omitted.

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.

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?

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 :)

Re: Exploiting System Management Mode with a very long interrupt

#37

Post by tptacek »

kmeisthax wrote: post #23
tptacek wrote: post #12

Earlier quoted context omitted.

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.

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?

Oh, it totally is, it just doesn't prompt the same sense of glee and wonderment.

Re: Exploiting System Management Mode with a very long interrupt

#38

Post by dnautics »

cheschire wrote: post #22

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?

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

Re: Exploiting System Management Mode with a very long interrupt

#39

Post by xp84 »

codedokode wrote: post #34

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, et…

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.

Re: Exploiting System Management Mode with a very long interrupt

#40

Post by EvanAnderson »

kmeisthax wrote: post #23
tptacek wrote: post #12

Earlier quoted context omitted.

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.

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?

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
Post reply on HN