linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Vovk <adrianvovk@gmail.com>
To: Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>
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,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs
Date: Mon, 29 Jan 2024 19:13:17 -0500	[thread overview]
Message-ID: <3107a023-3173-4b3d-9623-71812b1e7eb6@gmail.com> (raw)
In-Reply-To: <ZafpsO3XakIekWXx@casper.infradead.org>

Hello! I'm the "GNOME people" who Christian is referring to

On 1/17/24 09:52, Matthew Wilcox wrote:
> I feel like we're in an XY trap [1].  What Christian actually wants is
> to not be able to access the contents of a file while the device it's
> on is suspended, and we've gone from there to "must drop the page cache".

What we really want is for the plaintext contents of the files to be 
gone from memory while the dm-crypt device backing them is suspended.

Ultimately my goal is to limit the chance that an attacker with access 
to a user's suspended laptop will be able to access the user's encrypted 
data. I need to achieve this without forcing the user to completely log 
out/power off/etc their system; it must be invisible to the user. The 
key word here is limit; if we can remove _most_ files from memory _most_ 
of the time Ithink luksSuspend would be a lot more useful against cold 
boot than it is today.

I understand that perfectly wiping all the files out of memory without 
completely unmounting the filesystem isn't feasible, and that's probably 
OK for our use-case. As long as most files can be removed from memory 
most of the time, anyway...

> We have numerous ways to intercept file reads and make them either
> block or fail.  The obvious one to me is security_file_permission()
> called from rw_verify_area().  Can we do everything we need with an LSM?
>
> [1] https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem

As Christian mentioned: the LSM may be a good addition, but it would 
have to be in addition to wiping the data out of the page cache, not 
instead of. An LSM will not help against a cold boot attack

Adrian



  parent reply	other threads:[~2024-01-30  0:13 UTC|newest]

Thread overview: 26+ 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 [this message]
2024-02-15 13:57           ` Jan Kara
2024-02-15 19:46             ` Adrian Vovk
2024-02-15 23:17               ` Dave Chinner
     [not found]                 ` <10c3b162-265b-442b-80e9-8563c0168a8b@gmail.com>
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
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=3107a023-3173-4b3d-9623-71812b1e7eb6@gmail.com \
    --to=adrianvovk@gmail.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 \
    --cc=willy@infradead.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).