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 34051C4829E for ; Thu, 15 Feb 2024 23:17:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB1468D000E; Thu, 15 Feb 2024 18:17:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B5F538D0007; Thu, 15 Feb 2024 18:17:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A006B8D000E; Thu, 15 Feb 2024 18:17:36 -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 8904B8D0007 for ; Thu, 15 Feb 2024 18:17:36 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5FFB8C07E7 for ; Thu, 15 Feb 2024 23:17:36 +0000 (UTC) X-FDA: 81795602112.12.B0DA225 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf06.hostedemail.com (Postfix) with ESMTP id 8D5E9180018 for ; Thu, 15 Feb 2024 23:17:34 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=H0nsQHBg; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf06.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708039054; 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=2/et5MSWxRm/qeqE7m6EKR3xHrEpnYGsOApna7Ov6Ak=; b=nvnd92T9ioLrvpcgNXvMw19PQVfY6hGhzB9EzNBJ26QAR5niY8KMn1SmfS5YBerrn7/AcL Ve17Y+94NdIgOBsmFzizPcfKCfW6UQ0wnMHRmYetFHHo6FUVWjrlOKheyXzyaWlY+cHRwv OAn+T3UYDUBf7XI04IMaDhxSBJfyxEg= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=H0nsQHBg; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf06.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708039054; a=rsa-sha256; cv=none; b=atgH+vdj0yuMcr5N4ipPg9ZYyPC5Ss6oAMi8KcCaVE0VidBk0DoDSJ6tlT1OJPxbUZk63I 9mri3KO9+531SIkRQBjeFSr31emcyczZ2cDPNy0G4FM2xEmvnUIWoJuSXCj/LGSKcqDrr8 QfpQEwI0uokzFkUXHOi1/p3JxBhWfOs= Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-296dcd75be7so1217927a91.2 for ; Thu, 15 Feb 2024 15:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1708039053; x=1708643853; 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=2/et5MSWxRm/qeqE7m6EKR3xHrEpnYGsOApna7Ov6Ak=; b=H0nsQHBgq582PdVCGERhjAnqNoL24WzRzDdVxl8pfk+GKWuASz2MIi19gt/sUldawM quC4ZcECr9d1dgOdPFLoThwzCgabmHC2u2SwrFx+D2ZHql2rtwxUAUETQ1zgcWg7ohg+ uV7PFW+LxWrmUfHjmJOnyfiAalayqBSNdfhy70SEfcaCW2JwdMeG1w7aTn/qc1DV+wvR tIT+fD2aDJQ0xAB+onpBzAx12Uaa0vK8iDQErE8eSMOJBeMCX93ddZCVsVO8wl0T05DU dsW2Sh/kkyqPlIUmTa6LONVUqSw9+OFS8uZdMz4jYpqelRLg/QGmh8k4GqozS+POvrvm d+Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708039053; x=1708643853; 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=2/et5MSWxRm/qeqE7m6EKR3xHrEpnYGsOApna7Ov6Ak=; b=uRcA/uxqgCeNT+KoCutyGARQB7s34turdRL/42J/i/A1r04ufcnuK95WQ/yPn2c3bt ey5EUuaQW7rgrRlxX1oZuA2DLj8dwW8++cDl7KyeSda+vaCBplPjtHIFsR86FoPPGelT mkHQwtThWvLvEbsXgIylJZR/7uxPVtTHzaJbXHFAXiTo5sehzfjYJkUFSA+jVt+RuvbD opedReb2YADSIlcxGjAQ8W4H/f6OokETEMrfC2Zjvwe4Z82T1gy8pvG5/+Ao3JFHY7e2 qkONN8Q4u/rEziK/pE/orypX+A/BUmhMclAu8C1EPF2lCywZ6Yp3gnkcmwgd5gaVQ8/F Grkg== X-Forwarded-Encrypted: i=1; AJvYcCWA5W8LSOHUeacUZzS2rvStCl7j6koZ5nccUuHvOcxgezYx55SSWB7DfH+fDZRtFvDFTYn8AH1AqI63QmY+oPxb6+4= X-Gm-Message-State: AOJu0YyMH+TsmXrOj+iLo54391pN00aFNhkiUNJyg4n15q61QZWb9LkS WUj6l2Zf0SW0SyYoi416ypAq337WgYZLmha/jJDrwVKn8DPs77IAHRYGMh9vQYo= X-Google-Smtp-Source: AGHT+IFhA4H/FgqLaX5RroaIei6TRFkU6Su0sp4d98cSsiQq3PYmJvaE1sS4txnHDPpO9+9KxCEcqg== X-Received: by 2002:a17:90a:ac08:b0:296:3a5:6fb8 with SMTP id o8-20020a17090aac0800b0029603a56fb8mr3007778pjq.25.1708039053227; Thu, 15 Feb 2024 15:17:33 -0800 (PST) Received: from dread.disaster.area (pa49-195-8-86.pa.nsw.optusnet.com.au. [49.195.8.86]) by smtp.gmail.com with ESMTPSA id eu16-20020a17090af95000b00296f3401cabsm336168pjb.41.2024.02.15.15.17.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 15:17:32 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rakyv-0072Pt-2a; Fri, 16 Feb 2024 10:17:29 +1100 Date: Fri, 16 Feb 2024 10:17:29 +1100 From: Dave Chinner To: Adrian Vovk Cc: Jan Kara , 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 Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: c4thtn3utb4z6fjbxfzftkwi1bc7j7oi X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8D5E9180018 X-HE-Tag: 1708039054-532303 X-HE-Meta: U2FsdGVkX18LlcJfFNoXIo/NpmMQUg/K/lLjsVAOA6MfIb9Xsx4XKUq52rgwkTKqrCZC3BK6Igs1q+CXhQTUwm78T+/BUjakpR5tklWr+8JogXQFIt7HDvcK/t5qcQ7Hek28qSKbp11IvcwKBVJb0nVx3dduCMgPNAtEj64VZB0IzPl2bb13tewg3cDD1YnOo0b2F6ixyHQDZLB2xDPKVcMlUJweqirj4h6QP6shI5+I5zVnpO181WaQcI26rRdO2UOYWFwYuCvDw7mbrdNdO1ArZz7SkCrRXc2dhqmt8P7AsA8I63f20cZCjJHBOAY3g2NpW7H+b6kE2+2+pvY+GdJZaPZDUZq6TScCdX0cnVS+e7UwBdaMJavzK/uB9GDH3CwkjXGsevOnqbZEWZkz+1dqAKuRnamz2qP6WoFZ8VgSHqE2dPY122LIvyVPN0oty/+tZbcAE+XZG/vBRUuqp9KglTx67YKaxdjwPlXX5FIPU0mX3JfgJRLOTaTYNChMxqe7ZH/GZtWNStHG0cgSgoHX2zmH9BOMWCWU2r1xXSjv8z1ukUrdpu0Qg+aBll4EVDmvDt4lgMCpPTX8IDmPQvUpHywNGj1N36eeOB2VPWnnEqY6kVQ/fYOu+KpwqPFnGaTdtnfjIcUYbm1P82Jq3m9hwi9mMZynqiHhlD6+HFoK2zUgQT2ISRd1ONeiurIU5iqcWmqyaLZSxZv9cUPPClOAi8fVF50lijps6XkXCc/EDy2yGu9SVInHVr0qX/vLcJCgGMYqhY2HR056e6sJG29eSHXUxV0RIw4lM/sKAoVAB87M6bIwv36zTUiPgaVI+Hi70BcDK+EuM49jLcAiLayUzspuiHhYFZEjyAR15tubivBvD5/K5zXVyHNKESy2vPXq3B1HBHrIVLKNYSTbTzBGLnxsbNdN9+pyyLcqXEnliidyKRUNVl/TYE8tX2IXHDcW0ZNtcd0o3ckvNfS gOOeirgX 7q/j7mmwC01bUz0IQa/bJ0CCocn4TsHER7xfKF5QNm6no2P/W4OB2s0V4VrVmp0VDF8i1PKlUcqd+Q/hPUsxT5+y9qCGmKAioRYzrn/x0bAypEF4Qc18Sxa0uFQ== 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 Thu, Feb 15, 2024 at 02:46:52PM -0500, Adrian Vovk wrote: > 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. Memory pressure does cause cache reclaim. Not just page cache, but also slab caches and anything else various subsystems can clean up to free memory.. > 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? Memory exposed to userspace is zeroed before userspace can access it. Kernel memory is not zeroed unless the caller specifically asks for it to be zeroed. > - 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 truncate(), fallocate(), direct IO, fadvise(), madvise(), etc. IOWs, there are lots of runtime vectors that cause page cache to be freed. > other words, what situations would turning on some zero-pages-on-free > setting actually hurt performance? Lots. page contents are typically cold when the page is freed so the zeroing is typically memory latency and bandwidth bound. And doing it on free means there isn't any sort of "cache priming" performance benefits that we get with zeroing at allocation because the page contents are not going to be immediately accessed by the kernel or userspace. > - Does dismounting a filesystem completely zero out the removed fs's pages > from the page cache? No. It just frees them. No explicit zeroing. > - 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. You can test it for yourself: the init_on_free kernel command line option controls whether the kernel zeroes on free. Typical distro configuration is: $ sudo dmesg |grep auto-init [ 0.018882] mem auto-init: stack:all(zero), heap alloc:on, heap free:off $ So this kernel zeroes all stack memory, page and heap memory on allocation, and does nothing on free... -Dave. -- Dave Chinner david@fromorbit.com