alt Hacker NewsHi 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!
Replies
At the risk of sounding extremely dumb, I have a question for you: if the hardware is susceptible to something that you can't actually reproduce with the software everyone runs on it, who should care, and why? Is it even really fair to call it a vulnerability at that point? Is the idea that this is supposed to help identify a different mechanism of exploiting the vulnerabilities with the shipped OS too?
To give an analogy, it almost feels like removing the protection circuitry from a Li-Ion battery and then testing if it can catch fire, and observing that it does. Should it really worry users?
chapeau for this project - and thanks for sharing it with the world!
have you considered forking existing OS and implementing changes that you needed instead?
it's hard for me to justify the tremendous effort of implementing the OS from scratch, instead of adding the functionality that you need to for example linux or xv6.
> (it) exposes primitives that let a single experiment switch privilege levels at runtime while executing the same instructions in the same address space.
i think that it can be achieved by following linux modifications:
- make all executable pages executable both in user and kernel mode
- define a new syscall number, let's call it 'fractal'
- upon 'svc' trap (syscall), if it's a fractal syscall, just branch to instruction after the 'svc' (still in kernel mode! no 'eret', as opposed to no-fractal syscalls)
and.. that's it?
I didn’t quite understand the scope of impact of the issues highlighted in the article.
> The CPU still fetches the target into the instruction cache before the protection kicks in.
> In Phantom, ordinary instructions, including a no-op, can be misinterpreted by the CPU as branches, triggering speculative behavior the program never asked for.
Is the idea you combine these two to execute a BTB style attack? Is there a world in which speculative cache fetching is still fine if it’s non exploitable or is it always a risk and the performance cost of fixing the hardware negligible?
> The Fractal team showed that the conditional branch predictor has no privilege isolation at all
This one seems more serious. Now that it’s confirmed, does it provide a map for how to exploit it in a real system or is this non-exploitable in practice because of OS design choices around migration?