From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B72E4C47077 for ; Tue, 16 Jan 2024 15:40:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DBB86B008C; Tue, 16 Jan 2024 10:40:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 48C9E6B0092; Tue, 16 Jan 2024 10:40:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37C4C6B0093; Tue, 16 Jan 2024 10:40:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 283196B008C for ; Tue, 16 Jan 2024 10:40:18 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EC6E0A17B1 for ; Tue, 16 Jan 2024 15:40:17 +0000 (UTC) X-FDA: 81685585674.08.12D6D81 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id ECE66180026 for ; Tue, 16 Jan 2024 15:40:15 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=nRnVOlNl; dmarc=none; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705419616; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UOSFk0nvbcxntL/e+i9swjB3N8ugf671tA7ZAfcaVpQ=; b=b0X/OtysYpmClKwbtknR0COeFAtWx5p96nNfAq6SMStZ9Gf5rRyZfIsY6+qTFh5RXNymZe vYXtEI9W/08luG4KA3vi9hhoaHTD8Ing2zZAOMpYsRb6d06k8SUIYfQZcEXCEcMvYAy8oK ZiQVAuRAHEkMJa7Y4xrYO9d0dxZgaBU= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=nRnVOlNl; dmarc=none; spf=none (imf06.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705419616; a=rsa-sha256; cv=none; b=y14UmPU5cKMncn23iTN0phfey/ZS3Zr/jlFfadIjPh1nC3LtSDuGhPe3Q69y4GTAhLYo+0 sVpeijqEvRWUBfzehjbc2Rlmd/kc3e01leZadsstxkP0No8FTqsmFDejhNtgsdC000Ay28 YdLr6m8qA0BbQA9MpgqlnT/+gyCOn90= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=UOSFk0nvbcxntL/e+i9swjB3N8ugf671tA7ZAfcaVpQ=; b=nRnVOlNlqU0wzY0eiRwHd6EoDE G0DXHIiF0yPgG2E26wxU70erTT984qSaoilmnEIpKpaywZ/oSnRDXhBiNLh+q6a4qMJbWobmUN569 2AnaQp3vv5CMTAeTwmAQ3Y8GyBQBctlWiGzEkfQ+FanpCZP1CpoTkNzHLgJqa9oZTRLyrkxYWXQB+ Zb+az/e6WwVObx/QgZht1ZY27IukrD12ia5yaWSxdBBsebYjqlGlB2dP3vsGQ/k72yHhUlRDyFOvr eRAG+eeu5RFzJU6Dv04nn4So8z1h/laLyeAZByuILfKNv2voWmvzV++x+ca0sTBa4TYEeszmrcfI1 jSJFOvAg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rPlXm-00DQxa-TK; Tue, 16 Jan 2024 15:40:02 +0000 Date: Tue, 16 Jan 2024 15:40:02 +0000 From: Matthew Wilcox To: James Bottomley Cc: Christian Brauner , 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 , Christoph Hellwig Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs Message-ID: References: <20240116-tagelang-zugnummer-349edd1b5792@brauner> <458822c2889a4fce54a07ce80d001e998ca56b48.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <458822c2889a4fce54a07ce80d001e998ca56b48.camel@HansenPartnership.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: ECE66180026 X-Stat-Signature: kh5fcxoxwd3ezh68du34ohb7y6anp9ut X-Rspam-User: X-HE-Tag: 1705419615-828992 X-HE-Meta: U2FsdGVkX19j2kPW3zapyQhZpSppQJRPqo4m3pO6hbIL9ST1sOXIgTf6Yl6iR8RJHgfDXI7U3CNx2RK9x+e8p9s6AZ/8stEWHBEZ+G671CiiaFw6Co2Dx8ri+5KZFlMEWo1bp1ufkl7n1kZfUiinBDFLyPKEzsV8VmqpdX8vfgqnYPdvH4gFEJTfQlM7k/CZ0ldcsJR9+4jDbFxd9T4B1FJ6TcjYdd72Ic5b28Pz5nmSheNWNh9VXU/dBHUh+P5pN5RnYaNn8rjgthzg2ilfVAsfvwTbqFE4oar8Y5xMMjt5kQ8HypIusAqTX5DQ0qiDWqFkYfXcgXgp9lxEfS0wYXrzAAvBl1gtzKrAVlqooOHfH0xBFn7eXQiOR5HJT4f/fifvZsqfwzc8RhbOUg/ND083I5P3VmaOZA5yPBhiu577uXeh6i6Srp9nSYjan3gs3plq/nJ5KLkz0+rTNOw2UIg3xIfbiyxvcWwUKGoE1NnfbT1ldT82iOhFuwCR9B6fpagN60hjCgJa/XAN+ZtuisN3KU3fI5zzRBnp9TTIHd14D388ZCutWNblGsNCN/f6+YDC93cLrZXmnM/DyOq6kXs2WlDSXFXejUyAFfBP9rsEdb9zwNWndWSp9CFx4UFnLnC1P89LC/9eiBtsVYuhzGRm7Cnc1/mc+8u61mkqKtlYF266ta9ZUfWW8xTIT99x/p3a4DJNf+Izku+M0vbdVZUYQ41UXINtgPzdcrSLXPLT7dOJgukGv3lqRFW/SWNUIrqkLAELZF5RLEiGjAJ1nSJI0JfzcN5otvxkbEbiwy7hARUQJLSo7YVJhCZt26cv/bsveQvxCDaVbddxHYXJwI/yv5TlW/YB1cTKmSrqVPF5o+SbO1wKJnMxulZnaozlACo5yFiurrIfvWNbwgR2oWHPS1+twIt2wy5QE2S3Eryv8wNHAM9QdYwD+/VM11gNscNsJcQA2Glm0bcZ3/w TvyZ057d aNo06kBMh692zh8UV4wuYkJ4JF99Lsw4x34hoft1/ZbOZKIGGIQT5V73JWPi6ul5zWuhXaMIROqgrGS/JPqdMDy9gucsOTXrM9RGYDBb7is+vBPmyeS8GPXAiUWakRKkSqDOnhgQ7lF2dpbE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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.