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 67B4EC47077 for ; Tue, 16 Jan 2024 20:56:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F37036B009E; Tue, 16 Jan 2024 15:56:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EE71D6B009F; Tue, 16 Jan 2024 15:56:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAE6E6B00A0; Tue, 16 Jan 2024 15:56:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id CC3FF6B009E for ; Tue, 16 Jan 2024 15:56:08 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A0D93140268 for ; Tue, 16 Jan 2024 20:56:08 +0000 (UTC) X-FDA: 81686381616.08.260AFD4 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf24.hostedemail.com (Postfix) with ESMTP id D186F180011 for ; Tue, 16 Jan 2024 20:56:05 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=Jx7qPtsm; spf=pass (imf24.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705438566; 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=R4ODcMiKnN9uc2CQEPWploNVotAW/sU5YV82cEbm6cw=; b=7kNClOTx4npL32iDzZgRaQCvdqMBbzvg/1g4KS/AtTu6xaFXrkCPzw5Ge2Bc/eojy0S6YK qzskB1syrp3Ut7NDdD0iLHB8GZkTPwkdpicy59vhsLYwwmB3kzJsmD60YDQBMOiX0DSqh1 JwbPFFMhCX59alHvy7NOpPK27dO41KY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705438566; a=rsa-sha256; cv=none; b=0LQlpWYes7WNnqajXbknWF7g8xVVYZl9PNZ4lIcGFrqEy7hvj3ACDvH0q9eAxTtPQQ09pR VldxJdHF9jl1wrxNDgCpesuF4btmbvKTXX/SX2aqjjSccGXjbwI4SPFyHVRaKWiP5vlcvO 8fwHmc7vifWweGGfN7oWTYXQYa48gJo= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=Jx7qPtsm; spf=pass (imf24.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1d5f4c9c2a6so5159565ad.3 for ; Tue, 16 Jan 2024 12:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1705438564; x=1706043364; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=R4ODcMiKnN9uc2CQEPWploNVotAW/sU5YV82cEbm6cw=; b=Jx7qPtsmeKvVQCHC1itcvMDXYyPUx3MpuSx7OXcEY6TitlE/hlH7chHM5aDG9X6TLr S4TFtSvZghhi8GIulbjKKJuxUK2NM1971vADneoaecjU1IYV9fPik+NdaTGjKDYyFjg5 yyii55ShN1Y5jANWs8VSfVcaeqey+Gsz2d9GQ2Cv3WdXlg9ufuvGdyRme0HPNhMSg0xf 88TVGSJHFHm6IcseqBWs4tXG2/Qn6L25VKJH5qsVTPg8lWRGHdX+p/TXXAKpiQc1bylG rAy0MbMUHrtWvBtel3mAlv1oGqb5gzehxE4swIlWrymCC5dykUHnoPqYFh0a2ZUs1ZWM UICA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705438564; x=1706043364; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=R4ODcMiKnN9uc2CQEPWploNVotAW/sU5YV82cEbm6cw=; b=pwye4FmVM1fcMHlchgk7mwsPvTc1pQHWOMaM4equzuWcb3QHobtAfPJZB4y4j7tgHL 83PZrsPyAd6XZeLwAeh+IMy5pAMLWYyoiVQA4iyOkIyLd+hu+ds7EDswld2WkFNEG01l jFqyEzxxYqVkkADOmCl8C4/IaRU+puJy8NskVZQIql4OVduilvM1+CUdakUJmTmE015J ogK7Yhi80KhZNuqEA1DICvkX3XCwZvHQCq0rKxvTEvEgXlv4chqg1AnOOfSefKv2SdJ3 hloAujelZRkm7zgm9PqwgY2d9p/14MZLnv5vHKkaPi22pYmkuJr8N3Bj3emO0zCnOTUR 4IPQ== X-Gm-Message-State: AOJu0YylMnM8KAz8xp0//BIpkgmXL7uOwqafUA2E6OgoX/jupRqDJkIO 4a7WhphqaYQ/1ShIUikeGoTrj8FGY/zlVQ== X-Google-Smtp-Source: AGHT+IFwoCp6EyOkXVbSZ/bZy3zGhRgZXj/tnkE3Ntm0JfGhaZXJ5mMWTPmLTDkXojp/i0RmI+gT9w== X-Received: by 2002:a17:903:1c4:b0:1d4:ca3d:742e with SMTP id e4-20020a17090301c400b001d4ca3d742emr10699298plh.67.1705438564540; Tue, 16 Jan 2024 12:56:04 -0800 (PST) Received: from dread.disaster.area (pa49-180-249-6.pa.nsw.optusnet.com.au. [49.180.249.6]) by smtp.gmail.com with ESMTPSA id y15-20020a17090264cf00b001d5e734868esm1716838pli.241.2024.01.16.12.56.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jan 2024 12:56:03 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rPqTZ-00BIHT-0N; Wed, 17 Jan 2024 07:56:01 +1100 Date: Wed, 17 Jan 2024 07:56:01 +1100 From: Dave Chinner To: Christian Brauner Cc: 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, Matthew Wilcox , Jan Kara , Christoph Hellwig Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs Message-ID: References: <20240116-tagelang-zugnummer-349edd1b5792@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240116-tagelang-zugnummer-349edd1b5792@brauner> X-Stat-Signature: cj63rbcm6ge1pndpnaotuaokft9ydr1h X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D186F180011 X-Rspam-User: X-HE-Tag: 1705438565-899990 X-HE-Meta: U2FsdGVkX19JmHiAp35uqlMFHRsWVrDaLb6RWWg879gFqXlina8UfCxyKAgMCGO/RKGrCNkerdWf1/Yfe2c2q2w7E1ZZO+lTIOGLQrmj34kCScptqpmNMyYgP3EhHKmhOHZxN/m8q2XC2OvFRgWpu3Xgals8ti92BYdLD7bxBfQ9v0z0AN0aPZi2aKuI2Oor9jVJd6yHpqlIdSd5gGSQHYX3WoqEL+DSI2oQL1TbGDlUWbn5xFnq0ByRcPAA3UL3RLSnUjO52XQedVN4+3oMU+daARR+E/Tw4Rw9cpDpnxjO82/zOiGPoX3ARtI2IqPE2O2kx3vTz0KiL6B8vdlV/JOIWcQbNQFhkcgth10F9eHRIuEfxdvZ+Dx4p25r+WzdQJSh3NVOMwjnQn7JLoKPSNlvgseaszoI3RpZDaT2rmFLa677m+DUSTOr7WPfDBdeT00WKRvsEAwV3pLz81D9ulS97qGM0O02CudQsTZ5uRZzfTU0Z+0acvEFMLcu9RqsSpofqWmIfT+y0NChiDS635uWOOi5upLzQkk6HXitIFTnUIg29/NkQlC4quisNoIpVDYu5Lgt4m3S6gyO/QbTPnvM9BaeRTNxI14FzIA8+gzosdx27qYgtbvhMkx+ylFJ4FA/YpDNlnvikv3dJ6jPEon3u/H5cAVJ1vV+Z9mAhriWasXIgeIO3PMhISeONMqXgWTy8+r7lr9TFwux8k5mr2H0JxJiBO0Aa64G2ue/lec4PR99Ttgp5AHRx5JNpfxrjGUR77cZM+mk7/M9bgW4dmGQ6FB8ih+M6sdnOsuQQEAK7iN0yQw2KAvH6yCxFsvmXU8EFfjQoDIdU4Sp7UcbPg7Fyt1pdPmASsmR8KmHffpuJ1+WxsTcXEWxuPguczKjCNTkddbg9M8xcBHzTU9450Qi85FbzJXxeani4xQm2OUcjmV57yFaeJ00LUFd8y0ZXSxouw5ZnNJU00xvPv2 Zo6wV9jc 6OlDKbzmgzd4T1dv2sp4UEohU789R0cfTi2dvHNLa2rPYfS6M702P9cA2DyC8LFcSQEMMaz/ODr3kgr1sqdITGd9uCTTZlBdVl1bZnFFTiaKmOjYD3zAb5gm98A== 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 11:50:32AM +0100, Christian Brauner wrote: > Hey, > > I'm not sure this even needs a full LSFMM discussion but since I > currently don't have time to work on the patch I may as well submit it. > > Gnome recently got awared 1M Euro by the Sovereign Tech Fund (STF). The > STF was created by the German government to fund public infrastructure: > > "The Sovereign Tech Fund supports the development, improvement and > maintenance of open digital infrastructure. Our goal is to sustainably > strengthen the open source ecosystem. We focus on security, resilience, > technological diversity, and the people behind the code." (cf. [1]) > > Gnome has proposed various specific projects including integrating > systemd-homed with Gnome. Systemd-homed provides various features and if > you're interested in details then you might find it useful to read [2]. > It makes use of various new VFS and fs specific developments over the > last years. > > One feature is encrypting the home directory via LUKS. An approriate > image or device must contain a GPT partition table. Currently there's > only one partition which is a LUKS2 volume. Inside that LUKS2 volume is > a Linux filesystem. Currently supported are btrfs (see [4] though), > ext4, and xfs. > > The following issue isn't specific to systemd-homed. Gnome wants to be > able to support locking encrypted home directories. For example, when > the laptop is suspended. To do this the luksSuspend command can be used. > > The luksSuspend call is nothing else than a device mapper ioctl to > suspend the block device and it's owning superblock/filesystem. Which in > turn is nothing but a freeze initiated from the block layer: > > dm_suspend() > -> __dm_suspend() > -> lock_fs() > -> bdev_freeze() > > 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. The wiping of secrets is completely orthogonal to the freezing of the device and filesystem - the freeze does not need to occur to allow the encryption keys and decrypted data to be purged. They should not be conflated; purging needs to be a completely separate operation that can be run regardless of device/fs freeze status. FWIW, focussing on purging the page cache omits the fact that having access to the directory structure is a problem - one can still retrieve other user information that is stored in metadata (e.g. xattrs) that isn't part of the page cache. Even the directory structure that is cached in dentries could reveal secrets someone wants to keep hidden (e.g code names for operations/products). So if we want luksSuspend to actually protect user information when it runs, then it effectively needs to bring the filesystem right back to it's "just mounted" state where the only thing in memory is the root directory dentry and inode and nothing else. And, of course, this is largely impossible to do because anything with an open file on the filesystem will prevent this robust cache purge from occurring.... Which brings us back to "best effort" only, and at this point we already have drop-caches.... Mind you, I do wonder if drop caches is fast enough for this sort of use case. It is single threaded, and if the filesystem/system has millions of cached inodes it can take minutes to run. Unmount has the same problem - purging large dentry/inode caches takes a *lot* of CPU time and these operations are single threaded. So it may not be practical in the luks context to purge caches e.g. suspending a laptop shouldn't take minutes. However laptops are getting to the hundreds of GB of RAM these days and so they can cache millions of inodes, so cache purge runtime is definitely a consideration here. -Dave. -- Dave Chinner david@fromorbit.com