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 46873C47077 for ; Tue, 16 Jan 2024 15:25:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 851276B0082; Tue, 16 Jan 2024 10:25:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 801676B0085; Tue, 16 Jan 2024 10:25:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C9646B0087; Tue, 16 Jan 2024 10:25:30 -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 594C46B0082 for ; Tue, 16 Jan 2024 10:25:30 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 21353140A85 for ; Tue, 16 Jan 2024 15:25:30 +0000 (UTC) X-FDA: 81685548420.24.1A125A3 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by imf26.hostedemail.com (Postfix) with ESMTP id 726B7140026 for ; Tue, 16 Jan 2024 15:25:26 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=tXYH13F7; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=tXYH13F7; dmarc=pass (policy=none) header.from=hansenpartnership.com; spf=pass (imf26.hostedemail.com: domain of James.Bottomley@HansenPartnership.com designates 96.44.175.130 as permitted sender) smtp.mailfrom=James.Bottomley@HansenPartnership.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705418728; 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=sYVqOikxTSyd0trh4l0r/Udl4Sk9G1Tu1OgkxI5vyag=; b=nLQdpUzOR0bmoidZVPcZG74yPQa6VcpoGghV4C7iBdjPuHOVxpFg6S/rVDYSohcxlgXwMe EelvOHbhlB4GvS0GGUqRLFdE3/b7JVlYdFzOnZztnImn8D2B7laxFtF0bzdcy8q/ZYMX0u 09ovI/JqZDld/Cu+Vl5FzhHIjRCzsyg= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=tXYH13F7; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=tXYH13F7; dmarc=pass (policy=none) header.from=hansenpartnership.com; spf=pass (imf26.hostedemail.com: domain of James.Bottomley@HansenPartnership.com designates 96.44.175.130 as permitted sender) smtp.mailfrom=James.Bottomley@HansenPartnership.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705418728; a=rsa-sha256; cv=none; b=sQlXb7Lj/9axRsmtpiikDAl1krwjLR9TqzM7UurBi5p33VoaR3ftsefwvrSRDI51ulFeOi HYqcwGNBonQkKJJvhkgzJpuj8PB6sVLH2fURcrShR6tzWU6OpFmQyk8rwNezb2xLivOhuA CdCJaJXP1D2OY7YBTT+0rEyBjksPjHw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1705418723; bh=MvWh+67ftiWh2+3eSFJmv3mJL/+4kfnHoljEwqdxTPw=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=tXYH13F7f9/A2kjZUfgcLq4Xw+gQVdGFIUdRYIZ5VtDKmcoc9XR1Ce2tI4o0xdzwC R5NGKecPG+8lXOghqb7ohkUIEQt4OiNrdy+9uAtfyoM2AzA/TErDC76D04PYrjW/4C LlxOo0M6PMBGIaAXCITzQvQyqcnsMjFwb4PCPIEU= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 61F911280773; Tue, 16 Jan 2024 10:25:23 -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 c3eCd6WnbF3W; Tue, 16 Jan 2024 10:25:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1705418723; bh=MvWh+67ftiWh2+3eSFJmv3mJL/+4kfnHoljEwqdxTPw=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=tXYH13F7f9/A2kjZUfgcLq4Xw+gQVdGFIUdRYIZ5VtDKmcoc9XR1Ce2tI4o0xdzwC R5NGKecPG+8lXOghqb7ohkUIEQt4OiNrdy+9uAtfyoM2AzA/TErDC76D04PYrjW/4C LlxOo0M6PMBGIaAXCITzQvQyqcnsMjFwb4PCPIEU= 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 5E5FD1280473; Tue, 16 Jan 2024 10:25:22 -0500 (EST) Message-ID: <458822c2889a4fce54a07ce80d001e998ca56b48.camel@HansenPartnership.com> Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs From: James Bottomley To: Christian Brauner , lsf-pc@lists.linux-foundation.org Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-btrfs@vger.kernel.org, linux-block@vger.kernel.org, Matthew Wilcox , Jan Kara , Christoph Hellwig Date: Tue, 16 Jan 2024 10:25:20 -0500 In-Reply-To: <20240116-tagelang-zugnummer-349edd1b5792@brauner> References: <20240116-tagelang-zugnummer-349edd1b5792@brauner> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: y7y83mtb3dqwqmytbijr5h36qg5rzjkc X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 726B7140026 X-HE-Tag: 1705418726-445007 X-HE-Meta: U2FsdGVkX1+MBdeq5PEoIpW7yx8e8itJr6Wmvcdph/1XGbIRDRHiAnz6gXvbz4Rfxw5EUBoIuR/0gJoz5uR+HbdlXA7zsM3hwrsl8tLT9f9hGxorv4iMT0Ec9CEy1IVNCcf/nWGY1pGUinCK2WbRRqPz4ZbdbrQws6b0MUE83CqkzLQpaySqwCEkpcg506mLDZkM3lG2bZIq5XtZNUtxrNCOZZKUkusKb8B/Vj6GQIikB17bzRvH3TLmM6DD8dZqoACB1RCqxKkIm1rboP8nWwYAHa55fiTZIOu4GnEIDOTxXlQgw6KEMIWtkecdpnbOLGzRBviQQMPULkKpzhomz5qEMM5GJl6/M9vVfTgIdWoezPdaVv21AFCUTqrzFUN9gGB8Qkok2uLXymDItJGOCK9xan/kd2wCg+CXnk0C7RxjVrWX05zjAdVFHxNPkqrM+lrKzGrkwYJUVXXHWNpw+LP+cBGKEIykUjhjKWEoBVLr7vf2mRCUvTNhmxbNsvzPdS/B4W02l/g1qBJs9FszTsrJCDu/NuUtqk2FcmxlOagsWURJDj5ktELRGc5Wndkc+2rJoVoeFxupEzipt6wfrEqaZ1Lpc4rCGBUu4TRSW7A4JCskqsMY9yCdyEN0xsCXIkbpL9zk7K+PE18nsTtGjmCTdF5le6J0oR1KOvSw8y8G7jSDqbFZjlQVtjjKcUyFderAEMNTMLM6vPHGCBs8tg4+khvJTY6lu5/3YXuUtUccaXnW9nxu0OPk03YKenC7H99zuYQo2hl3OWqYzuIchBemGQcRnBm29/U+iCfn1YBZAkFSgZqqnAAeJ0w+UB4O1oIIkeSvsFqkwzVeZ57YukIbqhFr+S/Ldb8PRy1+mJXT2XBy4J3GKLy/INhcB+f+FZWG+hgBzo9GHocFunBbPgAc0DRPMafIVHPWIPh16s6+eYdznjoVkTqkrz+RxKzzpD1ITUD7wBfJGz8sdFi te68Owpx Oa7X8m6W0gPm/kQt51qv9mV1v8ziWvchL+17ULWX0+sReSXKTUrKslacU9Y8aVkCO/tIShkN+D2U0im4NwkDON3FdD/cpkQyiUpQfvTy0IQYYyPwj0kqt9w1fvBCN6fust5bhNqfRCz9zxNmEoxVFXpDLhP4GxTehzKo0CRMQPyxxKcBn7cKkUQ8BMZy2XUOC5WV7m7m80VZ6+nlYXA9WtUZAJ56B/24C2SWM/t85qFMYo8VbmFzZnyd5VdD36kxkI5tApqKoIlpmdpjW/ExZDrCFP1TH0Uwuhkk0lHUUYA6A+EGMtyKP5hqu9RJBoK1rymwY 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 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 ... So perhaps before we start bending the kernel out of shape in the name of security, we should also ensure that the various user space components are secured first. The most important thing to get right first is key management (lose the key and someone who can steal the encrypted data can access it). Then you can worry about data leaks due to the cache, which are somewhat harder to exploit easily (to exploit this you have to get into the cache in the first place, which is harder). > This will still happily print the contents of /mnt/data even though > the block device and the owning filesystem are frozen because the > data is still in the page cache. > > To my knowledge, the only current way to get the contents of > /mnt/data or the encryption key out of the page cache is via > /proc/sys/vm/drop_caches which is a big hammer. To be honest, why is this too big a hammer? Secret data could be sprayed all over the cache, so killing all of it (assuming we can as Jan points out) would be a security benefit. I'm sure people would be willing to pay the additional start up time of an entirely empty cache on resume in exchange for the nicely evaluateable security guarantee it gives. In other words, dropping caches by device is harder to analyse from security terms (because now you have to figure out where secret data is and which caches you need to drop) and it's not clear it really has much advantage in terms of faster resume for the complexity it would introduce. James