sensitive [LWN.net]

sensitive

Posted Apr 4, 2025 4:05 UTC (Fri) by NYKevin (subscriber, #129325)
In reply to: sensitive by mb
Parent article: Page allocation for address-space isolation

Based on the article, they appear to be including all file blocks. That seems like a good starting point, but there are a number of other things that are "obviously" at least as sensitive as file blocks:

* All components of the RNG state (especially the entropy pool).
* memfds, pipe buffers, etc., basically anything where you're holding userspace's data for a little while.
* Drivers?

OTOH, if something is routinely displayed in e.g. top(1) without anyone getting upset about it being visible (PIDs, command lines, resource metrics, etc.), then it's probably not sensitive. I imagine that makes most if not all of the scheduler non-sensitive by extension (but I could be mistaken).

to post comments

sensitive

Posted Apr 4, 2025 12:00 UTC (Fri) by bjackman (subscriber, #109548) [Link]

Yeah, it's tricky.

All the code I've posted so far just says everything allocated as GFP_USER is sensitive. So, not just file pages but also all anonymous user pages are sensitive. This already goes a pretty long way (it certainly adds a huge amount of extra engineering work for an attacker starting from a pre-ASI exploit) but as you've pointed out there are obvious things that it doesn't include that need to be protected. The other classic example to my mind is stuff copied into the kernel stack from userspace/VM guests.

In principle we should be able to flip this question on its head and instead make the question "what _isn't_ sensitive", i.e. isntead of marking stuff as __GFP_SENSITIVE with the default being unprotected (we call this "denylist"), we could protect erverything by default and mark exceptions as __GFP_NONSENSITIVE (we call this "allowlist"). So far the general feeling has been that it's more practical to start from something that people can actually deploy and evaluate without worrying about an unpredictable performance disaster. But we could certainly switch to an allowlist model later down the line, it would make good sense to me.