jprx
Joined 4 years ago
Karma
649
Submissions
24
Member since
Jun 10
Recent submissions
Comment · 4 months ago
Haven't gotten around to it yet haha
Comment · 4 months ago
Hi everyone, Joseph (paper author) here. You can find Fractal on Github: https://github.com/jprx/fractal
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!
Comment · 1 year ago
You can find PDFs of the lectures as well as the reading list here:
Comment · 1 year ago
Personally, I learned programming when I was a kid by watching YouTube tutorials + reading random Internet sources. When helping build SHD, it was important to me that we "paid it forward" & made all our lab materials open for everyone to learn from.
Hopefully someone out there finds it useful!
Comment · 1 year ago
We teach using Intel X86_64 CPUs for a variety of reasons
- 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...?)
Comment · 1 year ago
Yes!
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.
Comment · 2 years ago
You get it!!
Comment · 4 years ago
Unwinding changes to the TLB on every mispredict would have a significant overhead and hurt overall performance. Removing valid data you just cached (speculatively or otherwise) is generally a bad idea.
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.
Comment · 4 years ago
Additionally, if can find a way to trick a user into installing a malicious kext, why even bother with PACMAN? You already have arbitrary kernel code execution!
Comment · 4 years ago
You could maybe do it with lots of fences or just a ridiculous chain of NOPs after each branch such that the ROB is cleared before you have time to try to load a pointer speculatively.
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.
Comment · 4 years ago
Pretty much!
(There are a few aspects that make this challenging in practice, but that's the idea).