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 83C6CC48292 for ; Mon, 5 Feb 2024 17:40:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C74156B0081; Mon, 5 Feb 2024 12:39:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C246C6B0083; Mon, 5 Feb 2024 12:39:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC5526B0087; Mon, 5 Feb 2024 12:39:59 -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 966326B0081 for ; Mon, 5 Feb 2024 12:39:59 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 517B1A04F9 for ; Mon, 5 Feb 2024 17:39:59 +0000 (UTC) X-FDA: 81758463318.15.CC051F7 Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) by imf21.hostedemail.com (Postfix) with ESMTP id 6150B1C0015 for ; Mon, 5 Feb 2024 17:39:57 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mAl6dhHb; spf=pass (imf21.hostedemail.com: domain of yumpusamongus@gmail.com designates 209.85.210.52 as permitted sender) smtp.mailfrom=yumpusamongus@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707154797; a=rsa-sha256; cv=none; b=3vIxg+daYbybVagP2gTODEtIe9VMmJXwbYNkEivHxrEHCX6TiXYWiu3xrszkGfQK/Lm7mY yjKuCG2T3xMZGMfApfyzs+3NnellJZ4zHzDknU7RZMxebQaLQOpmGB8ZPCobWCR9jtOU+O yE/T+s0OF5kzLPKaLv++r/WhrMJ+guE= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mAl6dhHb; spf=pass (imf21.hostedemail.com: domain of yumpusamongus@gmail.com designates 209.85.210.52 as permitted sender) smtp.mailfrom=yumpusamongus@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707154797; 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=pIZmrVeKJRsRvZTpUXLQ0YB2Q+u+HKTagSK/hpmNrug=; b=ksptWFfEWyAwqiGK+EWQfSVK9D6sNDOD5KenR+stiKNi4C1vE7WkMCvj1N+Mf1j8Ddg1uy rbA+2G/lzJiw2eCMimWGgCyeFFbQVPHHa0VvQlmvac6A2E5W74r+VmvyiDhrX5bGi0i30z hi14DH+sOBGFttw5nf/kjyAOtsaJRPE= Received: by mail-ot1-f52.google.com with SMTP id 46e09a7af769-6e114e247a2so2365896a34.0 for ; Mon, 05 Feb 2024 09:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707154796; x=1707759596; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=pIZmrVeKJRsRvZTpUXLQ0YB2Q+u+HKTagSK/hpmNrug=; b=mAl6dhHbXbvjL971q9mD7XmzjIo6bJn7USLCiYHoki1hxKrjQUEIva4PwmfyYGvtRz wd1bUH2rlz53L/PXQjAQigQ7LW1njioE49lTjaRdvhHDRRClfFYriU9k58RqJXCIM97Q lHhxfJW3bQchzZqVRdWd5EBgAmKL9GucM+v2g8GltEz7ZSLeCU7vG42gVMBeKt2iBp8W mfocFPSswhPMiNYas8kUDo/VHlUHSu+E+zPtRr6Ho+6Rpuq7bUwj2ZgzPj/ZBFQcjbhF rwRm9YMIKEwYH/ccaxW3mpAG0ikTLKdB5HC6fq6NfaHW/mjiP32B0gQQsl91DKPJPv5y lX3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707154796; x=1707759596; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pIZmrVeKJRsRvZTpUXLQ0YB2Q+u+HKTagSK/hpmNrug=; b=AypqNKLdskze2oznJV/XCQnuZN03XXAZp5U/1V3hflZMZvS22csRnTZbMjrgnboeoi C+DSHegaazQoMjuYA3Aau4vderdJqb2U5PzzDQ0rhk0fmpUpJg8p4AO8s7v6MciqiPpr T/WbDLgjoVrqKmLz3M++VQ7no9qz+yqbNK2mAbi7aNWB3V2LnB7dF/rV8paJFrX5uRPA 1uGQl0K+R9n4AY7oiResvidBPNRGPeyMD2sYOwDX8I+m5mbcZM0FN5DZFzdSOaUG5lu+ /pgfwUGXF7qEnUGB39UkMgGHMPOYUyCw5rA33aOGvEEFRrzt5Aa6B3ZIHun68tdIyMYH LgqA== X-Gm-Message-State: AOJu0Yy1xPCHMgj+KXqi158nEqpu+zkm4TPq7yNYsiMdbnyqFUT+zX+B JCmvSrHCMf+IlbAfHpsrJ00mGuyFpNMMQZf/i0DBm9Ou5BB3K/jV/aw6buJsM3Q= X-Google-Smtp-Source: AGHT+IG+amI0yG7Eodpu/pBiuimcljdmmO7j+CrPTZuS877t4XaW79vk+AzKTBGUT/eusQ66eEH6tg== X-Received: by 2002:a05:6830:ed4:b0:6e1:11b7:9a39 with SMTP id dq20-20020a0568300ed400b006e111b79a39mr342912otb.23.1707154796342; Mon, 05 Feb 2024 09:39:56 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUn7pPZboH59rVCObb4ny5txAGKN68y6BfXZcXgzbXvWml4u0RzEAhiXkQj2xwOGVp9GP/HgofAz0DT1TgRhOlrWjghVuAWayuk2ZWEUjEQ+bCtwV4aNCT3I4bxfT5FlmnItYCJWAj4Fx8Mz1kwx+3xWKqZ8JN8wyI64+40eLF8alOghiRsyHMoYz8LHNhZSqFtlXqKRh9tPIgyxyyfJLOPH4AzWUsuCzZLuYCsAGg7cuMfqpZTj0rUKp1Nv9jBVl2o09posbqGOkTFG0BKYOoEp7tVMDYwnxPQudLg7Qsrrbysjgu9YOaqznQ5KeYXPBGzEBB+ga/+QvUIEt8= Received: from ?IPV6:2600:6c56:7d00:582f::64e? (2600-6c56-7d00-582f-0000-0000-0000-064e.inf6.spectrum.com. [2600:6c56:7d00:582f::64e]) by smtp.googlemail.com with ESMTPSA id b12-20020a056830104c00b006e11d75f20dsm54239otp.9.2024.02.05.09.39.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Feb 2024 09:39:55 -0800 (PST) Message-ID: Date: Mon, 5 Feb 2024 11:39:52 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs Content-Language: en-US To: Christian Brauner , Dave Chinner 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 , adrianvovk@gmail.com References: <20240116-tagelang-zugnummer-349edd1b5792@brauner> <20240117-yuppie-unflexibel-dbbb281cb948@brauner> From: Russell Haley In-Reply-To: <20240117-yuppie-unflexibel-dbbb281cb948@brauner> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 6150B1C0015 X-Stat-Signature: 1uxbsjmf3mpft8dawzxhyfu1a5xoxj53 X-Rspam-User: X-HE-Tag: 1707154797-487363 X-HE-Meta: U2FsdGVkX19ZI3Le1SkRk4x9fAFTAZlJO+apclImdqEPH/THB+FPWUjp3gJZ315y6ISlyRi+34IVudxI/K+XA54tfNOmVHglNHHw9ZjgqVnRNI6zHw1axlfZpjLfoNhVgs6Z/wDT0rFCfWwA7CgdbK6rT6BbEiExza9yGmD/cf2hWYRIeIA7x58dZaHn3SNCk++pM8mxriBHkjWwEq8WXDMASwgeNOr08zqyIcWqpI4R8rNgtoL4/SWt0NppO4exhMVJ1W6YysNEsHnpW71Zd0I+CLXJJ3ThI81nFbIX/ss8QEK7xaL81Tv9KBDU2oMISUuXyfsXkL6JnPFugO/7cEaIhMx0okdBI+CW9gAMDlKKE6Lb/nh3iPEge4UH9ddkBWASSaQFCzkkTYaCSYElId9/hBai1jgK1Kajhjm8HY3qQNAVvDbMHmSRiycooGo+pcnv88gfrfPUD5YEFwo2iS7UezEhmeUy5cBbp+04GVZxSJnij40PxE8ZWk8Wdb7haCqnfgcAwnsC621qAss3MFiClaQBHttLQvN7dATm60pb0taDcm/n2sf7H8KX+KEgw9adPjLv1WF7mt2eMoQWCgY2OYkxfNeT9waJtNWPj7BTj4Y3Aop/TXYb6e2RAdEbUTfVIAw4ZWD1MMbWQTYU8N87PCmgdshK9yWmtmGKoE5TBAsvAw2wH16LvRDUv0lBKttYQFkGXEKhCuzasAOqcFccDlNEvgnV3dbf4IQ2mKOO19pzyyZkEooi6/aHiaLq5KHSHfcZIo6kT3NPNDdhYVU+ttMRRVxiEbfzZwr4EcWQwPr1ZUiVLEqyuSRsgoXlkIch5m3zyIu63UOOcth94ruwFwieiuCvAPuQ9Px9/IA6GwEbtKIEkQHdeJMXK559sLjjkLVdlDTeHh5KEuRVELd/LdbXGG4dR/jaVyCTTr2MIxSsWCj/KsvSzwHPXI7smoxNvZzEWzVJLHHmOrm 3s3CBtqX 7bhkn/y4aJvez1XqhbK5QqvkikeicBxLfD0UDvwjCxbvUy53HJRkMAs23PU+E1FcvB9knkNwU4P/yxAnsxDnjYKXsinua3Q86SslWDC5ebrrHgXZdFp/QR5CKU98yGiV4G2lhRdbmQaIH16ijpjaKGefMbm4K4HAMOtjFb5fzYXvOrYxCp5e/0qekkexe9d4nIAV/LHLcftUS571KB0aV8bw/seINSoBgU3XwRmqhx2wHPc2P0Jt+3LThLmoFelH+xGZKb5tqMWy8Qt+425/dGh5PpWOME/FC5C6NLQCokGe4FIR/kyNKHiRb6L8YbPZ1yqcrmOfP9AvaXB0ArvG8XR4YA0g/VaFpQDBx6HY/hVkhHzsOFeSPTkd7xCjrhNIG2GLSTndde2r21innm6QJi0ASZFxLZIytQM2H7AztNg7sB1bOS3WbiMO3r9hmN0L1TjmOZql4k2U54eg= 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 1/17/24 07:19, Christian Brauner wrote: > And drop_caches is a big hammer simply because there are workloads where > that isn't feasible. Even on a modern boring laption system one may have > lots of services. On a large scale system one may have thousands of > services and they may all uses separate images (And the border between > isolated services and containers is fuzzy at best.). And here invoking > drop_caches penalizes every service. > > One may want to drop the contents of _some_ services but not all of > them. Especially during suspend where one cares about dropping the page > cache of the home directory that gets suspended - encrypted or > unencrypted. > > Ignoring the security aspect itself. Just the fact that one froze the > block device and the owning filesystem one may want to go and drop the > page cache as well without impacting every other filesystem on the > system. Which may be thousands. One doesn't want to penalize them all. I'm not following the problem with dropping all the caches, at least for the suspend use case rather than quick user switching. Suspend takes all the services on the machine offline for hundreds of milliseconds minimum. If they don't hit the ground running... so what? drop_caches=3 gets the metadata too, I think, which should protect the directory structure. >> >> 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). > > Yes, of course but that's fine. The most sensitive data and the biggest > chunks of data will be the contents of files. We don't necessarily need > to cater to the paranoid with this. > If actual security is not required, maybe look into whatever Android is doing? As far as I know it has similar use pattern and threat model (wifi passwords, session cookies, and credit card numbers matter; exposing high-entropy metadata that probably uniquely identifies files to anyone who has seen the same data elsewhere is fine). But then, perhaps what Android does is nothing, relying on locked bootloaders and device-specific kernels to make booting into a generic memory dumper sufficiently difficult. >> >> 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. > > Yes, which we know isn't feasible. > >> >> 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. > > I'm really trying to look for a practical api that doesn't require users > to drop the caches for every mounted image on the system. > > FYI, I've tried to get some users to reply here so they could speak to > the fact that they don't expect this to be an optimal solution but none > of them know how to reply to lore mboxes so I can just relay > information. > User replying here :-) One possible alternative would be to use suspend-to-encrypted-swap instead of suspend-to-RAM. It feels like it was left to rot as memory sizes kept growing and disk speeds didn't, but that trend has reversed. NVMe SSDs can write several GB/s if fed properly. And hasn't there been a recent push for authenticated hibernation images? That would also protect the application memory, which could be quite sensitive I think because of session cookies, oauth tokens, and the like. I assume that a sophisticated adversary with access to a memory image of my logged-in PC would be able to read my email and impersonate me for at least a week.