linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Christian Brauner <brauner@kernel.org>,
	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, Jan Kara <jack@suse.cz>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs
Date: Tue, 16 Jan 2024 15:40:02 +0000	[thread overview]
Message-ID: <ZaajUn0Idp90hLir@casper.infradead.org> (raw)
In-Reply-To: <458822c2889a4fce54a07ce80d001e998ca56b48.camel@HansenPartnership.com>

On Tue, Jan 16, 2024 at 10:25:20AM -0500, James Bottomley wrote:
> On Tue, 2024-01-16 at 11:50 +0100, Christian Brauner wrote:
> > So when we say luksSuspend we really mean block layer initiated
> > freeze. The overall goal or expectation of userspace is that after a
> > luksSuspend call all sensitive material has been evicted from
> > relevant caches to harden against various attacks. And luksSuspend
> > does wipe the encryption key and suspend the block device. However,
> > the encryption key can still be available clear-text in the page
> > cache. To illustrate this problem more simply:
> > 
> > truncate -s 500M /tmp/img
> > echo password | cryptsetup luksFormat /tmp/img --force-password
> > echo password | cryptsetup open /tmp/img test
> > mkfs.xfs /dev/mapper/test
> > mount /dev/mapper/test /mnt
> > echo "secrets" > /mnt/data
> > cryptsetup luksSuspend test
> > cat /mnt/data
> 
> Not really anything to do with the drop caches problem, but luks can
> use the kernel keyring API for this.  That should ensure the key itself
> can be shredded on suspend without replication anywhere in memory.  Of
> course the real problem is likely that the key has or is derived from a
> password and that password is in the user space gnome-keyring, which
> will be much harder to purge ... although if the keyring were using
> secret memory it would be way easier ...

I think you've misunderstood the problem.  Let's try it again.

add-password-to-kernel-keyring
create-encrypted-volume-using-password
write-detailed-confession-to-encrypted-volume
suspend-volume
delete-password-from-kernel-keyring
cat-volume reveals the detailed confession

ie the page cache contains the decrypted data, even though what's on
disc is encrypted.  Nothing to do with key management.

Yes, there are various things we can do that will prevent the page
cache from being dropped, but I strongly suggest _not_ registering your
detailed confession with an RDMA card.  A 99% solution is better than
a 0% solution.

The tricky part, I think, is that the page cache is not indexed physically
but virtually.  We need each inode on the suspended volume to drop
its cache.  Dropping the cache of just the bdev is going to hide the
direectory structure, inode tables, etc, but the real privacy gains are
to be had from dropping file contents.

  reply	other threads:[~2024-01-16 15:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-16 10:50 [LSF/MM/BPF TOPIC] Dropping page cache of individual fs Christian Brauner
2024-01-16 11:45 ` Jan Kara
2024-01-17 12:53   ` Christian Brauner
2024-01-17 14:35     ` Jan Kara
2024-01-17 14:52       ` Matthew Wilcox
2024-01-17 20:51         ` Phillip Susi
2024-01-17 20:58           ` Matthew Wilcox
2024-01-18 14:26         ` Christian Brauner
2024-01-30  0:13         ` Adrian Vovk
2024-02-15 13:57           ` Jan Kara
2024-02-15 19:46             ` Adrian Vovk
2024-02-15 23:17               ` Dave Chinner
2024-02-16  1:14                 ` Adrian Vovk
2024-02-16 20:38                   ` init_on_alloc digression: " John Hubbard
2024-02-16 21:11                     ` Adrian Vovk
2024-02-16 21:19                       ` John Hubbard
2024-01-16 15:25 ` James Bottomley
2024-01-16 15:40   ` Matthew Wilcox [this message]
2024-01-16 15:54     ` James Bottomley
2024-01-16 20:56 ` Dave Chinner
2024-01-17  6:17   ` Theodore Ts'o
2024-01-30  1:14     ` Adrian Vovk
2024-01-17 13:19   ` Christian Brauner
2024-01-17 22:26     ` Dave Chinner
2024-01-18 14:09       ` Christian Brauner
2024-02-05 17:39     ` Russell Haley
2024-02-17  4:04 ` Kent Overstreet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZaajUn0Idp90hLir@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=brauner@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).