Hacker News

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?

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.

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.

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

> 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

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

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

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

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.

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.

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.

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

DEFCON the fun hacking conference in las Vegas that happened last weekend.

I also noticed clustering of topics lately

This rosenbridge repos commits claim to be 8 years old https://github.com/xoreaxeaxeax/rosenbridge

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.

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.

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

Can this be patched? Is there a chance it's a hw watchdog that you can't fix in microcode?

Looks like it's ~4 billion (2^32) crossover counter?

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.

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.

Maybe with vfio/igb_uio/uio_pci_generic? Still root level access.

You need to be root.

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

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