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 48D43C3DA7A for ; Thu, 5 Jan 2023 22:57:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D99EE8E0002; Thu, 5 Jan 2023 17:57:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D4ACE8E0001; Thu, 5 Jan 2023 17:57:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C12928E0002; Thu, 5 Jan 2023 17:57:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B1CF98E0001 for ; Thu, 5 Jan 2023 17:57:39 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 71628A5EE0 for ; Thu, 5 Jan 2023 22:57:39 +0000 (UTC) X-FDA: 80322259038.01.4077BF5 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf03.hostedemail.com (Postfix) with ESMTP id B0A812000F for ; Thu, 5 Jan 2023 22:57:36 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=d3U57LHD; spf=pass (imf03.hostedemail.com: domain of "SRS0=d7xY=5C=zx2c4.com=Jason@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=d7xY=5C=zx2c4.com=Jason@kernel.org"; dmarc=pass (policy=quarantine) header.from=zx2c4.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672959456; a=rsa-sha256; cv=none; b=ZHmjYfVyzF91vQ1udhZarCDwcOhMU7T/Wbb0vzWpfb93bHhwAIIKo0TekYfu2CnAxba580 BjbssYoJB27fKTnsix6sbokSsluf2FpsEvVYtUGWwBLK2qcJ6exhDrD2/p70cvhT1Xf+gV Rrix8efJ0Tn6cfcej59JN6+tpU6eKLw= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=zx2c4.com header.s=20210105 header.b=d3U57LHD; spf=pass (imf03.hostedemail.com: domain of "SRS0=d7xY=5C=zx2c4.com=Jason@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=d7xY=5C=zx2c4.com=Jason@kernel.org"; dmarc=pass (policy=quarantine) header.from=zx2c4.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672959456; 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=INhUx6/3Xhk2/xGcSTChC+f55M0MZlL+ygV3JkGy+qw=; b=JGoTaqmgsN7wufH+QY/Qytp64hWShaC5WTn8fhgECK/HeupGpx8lBLv+uk26nf8Bq5vsDz L2f7BC2aIIY4O4NH+mJ6/CXqmsHnesjuBQ0N5+XQW+6AZQcD/t36E7Wqc7RNKnwtDiDgJD GdRNrDG9tVigVzKExnN+vKuiMNCYkbM= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2ACA4B81C01; Thu, 5 Jan 2023 22:57:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2E39C433F0; Thu, 5 Jan 2023 22:57:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1672959449; h=from:from: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; bh=INhUx6/3Xhk2/xGcSTChC+f55M0MZlL+ygV3JkGy+qw=; b=d3U57LHDK5/g5g3S5DBYHkQoCwcYk8ZV6a0oM3Z6SewXdvSOqXsdHHaQbe31rTK2/sDwM8 uMa3NJfzLzSkKnpUMBkGoQwKDNdqTWO6cQbSV8C+gyuenY/YH3A7RWhDB0eL4EaO20uqvQ CziJ/xm7YuUGNCJojapunpRX30XKVzA= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 8daf678c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 5 Jan 2023 22:57:29 +0000 (UTC) Date: Thu, 5 Jan 2023 23:57:26 +0100 From: "Jason A. Donenfeld" To: Yann Droneaud Cc: Linus Torvalds , Andy Lutomirski , Ingo Molnar , linux-kernel@vger.kernel.org, patches@lists.linux.dev, tglx@linutronix.de, linux-crypto@vger.kernel.org, linux-api@vger.kernel.org, x86@kernel.org, Greg Kroah-Hartman , Adhemerval Zanella Netto , Carlos O'Donell , Florian Weimer , Arnd Bergmann , Jann Horn , Christian Brauner , linux-mm@kvack.org Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings Message-ID: References: <20230101162910.710293-3-Jason@zx2c4.com> <10302240-51ec-0854-2c86-16752d67a9be@opteya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <10302240-51ec-0854-2c86-16752d67a9be@opteya.com> X-Rspam-User: X-Rspamd-Queue-Id: B0A812000F X-Rspamd-Server: rspam01 X-Stat-Signature: fgiut4ok4c7njiaby9y4a6y9dh1arbgp X-HE-Tag: 1672959456-543404 X-HE-Meta: U2FsdGVkX18M0ptg1gTnsbIX4OH8sQWrc2bX77ZkzK1jcmS7A58/ygkLE4vcc5Hn2PGz+wVDffLKfOtv2RDxtee58ukcxumIcBK6gzwOnd5+Ww99TS6cdD1At6wsGtYNtFrk+Z6LBm7vLVj7w5xnklnVWyEYEZzdOeB57F0xkK9ZTls3jpbOKaadzV8d1xXwACvp5LqqeTYYeNyrzsHrs8iVKihLo099osJcl/n072lorvy0EsT79OK0VBRaJU6/xLxjxPqwNJ3dK2RPLuOfKQOaERf57D92KK3EFzxRtscJKI4iHQ2wfOcYxA4x2zBDF5ARZFfxOMh+8JYYvZ0WSsWHAxAIh0Oxj4x++S57yQM7zSvaSNiaxZx9jLmbI3S+Xz9AqC0yqJXznc5ETEzF33XHkHqAUH8YYjOdkuUoHTVG5z72oGIUH027I1QPSSwmT7YePRHTcCnJluh7SWe/Uw3yFtUo5lMeCAuzAsy4+Sxu4Zq+01NmVWgGf+5cDIZrCwyL7uAVYwr/dW+iPsVI70+02PaLKQ0LBFnF/sLxFx7Y8KKB+Y3z2b2fUHucgT9XR1EjuuhWY/DCdkPElz29PLcjT64jXGBiCDr5sSbedxVHiO/nzBCbHpQm12V+3u+1sbEGMkFrVBwDPZ27pgwLpGuARfyRT+D0/VEZCPAZ8xZ2XFJE47m6tAXX5ZPDg0uygFwxhU6shSWR5Jvq71XUWbGueJQEkG/2P/WkNWCUTTr+NsrgNfVGG0r+PklK4vxPjnlHOcrCnFlY0KOU3GuNifl4f29HuM80DwFLXEPqdF0fwFlZLqxGq1x0YYegjcI4y/2zmgG2CUAvtjD9ozOzIVRwyhKN+Rhyi4u6DwkiDo/KBv1Qp2cYzbIP9eaSoWeTuKf7UG+RosQ+k3VLLMzdxFAhKJ8yJ2seqp84xW2IrQllGhZKOjmF7mXCyuqWu4+LH4L9rAB9sRF/AS854LZ vaW9JZNC oIdnj+fUw2DGQ7CSYqxevgxo85V2U2kyBaNPoxWddGpeWDqy+wua5J989N9dyDNBcEmcEMRDWqMOILF7Ep/W8qS7Mh7y/cAHsPvNhDruA9LnJSEYXwhoDlJOsd0Xlm/2A3NF10zoskutFWoi4Cqy0Tp1dXhjPH6vUCXb9AYs4/CJsOPAT13uIv/GjhQZSPr0o47gmNvZuFwpJlGMZ/tqxt1GCqIo3+IgySZpoL/qPAMyIGs84WEe4nIYGi14Onbdip9RMc3/YF+qZvzc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jan 05, 2023 at 10:57:48PM +0100, Yann Droneaud wrote: > Hi, > > Le 03/01/2023 à 21:44, Jason A. Donenfeld a écrit : > > On Tue, Jan 03, 2023 at 12:15:57PM -0800, Linus Torvalds wrote: > >> On Tue, Jan 3, 2023 at 12:03 PM Jason A. Donenfeld wrote: > >>> That buffering cannot be done safely currently > >> .. again, this is "your semantics" (the (b) in my humbug list), not > >> necessarily reality for anybody else. > > Yea that's fair. Except, of course, I maintain that my semantics are > > important ones. :) > > > I concur. > > To hold secret material, we need MADV_WIPEONFORK | MADV_DONTDUMP and the side effect of mlock() (pages' content never written to swap), inherited across fork(). > And I want mlock() without paying the price. > > Jason's proposed semantics, which I call MADV_WIPEONSWAP, provide a mean to hold /unlimited/ amount secrets in userspace memory (not limited by RLIMIT_MEMLOCK). > The only constraint for userspace is to handle the case pages are wiped, which is already the case of userspace arc4random()'s implementation. If you're actually serious about wanting a generic mechanism for userspace, I think the moral of yesterday's poo-poo'ing all over this cool new idea is that the Linux innercircle doesn't really care for "security things" as a motivator and just takes the shortest and easiest route toward swatting it away like a gadfly, assuming that the concerns are unreal or niche or paranoid or whatever. This is obviously nothing new - it's an old complaint beaten to death for years, with people who are diehard it about eventually getting burnt out and leaving. So, practically speaking, if you want this to exist, I think you have to find some other cool use cases. Like, see if the database cache people would actually love this. Or if it could be used as an opportunistic renderer cache in Chrome that wouldn't result in OOMing with lots of tabs. Or if shared process compiler servers could benefit from it. "Droppable cache" is likely useful lots of places. So just find SOMETHING that doesn't mean having to convince folks of a new security model that justifies tickling mm/ innards in uncomfortable ways. Jason