TL;DR: This is analogous to using mlock() to keep secret keys and stuff from being swapped to disk. You use CATalyst to lock your vulnerable-to-Flush+Reload pages, and it tries to guarantee accesses to those pages will always result in a cache hit: "...our security guarantee is that secure pages always hit in the secure partition of the LLC. If data in a secure page was ever evicted out of the secure partition, it would become susceptible to attacks." The downside is that only a tiny amount of memory can be locked into the cache, and applications have to be built knowing they're vulnerable to Flush+Reload attacks and call an API to secure their vulnerable pages.
That doesn't work against input distinguishing attacks since the amount of code you'd have to lock into the cache (i.e. the entire program, unless you have time to figure out which parts of your HTML parser code leak distinguishing info about the input) is probably too much.
TL;DR: This is analogous to using
mlock()to keep secret keys and stuff from being swapped to disk. You use CATalyst to lock your vulnerable-to-Flush+Reload pages, and it tries to guarantee accesses to those pages will always result in a cache hit: "...our security guarantee is that secure pages always hit in the secure partition of the LLC. If data in a secure page was ever evicted out of the secure partition, it would become susceptible to attacks." The downside is that only a tiny amount of memory can be locked into the cache, and applications have to be built knowing they're vulnerable to Flush+Reload attacks and call an API to secure their vulnerable pages.That doesn't work against input distinguishing attacks since the amount of code you'd have to lock into the cache (i.e. the entire program, unless you have time to figure out which parts of your HTML parser code leak distinguishing info about the input) is probably too much.
I adjusted the wording in the paper.