Screen lock confidentiality [LWN.net]

Screen lock confidentiality

Posted Jun 11, 2024 20:49 UTC (Tue) by willy (subscriber, #9762)
In reply to: Screen lock confidentiality by Tobu
Parent article: Dropping the page cache for filesystems

The point of the pagecache is to support mmap(). That's not compatible with "keep all data in the page cache encrypted".

to post comments

Screen lock confidentiality

Posted Jun 12, 2024 1:16 UTC (Wed) by intelfx (subscriber, #130118) [Link] (3 responses)

> The point of the pagecache is to support mmap(). That's not compatible with "keep all data in the page cache encrypted".

It's not compatible with _keeping_ all the data encrypted, but perhaps the GP meant the en-/decryption of the pagecache contents as a one-off operation (same semantics as suspending/resuming the LUKS volume).

I don't see an immediate reason why that wouldn't work — just mark all the PTEs as not present, similar to them being swapped out.

Screen lock confidentiality

Posted Jun 12, 2024 1:34 UTC (Wed) by willy (subscriber, #9762) [Link] (2 responses)

What's annoying about this whole proposal is how under specified it is.

It starts out with "we want the page cache to be inaccessible". Then it turns out to be OK if 99% of pages are inaccessible, but 1% are still accessible. But a purely programmatic prohibition is unacceptable because evilmaid attacks. But we don't care enough about evilmaid attacks to zero pages which are being evicted from the pagecache.

It all feels like "we want to feel secure but we don't want to pay very much for it".

Screen lock confidentiality

Posted Jun 12, 2024 20:10 UTC (Wed) by stevie-oh (subscriber, #130795) [Link] (1 responses)

I disagree. I believe it's a matter of "we should take feasible steps towards maximizing security."

Treating anything less than exactly 100% secure as being the same as 0% secure is the sort of thing the cryptography/security people frequently do, which tends to set Linus off (and I agree with him.)

The troublesome feature in question seems to be "cryptsetup-suspend", which (according to the documentation) flushes all pending writes to disk and then purges the encryption (more relevantly here, *decryption*) keys from memory. After this point, up until cryptsetup-luksresume is executed to reload the key (presumably the result of the user reauthenticating themselves), any attempt to read from the encrypted block device will fail.

However, not all attempts to read from the *filesystem* will result in reads from the *block device*. Sometimes everything needed to read a file on that filesystem is still in the page cache, in which case that file -- one that is nominally stored on an encrypted filesystem for which the system does not have the decryption keys available -- is still readable.

The request is simple: provide some sort of method to tell the kernel to evict as much information as possible from its own caches. The article points out that there are many cases where a page cannot be evicted:

1. It's part of an active vmsplice call
2. It's part of a DMA operation (especially an RDMA operation)
3. It's mapped as executable code (e.g. a running binary)

I would expect (and based on the article, the kernel devs agree with me) that the overwhelming majority of the files one would be interested in keeping secret don't fall into any of these categories. I'm not likely to be vmsplicing or RDMAing my SSH private key anywhere.

It *is* quite reasonable for me to be executing code from an encrypted block device -- as a software developer, a *lot* of the executables that I run are from my home directory, because I just compiled them. But I'm not super concerned about someone gaining access to such an executable via the page cache. And if I *am*, well, then it's on me to make sure I kill that process before I close the lid on my laptop.

Screen lock confidentiality

Posted Jun 12, 2024 20:27 UTC (Wed) by willy (subscriber, #9762) [Link]

FYI, I'm the Matthew Wilcox quoted in the above article.