61–70 of 77 posts
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?
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…
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.
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…
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).
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…
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…
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? 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
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 deliber…
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!
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?
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.
Unclear why there is a 1 second timeout at all. Presumably the patch for that will be to make it an infinity timeout.
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.