My website’s the one linked in this post: https://snee.la/

My email is at the contact page: https://snee.la/contact/

sneela [at] tugraz [dot] at

I’ll be sure to reach out if I find myself being unable to replicate it.

No worries, and good luck! My email can be found on my website if you want it :D

I wasn’t even talking about tikzplotlib. It’s just that pgf backend is now supported by matplotlib and you can produce pgf files with.

Ah… I’ve think I’ve heard of it, but I never really registered that. Thanks for the info :D

I could give you the tikz source of Fig 2 if you’d like. The patterns and colors of the plots took me almost a day to choose. I wanted to go for a color-blind friendly pallette and keep it looking still snazzy. (https://github.com/simon-pfahler/colorblind)

I’m familiar with matplotlib -> PGFplots (using the Python tikzplotlib library). Unfortunately, I’ve decided against using it for the paper as it produces quite unmanageable outputs. Especially if I rerun experiments + with new data, and later want to change patterns, colors… It was always more of a hassle. I used it for my Master’s thesis.

Instead, Python program -> show plot -> if okay, generate CSV.

In LaTeX, have PGFplot code which reads CSV file and generates the data that way. Much, much easier to maintain.

Thanks for your words!

Yes! We use TikZ for the diagrams, which can be a nightmare sometimes… but it gets better the more I use it.

Regarding the plots, we use PGFplots. I often use matplotlib for quick plots while running experiments, but the paper itself uses PGFplots with the data in a CSV for that sweet, sweet scaling when you zoom in.

Thanks for the question!

As long as caches have existed, very similar styles of side channels have been demonstrated since the late 90s. A lot of the terminology we use (flush+reload, flush+flush…) are attack techniques that have been already demonstrated on CPU caches, and these demonstrations are at least a decade old.

Flush+Reload: https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/yarom

Flush+Flush: https://gruss.cc/files/flushflush.pdf

Invalidate+Compare (GPU caches, 2024): https://www.usenix.org/conference/usenixsecurity24/presentation/zhang-zhenkai

My colleague, Hannes, found similar styles of attacks existed with the Linux DNS cache too: https://hannesweissteiner.com/pdfs/dmt.pdf (also published at NDSS 26!)

The one really big difference between the page-cache side channel and other side channels is the “monitor” primitive. There are methods that the OS provides which directly report the presence of a page in cache. These are syscalls like mincore (mitigated in 2019), preadv2 + rwf_nowait (unmitigated), and cachestat (mitigated in 2025).

With these syscalls, we don’t even have to rely on timing information (is page access fast -> cached; is it slow -> not cached). These syscalls really set the page-cache side channel apart because you can nondestructively figure out whether a page is in cache.

The page-cache side channel was first explored in 2019. It was explored on Linux but also on Windows by my advisor et al.: https://gruss.cc/files/pagecacheattacks.pdf

Hope this answers your question :D

Thanks for cross-posting and tagging me!