https://github.com/jprx/darwin-vm
For the past few months, I've been building support for running the latest SPTM-based versions of iOS and macOS into qemu. The idea is to create a lightweight barebones environment for playing around with / debugging XNU and low-level Darwin internals, kind of like a tiny busybox Linux system except running Darwin, and using an emulated Apple Silicon CPU (custom instructions/ privilege levels...
The full paper, slides from my S&P talk, and all our experiment data can be found at the Fractal project website here: https://fractal-os.com
We've been building Fractal internally for a very long time (first commit was almost exactly 2 years ago), so it's exciting to finally share it with the world. Let me know what you think!
Hopefully someone out there finds it useful!
- Most academic research has been done on Intel systems, so it's easier for students reading papers to relate to their experiences in the labs
- X86_64 provides convenient cache flush and cycle measurement instructions in userspace
- Intel's strongly ordered memory model and cache inclusion policy makes cross-core side channels simpler to reason about
- Practically, it's easier to scale up server infrastructure on Intel (you can do most of the labs on inexpensive Intel-based Linux systems)
- For Rowhammer, our students attack one particular kind of DRAM that we have profiled and know works well with our machines
- Note that AMD's cache inclusion policy differs from Intel's- we only support Intel chips for now
Down the road I could see us moving to ARM for a few labs (perhaps a future PACMAN attack lab...?)
Our labs include building your own real spectre attack against the kernel, bypassing ASLR and building ROP chains with various side channels, finding and exploiting backdoors in a RISC-V CPU by building a hardware fuzzer, and more.
(source: I designed the Spectre lab plus a few others)
All our labs are fully open source for anyone to try: https://github.com/MATCHA-MIT/SHD-StarterCode
If you give them a try, please do let us know what you think! We genuinely want these activities to be fun and approachable (we designed them like a big CTF) and welcome feedback from the community.
User mode software requires a TLB (unless you want to do a page walk for every single instruction!)
Even if you could remove the TLB entirely from the CPU somehow, the attacker could just use the cache or some other microarchitectural structure.
In practice, both of these would probably kill performance, so I don't think either of these are great solutions. Recall we are targeting the kernel where everything needs to be as fast as possible.
(There are a few aspects that make this challenging in practice, but that's the idea).
1) Our attack does apply a brute force technique with the twist that crashes are suppressed via speculative execution. If you tried to brute force a PAC against the kernel, you'd instantly panic your device and have to reboot.
2) Given that we never sign anything (only try to verify a signed pointer), and that every authentication attempt happens under speculation, I'm not sure how you would rate limit this without absolutely destroying performance. Keep in mind the kernel is doing a whole lot more with PAC than just our attack (for example, every function's return address is also signed with PAC) so distinguishing valid uses from a PACMAN attack might be challenging.
I suppose you could track how many speculative PAC exceptions you got, but it's a little late to add that now isn't it? And it could also raise lots of false positives due to type confusion style mechanisms on valid mispredicted paths.
Our goal is to demonstrate that we can learn the PAC for a kernel pointer from userspace. Just demonstrating that this is even possible is a big step in understanding of how mitigations like pointer authentication can be thought of in the spectre era.
We do not aim to be a zero day, but instead aim to be a way of thinking about attacks/ an attack methodology.
The timer used in the attack does not require a kext (we just use the kext for doing reverse engineering) but the attack itself never uses the kext timer. All of the attack logic lives in userspace.
Provided the attacker finds a suitable PACMAN Gadget in the kernel (and the requisite memory corruption bug), they can conduct our entire attack from userspace with our multithread timer. You are correct that the PACMAN Gadget we demonstrate in the paper does live in a kext we created, however, we believe PACMAN Gadgets are readily available for a determined attacker (our static analysis tool found 55,159 potential spots that could be turned into PACMAN Gadgets inside the 12.2.1 kernel).
Our paper is available at our website: https://pacmanattack.com/paper.pdf
The PDF is available here: https://pacmanattack.com/paper.pdf