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 A95B0C4829E for ; Thu, 15 Feb 2024 19:46:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C13F8D0013; Thu, 15 Feb 2024 14:46:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 371238D0001; Thu, 15 Feb 2024 14:46:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EB648D0013; Thu, 15 Feb 2024 14:46:58 -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 07DB48D0001 for ; Thu, 15 Feb 2024 14:46:58 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AE4271403AC for ; Thu, 15 Feb 2024 19:46:57 +0000 (UTC) X-FDA: 81795071274.13.B08C5B4 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf30.hostedemail.com (Postfix) with ESMTP id B2B0A80012 for ; Thu, 15 Feb 2024 19:46:55 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=K+RVsFlE; spf=pass (imf30.hostedemail.com: domain of adrianvovk@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=adrianvovk@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=1708026415; 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=0a9EFonqMBn2eHbLHRvN6s4nh6pQCa5EAdO92aYTphs=; b=DMGH1o5PUkPpjnvo296J3OKMaD6OnFIvGOBlSZWaeRyj3IZilxQbEg4Zvp11ZkCc84p9JK wSPqOORwMt8kW6J3QBTwrX5yjcvdq/XUhJMU+rallVi3dmwKiJdeDewoXty/ZIIXOxlvWp DyKaE3fcCVz91Iko6qrOffpwbIpxSdU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708026415; a=rsa-sha256; cv=none; b=6lkrO5TxNCt5inmoA4xr2GX2N7Ib9rOOa7DCavl8xhqBgNh5ChxUjrpSDnCPd315X1Kv3a +3tjifU9f58yTwr/YY/Uno41Vd9agjayKeszGC7F5rpPbR2PeAWjN3N3BhxJULFwSqNjHp sET970WBkd0Z7yIFlU3NOIg47roPwDg= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=K+RVsFlE; spf=pass (imf30.hostedemail.com: domain of adrianvovk@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=adrianvovk@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-68f15ff496dso5145896d6.3 for ; Thu, 15 Feb 2024 11:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708026415; x=1708631215; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0a9EFonqMBn2eHbLHRvN6s4nh6pQCa5EAdO92aYTphs=; b=K+RVsFlEcuy6grQ5BaJ3aTHw7PirH8PKTeHpcEJ6WjmmxwN4kKNLWdsb7IpGATNJhq VxrqbghdQa/DRZO+1HGVd8df+LJrcaip6xWHILgB3I35wRtscRiWb/TQWMeRCgpVjEj1 BjieVL4zrBFhyuTkA4OpS+nj8fOQDMYnhAuSDCYvLHRGHpQImba+RgDVh6aAG0MSDSZX oobysnmfZU0g3u6hPcbj4RtuuiIiDFqlQUGS88PujPz/N0KGABXnBa+FYD06hyXQcKPa ZQWVi0pg34yBSgjwUSmB6kWgIv+P0ylvu3NPouqZNMgfgAl1trb2vgqZvFL+U8OgMpzs S7HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708026415; x=1708631215; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0a9EFonqMBn2eHbLHRvN6s4nh6pQCa5EAdO92aYTphs=; b=YaPJzPjkOt/x2BrBRBF7vlA7J+/69uXTsP6wePU0Uu5iwWWYmj2kt1suaIlvbAtu71 3PSUwSa++wYrMhOJraWxQFnwwiYmI6rROFcHG4s6H8jRykhDM+Ef32wa1a7KYVdgdDNO TiY7FFrgsTz4Kf+v0GDcux9uZzJcOCWgisf+8GRc7BkKLX+s+oEr7YxgSExxzjFpCkgB v+oaosm/Wn4kTVXyBT29aG89RUkJDwajYQ8JXtsZuIgUH4Y9xOba6xDIHwGJQWyl0dTs EFij05bENjgXRBKWuOI8CVHy1zOvezFUn/bIchhSh1nap7ho3yGkLSL/ehNVdyI1kJeW 8sjw== X-Forwarded-Encrypted: i=1; AJvYcCUXmI6E0bGCA8Tbz6BDbB8I0Iag/YlGBE/JL9aP9BKEfrZaPfduvO/8sxmJuLSM8maj0WeGUluXee2E4j6o5gKmXQk= X-Gm-Message-State: AOJu0YzrI4JpZT2N81FX2MFRJh3lOHFHj+oZ8iu5089ZEJRvwuEbBBD6 LvEfG/tIBmAC8BtAi1d0xzgrEEOOwA0Y5x4PBMeDWoqgGksGaog7 X-Google-Smtp-Source: AGHT+IFUlCyEzpVqAiRhaKG/YKslsjBvW/1ZGIwwpMuMpyt9VGtgXczGDx9ymu2IxKEw8fJvFKJiLQ== X-Received: by 2002:ad4:5c8f:0:b0:686:a185:dc11 with SMTP id o15-20020ad45c8f000000b00686a185dc11mr3520139qvh.55.1708026414655; Thu, 15 Feb 2024 11:46:54 -0800 (PST) Received: from [10.56.180.189] (184-057-057-014.res.spectrum.com. [184.57.57.14]) by smtp.gmail.com with ESMTPSA id og11-20020a056214428b00b0068f2b1d9415sm413691qvb.23.2024.02.15.11.46.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Feb 2024 11:46:54 -0800 (PST) Message-ID: Date: Thu, 15 Feb 2024 14:46:52 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs To: Jan Kara Cc: Matthew Wilcox , 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, Christoph Hellwig References: <20240116-tagelang-zugnummer-349edd1b5792@brauner> <20240116114519.jcktectmk2thgagw@quack3> <20240117-tupfen-unqualifiziert-173af9bc68c8@brauner> <20240117143528.idmyeadhf4yzs5ck@quack3> <3107a023-3173-4b3d-9623-71812b1e7eb6@gmail.com> <20240215135709.4zmfb7qlerztbq6b@quack3> Content-Language: en-US From: Adrian Vovk In-Reply-To: <20240215135709.4zmfb7qlerztbq6b@quack3> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B2B0A80012 X-Rspam-User: X-Stat-Signature: fa51ndsqpc3b5pzwsei3snk6db8ibau5 X-Rspamd-Server: rspam03 X-HE-Tag: 1708026415-528133 X-HE-Meta: U2FsdGVkX1+5KC1mVnFBGcL+wAqse7AE61/xw/B9A7ySk+sn/WRqeslT5pLV/veDw9yXVt5uwwv2l66S+h2S8XgHIq7DpBY0SpPVrU/yXsa2cteRzqTdaeB6Pnz8s3KuBEmt0oGGiptEFItDFZU2lXLH11bzVMZkAV/1F00sRTY87Ha7l0QV5il8ACa44F8X53TzZmlNTuY16V786/331OPsjSFmqMqrZp5u60wWzG5SdVpSYsSR4lxm0Iidh47AjG2Z4wd31JITqolv1QXjlO1+Bj0IVqcve6pF6d4L2wBdmDPCVayd6F4ZovKoCYvjY33i0UnhtUJZnQS1Kw+hzVOcdjoT15FkNS7tf42l3oppTnln+DVtd/pfyTSzvu/WcZUNhhbM+XQDPvRXuugg3+xDzYNruHA2/ti3Aqeh7Ea5aBPQZtjvyA3sAMSBkcb4gEEZq6J1X0wei0a+7kW7e7FXOzOhtmaS8rMfW8dpkRhLd7L9Gs8Sf2pkrEfxYoqxqRyvwCmn/OMP6uf84xevjbKGZkf7B3Yq+hm5aUMJnlAh6L/WSxFztVWKBoeOuxEpwWAjNShh1C5d+fYgyApbrlSbmyrieM+UPhHJYA1lVLxnCRchfM3/7LfNdXrxCDAPGZ2UmsbB7PYYvZIL9IOkbxb/Bx8HPX1hzDVDH5iumFjJ4UCO8HRiGhD98a97xG/ZybsP0vZhSRn3aZOZDJ7Slfbm2Wcd+Wg+b5qurzYRIk8jmZn0/GkzJ/aDnGUsfgwjVSeKcixYGLLl2XZ64UauG5+sMC0B4OTmSTSEpLXo9QKhIEL72sMHUBSYc3GGvxJX6ve5w41ezZ1nKbGoHLOqWgRZSie0oNsGv28HBTnmuClCagzxkKUxPdxXmUUehN8LA4pZdoUfyOixpucMGBgr7kbIk1st53AaLQeBkUZ61ur8to7fglNnEIPd2/46t4VnWECK4+dhG/+rWa5TxL1 uOhMWZNQ keYUijVRStjZbo+mzYCXheZCN+wZQzRmb6UNEjy+Qm9ZFEo2vCl49y/q1+FXCxOf3ns7DYLCEIkw6Bne3rjr8oVl28nOvl2ESPZlQSf6URvToXnQGoxPl08S4rKYNTHYNVAy4uVQeJvmgvfYuyxGDWuG4zEzWZgvz6bAGVW0IDm9Wit/SvqfAivEgupdBndqleFTJ+qcUQbKCkWBDc6hM9AZMkjXtKfNKOwB7sKA/UC4HyExXcw06vEnprJ2NDfIBlOOxag3CcZq9xXSFp5iN3E/4TNdAfGFaLi1/VGX3vsU63PpsSfYHoGXS7L3cpiuv8LVknYi2kJZgLbUaSmPlXjh0rs6wlbaSd+nBcO4yKhNVLNWmWKqsLyrCBg7g37n32FnJ0FSRlnTSdyylhghqO076wVNE1Cx8U7rs4HNHCxPzbwqV8D4Utkjdz6o3mCxJlRf2pK07hpU6FtzFpbL3oPMvfQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000091, 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 2/15/24 08:57, Jan Kara wrote: > On Mon 29-01-24 19:13:17, Adrian Vovk wrote: >> Hello! I'm the "GNOME people" who Christian is referring to > Got back to thinking about this after a while... > >> On 1/17/24 09:52, Matthew Wilcox wrote: >>> I feel like we're in an XY trap [1]. What Christian actually wants is >>> to not be able to access the contents of a file while the device it's >>> on is suspended, and we've gone from there to "must drop the page cache". >> What we really want is for the plaintext contents of the files to be gone >> from memory while the dm-crypt device backing them is suspended. >> >> Ultimately my goal is to limit the chance that an attacker with access to a >> user's suspended laptop will be able to access the user's encrypted data. I >> need to achieve this without forcing the user to completely log out/power >> off/etc their system; it must be invisible to the user. The key word here is >> limit; if we can remove _most_ files from memory _most_ of the time Ithink >> luksSuspend would be a lot more useful against cold boot than it is today. > Well, but if your attack vector are cold-boot attacks, then how does > freeing pages from the page cache help you? I mean sure the page allocator > will start tracking those pages with potentially sensitive content as free > but unless you also zero all of them, this doesn't help anything against > cold-boot attacks? The sensitive memory content is still there... > > So you would also have to enable something like zero-on-page-free and > generally the cost of this is going to be pretty big? Yes you are right. Just marking pages as free isn't enough. I'm sure it's reasonable enough to zero out the pages that are getting free'd at our request. But the difficulty here is to try and clear pages that were freed previously for other reasons, unless we're zeroing out all pages on free. So I suppose that leaves me with a couple questions: - As far as I know, the kernel only naturally frees pages from the page cache when they're about to be given to some program for imminent use. But then in the case the page isn't only free'd, but also zero'd out before it's handed over to the program (because giving a program access to a page filled with potentially sensitive data is a bad idea!). Is this correct? - Are there other situations (aside from drop_caches) where the kernel frees pages from the page cache? Especially without having to zero them anyway? In other words, what situations would turning on some zero-pages-on-free setting actually hurt performance? - Does dismounting a filesystem completely zero out the removed fs's pages from the page cache? - I remember hearing somewhere of some Linux support for zeroing out all pages in memory if they're free'd from the page cache. However, I spent a while trying to find this (how to turn it on, benchmarks) and I couldn't find it. Do you know if such a thing exists, and if so how to turn it on? I'm curious of the actual performance impact of it. >> I understand that perfectly wiping all the files out of memory without >> completely unmounting the filesystem isn't feasible, and that's probably OK >> for our use-case. As long as most files can be removed from memory most of >> the time, anyway... > OK, understood. I guess in that case something like BLKFLSBUF ioctl on > steroids (to also evict filesystem caches, not only the block device) could > be useful for you. > > Honza Best, Adrian