Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • ...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?!

    by kmeisthax
  • You need to be root.
    by codedokode
  • Maybe with vfio/igb_uio/uio_pci_generic? Still root level access.
    by xxpor
  • 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

    by PunchyHamster
  • 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.
    by tptacek
  • 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?
    by engzaanin
  • 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.
    by inigyou
  • 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
    by Liftyee
  • One question, the firmware the repo shows seems to come from tianocore. How would you know what firmware your OEM is using? What if they have some other kind of configuration? Also I'm kind of surprised that the firmware can execute instructions like this, I was under the impression that after booting the firmware basically has finished it's job and is never touched again.
    by podocarp
  • Unclear why there is a 1 second timeout at all.

    Presumably the patch for that will be to make it an infinity timeout.

    by londons_explore
  • Looks like it's ~4 billion (2^32) crossover counter?
    by ramses0
  • Can this be patched? Is there a chance it's a hw watchdog that you can't fix in microcode?
    by xxpor
  • 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).
    by cryptonector
  • 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.

    by toast0
  • 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.

    by justusthane
  • 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?

    by cheschire
  • I also noticed clustering of topics lately
    by NooneAtAll3
  • This rosenbridge repos commits claim to be 8 years old https://github.com/xoreaxeaxeax/rosenbridge
    by _def
  • DEFCON the fun hacking conference in las Vegas that happened last weekend.
    by ironhaven
  • 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
    by dnautics
  • 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.
    by fotta
  • 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.
    by rft
  • 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

    by PunchyHamster
  • 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.
    by inigyou
  • 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.
    by quotemstr
  • 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.
    by hyperhello
  • 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.
    by mirashii
  • 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.
    by nazgulsenpai
  • 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
    by BadBadJellyBean
  • 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!

    by Hyperlisk