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 CF37FC47DA2 for ; Tue, 16 Jan 2024 15:54:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 44E8B6B007B; Tue, 16 Jan 2024 10:54:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FC486B007D; Tue, 16 Jan 2024 10:54:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C43B6B0081; Tue, 16 Jan 2024 10:54:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 17DE36B007B for ; Tue, 16 Jan 2024 10:54:57 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E1D3E14085C for ; Tue, 16 Jan 2024 15:54:56 +0000 (UTC) X-FDA: 81685622592.16.4525CE4 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by imf29.hostedemail.com (Postfix) with ESMTP id E104C120020 for ; Tue, 16 Jan 2024 15:54:53 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b="r4PQ/eOP"; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b="r4PQ/eOP"; spf=pass (imf29.hostedemail.com: domain of James.Bottomley@HansenPartnership.com designates 96.44.175.130 as permitted sender) smtp.mailfrom=James.Bottomley@HansenPartnership.com; dmarc=pass (policy=none) header.from=hansenpartnership.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705420494; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FLNv+dIJOZaRtqhA5DsbQtMmo+05U+Lr3LocyTTiDdw=; b=CSfBxpyfmrGiNJ0lB5xN5Sg9MbL3SYd+ZJCKGEXm00XBbXd6lWL1YUrjqiwyQ59fYk4TAp mUFve1N282R5UzHTgWztrY4c9b2cjlcQy0hOeGTiU7ZaEoC4jxDcgqwD9x4vlTHCpjGDz3 fmtsy8sIqkzv2gtRVAtngkCbBluim3Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705420494; a=rsa-sha256; cv=none; b=qQPWqrZtLL2ztdvPdbPXMGKEhwoZ/Dtt5z3AkNT30DWs633Z4VDEL94fbiNexAioG/SId7 Z7C6Gj/W4yDCbloQjboHCXDEmZmalXQFzysiKW1d7teSeKTfpLv13eHHbw1ozi/oOjHWrh sj93G9dalGWoUxM/LdvvVW8PpiCfkMU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b="r4PQ/eOP"; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b="r4PQ/eOP"; spf=pass (imf29.hostedemail.com: domain of James.Bottomley@HansenPartnership.com designates 96.44.175.130 as permitted sender) smtp.mailfrom=James.Bottomley@HansenPartnership.com; dmarc=pass (policy=none) header.from=hansenpartnership.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1705420491; bh=pjY2k+YByejaq83dLC4A1kRHxj3IpcdeBea5o5eMGtc=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=r4PQ/eOPY10cMMN0Ex+dLgBhMtXUhoGRNDRlToKsA1pvZRbbNBT7JE0/0OR5YRjZK IErSnnYepaPT2S5umKKMfWW5hCsGj5GjZOEpNSCPtI8XXvx9dDsBcFrXLRBFhMhbrI cDEWC0o7VASAF32fW76AiHo1dmaN7bIdKSLoOlBg= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id BD42112801D1; Tue, 16 Jan 2024 10:54:51 -0500 (EST) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id xjhfFOwDRbQ8; Tue, 16 Jan 2024 10:54:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1705420491; bh=pjY2k+YByejaq83dLC4A1kRHxj3IpcdeBea5o5eMGtc=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=r4PQ/eOPY10cMMN0Ex+dLgBhMtXUhoGRNDRlToKsA1pvZRbbNBT7JE0/0OR5YRjZK IErSnnYepaPT2S5umKKMfWW5hCsGj5GjZOEpNSCPtI8XXvx9dDsBcFrXLRBFhMhbrI cDEWC0o7VASAF32fW76AiHo1dmaN7bIdKSLoOlBg= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::c14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id AF76D12801C7; Tue, 16 Jan 2024 10:54:50 -0500 (EST) Message-ID: <9283ad6dd8e911fa9861b0f31a47aa82474d9fd2.camel@HansenPartnership.com> Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs From: James Bottomley To: Matthew Wilcox 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 Date: Tue, 16 Jan 2024 10:54:48 -0500 In-Reply-To: References: <20240116-tagelang-zugnummer-349edd1b5792@brauner> <458822c2889a4fce54a07ce80d001e998ca56b48.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: E104C120020 X-Rspam-User: X-Stat-Signature: zq1e4karngusft9b6wuaeihnnhin4dtc X-Rspamd-Server: rspam03 X-HE-Tag: 1705420493-541187 X-HE-Meta: U2FsdGVkX1+OCdycTyo6+0/dgTDjnGNJogxTtPCBmfLdeH5kvonqUY5BHGWTy3/5Wm0gDnAOOwxzDbUDq2Mv2bZ27KyRoMtS6MtNMwAaNjCdJ+VHPUUQ1aO3AbAuz6lJF4s92tALklOji75aVPRfDdAUQQJQ1HRmF1/qKw1ECEACxYhXDkrNhaGkcAKcUbNHr+pmaakrhZhBuGu+crWEcCRzUtB3Ia1LJfuyUkeBi7Py3SjqgdJp3iKJggdjmKveZph2tqUAtFQCWcDjCM3GuY0uC0tcQkfpg4MtWV846TvEEu+T0EIaEXhtKNsvOGfvN6QklFhj1XsX7PGcKxjbJwB1lMbgvlWEa8954B9tt4SeYq4zU9mVRaWF/Acs/kvhSa8LRGhCQwIv19cLZ9d82S4uDtGleYGei1V3r0090rMHpA74Uzxc+nDANAKLhJWTC2ZHrMd/sKMMgy03LhLdKrDPtrBdVlnozH1dnEKS89fYV3QHmw89fUNlFAbfYuYtUCN70qVXPZxyh8Vthdtd7wHVNdYZIyBnta+AbeNdPnAwY3SCbTg8a1tzQZAfafcKeF/z6AlYlO9r4qBi0pR/740x0koifUaMzO3gT6zCTgHNYgqH1IdKeB4G0/E2IwJvzCe83w7jIzyHj5FsgTvFC4y06xlXrhNhdkTqQ2WzD4qgMBAZCjr0wWYV9ExXh2afuwlL92T6pq9QvWsWC/9iPZ/0DyMCgaD9gcoCTbPABIQ0UH9aQr2RNUFx2eMO/FR1jinVOUMUO6a9+RAWwO6YTmEPisiGTVvsX1JhN5EFd7N9L/p1+HpSl/pJyabR5LTV9KVjmPRIlCKX30zgRzG0omYFofMRe8cwDm2pPh6VAsdL71ndTcba4nhPAlrxLlothzRv/aSIeekbFYRDHeE5I3MvOIfgXNUX39wo500U/Krk4Wn1492otsvFSjXRnMTqap1i7VJe+2IcmH5ePKZ E3iQJ8un wdN3Lp/rwSdYIhyWB2I8rgDHHpcs6THL8ZAbpRS2OLlvS2T+YsBsg7s0GleKac6fNB/ejUu8w4eDMMckeP0XhMnh+jj4maHxXHOZWSRPv1mKmz5khDhhu7wW0cLTmflEGuuNX5j47zWDmBj4Ins8XyxpLxQAclyNhUAyfVgOFOuR8nUh0W3nJY9VOe7TC5iI71H6Q0vkqWQtr8ruLwxxGDzOUOLIKv64VTPaE5XKnsWhbUgTj68D83kuSl0fXNI6mUkeCamcV4l/1IXv2LMkc1s2ayiVgCvuLz1Mu/m6vaPr6FasJtBnSo9TarM9X7MlrseFV 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, 2024-01-16 at 15:40 +0000, Matthew Wilcox wrote: > 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. No I didn't; you cut the bit where I referred to that in the second half of my email you don't quote. But my point is that caching key material is by far the biggest security problem because if that happens and it can be recovered, every secret on the disk is toast. Caching clear pages from the disk is a problem, but it's way less severe than caching key material, so making sure the former is solved should be priority number one (because in security you start with the biggest exposure first). I then went on to say that for the second problem, I think making drop all caches actually do that has the best security properties rather than segmented cache dropping. James