[OC] Reviving and Advancing Page Cache Attacks on Linux (My first publication as a PhD student!)

submitted by
edited

snee.la/posts/eviction-notice/

Hi everyone! I’m happy to share that my first first-author paper has been accepted to a conference recently about side-channel attacks on the Linux page cache.

Side-channel attacks on the page cache (first shown in 2019 by my PhD advisor et al.) were thought to have been mitigated since 2019 or thought to be impractical for a long time. Work that I (+my co-authors) did over the past year showed that such attacks were very possible, but also way more severe than initially thought.

It started out with me randomly encountering the cachestat syscall, introduced in kernel 6.5 (2022) to query the state of OS pages in the page cache. After a bit of investigation, we found that it leaks whether pages are in the page cache, including of globally-readable files not owned by that user.

I have a few examples of what attacks are possible on the linked blog post, but the tl;dr is you can detect whether binaries are run (like pkexec, which is the GUI that pops up for password prompts), infer which websites a different local-user visits on Firefox (via the libxul shared library), infer user and system behavior across docker containers, and a few more.

We also found a few more interesting stuff, like the posix_fadvise syscall with the POSIX_FADV_DONTNEED can deterministically remove pages from cache. The other fine grained details are available in the paper: https://snee.la/pdf/pubs/eviction-notice.pdf, but a general write up is in the blog post.

The cachestat vulnerability was assigned CVE-2025-21691 and was fixed by Linus Torvalds himself (first time interacting with him!)

Since I know Lemmy loves Linux (as much as I do, or even more), I thought I’d share it here :D. Feel free to ask any questions if you have any!

There’s also a Github repository of our code which has been peer-reviewed to be reproducible here: https://github.com/isec-tugraz/Eviction-Notice

10
146
1

Log in to comment

Hot Top New Old

This is so cool! Thanks for your work uncovering these things, and thanks for posting it.

 reply
24

Awesome work. Thanks for sharing!

 reply
15
edited

Congratulations on your first first-author publication in a conference. The topic seems very interesting and I have yet to give the paper a good read-through, but I already like how well-presented it is.

Did you use TikZ for the diagrams and matplotlib for the graphs?

 reply
15
OP

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.

 reply
9
edited

The patterns in the plots did have a pgf vibe to it, so that makes sense.

In case you’re not aware, it is also possible to have pgf outputs that preserve scaling with matplotlib with similar serif fonts for the labels that you can specify in matplotlibrc of the project. Hopefully you’d find that useful if you ever decide to use matplotlib beyond some quick plots.

 reply
3
OP

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.

 reply
4

That colourblind palette is golden, thank you for sharing it. And I was just talking about me wanting have a crack at creating that arrow myself, but thank you for offering to share. I’ll be sure to reach out if I find myself being unable to replicate it.

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:

import matplotlib.pyplot as plt
import matplotlib

matplotlib.use('pgf')

fig, ax = plt.subplots()
# Code related to plotting here

fig.savefig("outputfile.pgf")

with relevant rcParams options in matplotlibrc, then import the pgf with:

\begin{figure}[h]
    \centering
      \resizebox{\linewidth}{!}{
        \input{outputfile.pgf}
      }
    \caption{Caption here.}
\end{figure}

But Python -> CSV -> LaTeX/pgf pipeline is quite smooth, for sure. I understand why you’d decide to opt for it without involving too many third-party dependencies.

 reply
2
OP

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

 reply
1

I’d be glad to stay in contact about this. Feel free to let me know of your website/preferred email whenever convenient.

 reply
1
Continue thread

Comments in Linux@programming.dev

Thanks for cross-posting and tagging me!

 reply
7
OP

Np, if you’re wondering why it was so quick:

::: spoiler Why am I cross-posting .ml content?
>

I cross-post from .ml to the nearest relevant non-.ml comm to reduce the influence of .ml comms and indirectly, the instance as a whole, to make it an easier decision for other instance admins to defederate because one key reason I identified that admins don’t want to defederate is because .ml still has some very large comms and some niche comms.

Megathread on the issue

Some highlights from the link:

“Don’t worry guys, the Uyghur Genocide was REALLY just birth control! ~dessalines, .ml admin, dev https://lemmy.world/post/30580167

“See! nobody died IN Tiananmen Square, just AROUND it, so it doesn’t count!!” ~ Davel, .ml admin
https://lemmy.world/post/30673342

.ml admin, Nutomics continued transphobia https://lemmy.world/post/29222558
The original transphobic Comment from Nutomic: https://lemmy.world/post/18236068

“NK is actually good and anything counter to that is Western propaganda!” ~dessalines, .ml admin, dev https://lemmy.world/post/31595035

General negative sentiment to other instances who haven’t “seen the way” yet ~davel, .ml admin https://lemmy.world/post/27426510

“If you don’t support Russia then you just don’t understand geopolitics” ~dessalines, .ml admin, dev https://lemmy.world/post/27352415

And so so much documentation on clear heavy handed censorship and bias also on the link. So much I can’t even put them all here because this comment would be really long.

I believe the behavior of its admins (the main admins are Lemmy devs) does harm to the overall growth of the Lemmy-verse and maybe even the Thrediverse (since Lemmy kinda kicked off the Thrediverse) because of its association with the devs of Lemmy and their insistence to use .ml as their personal political platform to spread harmful propaganda

On the outside, bringing up Lemmy frequently leads to comments like “Lemmy? Isn’t that the place with a bunch of tankies?” Or “Tried Lemmy, but found it full of pro Russia crap so I left”. The best way forward from that I see is to either widely defederate from .ml like the rest of the Triad, or pressure them to put a fair and unbiased as possible admin team.
:::

 reply
11

Thanks for sharing your work!

Do you feel there is anything deeply problematic with the page cache that would make this kind of side channel likely to be around elsewhere too or is it more of a specific case?

 reply
4

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

 reply
1
Insert image