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

51–60 of 77 posts

Re: Exploiting System Management Mode with a very long interrupt

#51

Post by octoberfranklin »

userbinator wrote: post #48
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…

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.

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.

Re: Exploiting System Management Mode with a very long interrupt

#52

Post by bri3d »

cheschire wrote: post #25
_def wrote: post #24

Earlier quoted context omitted.

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?

He gave a talk at Defcon.

Re: Exploiting System Management Mode with a very long interrupt

#53

Post by kazinator »

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…

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

Re: Exploiting System Management Mode with a very long interrupt

#54

Post by doc_ick »

tptacek wrote: post #37
kmeisthax wrote: post #23

Earlier quoted context omitted.

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.

So we’re in agreement

Re: Exploiting System Management Mode with a very long interrupt

#56

Post by cryptonector »

londons_explore wrote: post #4

Unclear why there is a 1 second timeout at all. Presumably the patch for that will be to make it an infinity timeout.

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

Re: Exploiting System Management Mode with a very long interrupt

#57

Post by wtallis »

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…

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

Re: Exploiting System Management Mode with a very long interrupt

#58

Post by userbinator »

octoberfranklin wrote: post #51
userbinator wrote: post #48

Earlier quoted context omitted.

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.

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 mo…

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".

Re: Exploiting System Management Mode with a very long interrupt

#59

Post by neerajsi »

wtallis wrote: post #57
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…

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

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.

Re: Exploiting System Management Mode with a very long interrupt

#60

Post by NooneAtAll3 »

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?

I also noticed clustering of topics lately
Post reply on HN