Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs

From: Russell Haley <yumpusamongus@gmail.com>
To: Christian Brauner <brauner@kernel.org>,
	Dave Chinner <david@fromorbit.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-btrfs@vger.kernel.org,
	linux-block@vger.kernel.org, Matthew Wilcox <willy@infradead.org>,
	Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@infradead.org>,
	adrianvovk@gmail.com
Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs
Date: Mon, 5 Feb 2024 11:39:52 -0600	[thread overview]
Message-ID: <f6fa8310-9aa7-4b1e-9d7d-c9ca67d7dc38@gmail.com> (raw)
In-Reply-To: <20240117-yuppie-unflexibel-dbbb281cb948@brauner>

On 1/17/24 07:19, Christian Brauner wrote:

> And drop_caches is a big hammer simply because there are workloads where
> that isn't feasible. Even on a modern boring laption system one may have
> lots of services. On a large scale system one may have thousands of
> services and they may all uses separate images (And the border between
> isolated services and containers is fuzzy at best.). And here invoking
> drop_caches penalizes every service.
> 
> One may want to drop the contents of _some_ services but not all of
> them. Especially during suspend where one cares about dropping the page
> cache of the home directory that gets suspended - encrypted or
> unencrypted.
> 
> Ignoring the security aspect itself. Just the fact that one froze the
> block device and the owning filesystem one may want to go and drop the
> page cache as well without impacting every other filesystem on the
> system. Which may be thousands. One doesn't want to penalize them all.

I'm not following the problem with dropping all the caches, at least for
the suspend use case rather than quick user switching. Suspend takes all
the services on the machine offline for hundreds of milliseconds
minimum.  If they don't hit the ground running... so what?

drop_caches=3 gets the metadata too, I think, which should protect the
directory structure.

>>
>> FWIW, focussing on purging the page cache omits the fact that
>> having access to the directory structure is a problem - one can
>> still retrieve other user information that is stored in metadata
>> (e.g. xattrs) that isn't part of the page cache. Even the directory
>> structure that is cached in dentries could reveal secrets someone
>> wants to keep hidden (e.g code names for operations/products).
> 
> Yes, of course but that's fine. The most sensitive data and the biggest
> chunks of data will be the contents of files. We don't necessarily need
> to cater to the paranoid with this.
> 

If actual security is not required, maybe look into whatever Android is
doing? As far as I know it has similar use pattern and threat model
(wifi passwords, session cookies, and credit card numbers matter;
exposing high-entropy metadata that probably uniquely identifies files
to anyone who has seen the same data elsewhere is fine).

But then, perhaps what Android does is nothing, relying on locked
bootloaders and device-specific kernels to make booting into a generic
memory dumper sufficiently difficult.

>>
>> So if we want luksSuspend to actually protect user information when
>> it runs, then it effectively needs to bring the filesystem right
>> back to it's "just mounted" state where the only thing in memory is
>> the root directory dentry and inode and nothing else.
> 
> Yes, which we know isn't feasible.
> 
>>
>> And, of course, this is largely impossible to do because anything
>> with an open file on the filesystem will prevent this robust cache
>> purge from occurring....
>>
>> Which brings us back to "best effort" only, and at this point we
>> already have drop-caches....
>>
>> Mind you, I do wonder if drop caches is fast enough for this sort of
>> use case. It is single threaded, and if the filesystem/system has
>> millions of cached inodes it can take minutes to run. Unmount has
>> the same problem - purging large dentry/inode caches takes a *lot*
>> of CPU time and these operations are single threaded.
>>
>> So it may not be practical in the luks context to purge caches e.g.
>> suspending a laptop shouldn't take minutes. However laptops are
>> getting to the hundreds of GB of RAM these days and so they can
>> cache millions of inodes, so cache purge runtime is definitely a
>> consideration here.
> 
> I'm really trying to look for a practical api that doesn't require users
> to drop the caches for every mounted image on the system.
> 
> FYI, I've tried to get some users to reply here so they could speak to
> the fact that they don't expect this to be an optimal solution but none
> of them know how to reply to lore mboxes so I can just relay
> information.
> 

User replying here :-)

One possible alternative would be to use suspend-to-encrypted-swap
instead of suspend-to-RAM. It feels like it was left to rot as memory
sizes kept growing and disk speeds didn't, but that trend has reversed.
NVMe SSDs can write several GB/s if fed properly. And hasn't there been
a recent push for authenticated hibernation images?

That would also protect the application memory, which could be quite
sensitive I think because of session cookies, oauth tokens, and the
like. I assume that a sophisticated adversary with access to a memory
image of my logged-in PC would be able to read my email and impersonate
me for at least a week.