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 19005C54E76 for ; Fri, 6 Jan 2023 02:08:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25B7F8E0002; Thu, 5 Jan 2023 21:08:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 20BF58E0001; Thu, 5 Jan 2023 21:08:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AE548E0002; Thu, 5 Jan 2023 21:08:51 -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 EC0698E0001 for ; Thu, 5 Jan 2023 21:08:50 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BE5501A0228 for ; Fri, 6 Jan 2023 02:08:50 +0000 (UTC) X-FDA: 80322740820.09.5782C9F Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf19.hostedemail.com (Postfix) with ESMTP id 07BFB1A000E for ; Fri, 6 Jan 2023 02:08:48 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=P6XRZRqc; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.172 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672970929; 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=BiZr/M2mt9gUTQKPQ4MQC9Idh91qUV736LW/CBudrbE=; b=WI373ysmIasx8CHJ/5yOI1XsRvQF2Q5A3Iw08hW2KAS++bAIA5Dlq+IXLcoACcLLo4EKOT nDAMT9rcsRYfE8NFreFkqrVgi2xYC1FYwcIFMEZ9Afny0YPPXSdtWVfEjaQDwautVDNxiI E8KnPweffM/k+Nc0SMhIwafKB8sMlqw= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=P6XRZRqc; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.172 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672970929; a=rsa-sha256; cv=none; b=32keqXHWswlVGJPd9ZxfMYKhiN7Q0oT8N9gpJhC8Eq61HJO9bIwEt0mlqhHLDioJUYPseW zsHHi2fTf8Qtq+eDAOu/NTlsllIcIPR0zL+toomqw8bYXBFRmDOMe3twupje8ajInACPxQ qAJ+ErGNrQglXczbIG0X61t/SEj1v8Y= Received: by mail-qt1-f172.google.com with SMTP id h21so960940qta.12 for ; Thu, 05 Jan 2023 18:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BiZr/M2mt9gUTQKPQ4MQC9Idh91qUV736LW/CBudrbE=; b=P6XRZRqc9dOjMMfEouyKdDiSj6G0ngTgOdZFQGSK75nkXucj9HkSaMYockndHF8Fgv JpamW/mn6TTZlF+lr+0GH7uDfMqIljr7VdSxGTydv+v+N5EB1KGXMLstsXEyad+KVLek 0ijEMujzD3TCNaC+kW7hIIfLR7gJwBPXI08m0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BiZr/M2mt9gUTQKPQ4MQC9Idh91qUV736LW/CBudrbE=; b=rRjfn5KKEO7XGtXXzQuyJDrm0izlUllnyXP8bf21L8ogTqUdR2h19hQlfLHvktdczf n+zdDIHG1KAy3TtkgLvliRgg0B7iFVdI/ak/5lLCMFfKHMaDwLCy2uPM6fSdKviNUoKN fKCBQs6VNfHARVrJ/W/QdirZcMeKtUgK6HeWfMQMpaCjD2BJclY/26jEBGvbC4xXfXld wrbB3+pMH4Gb/lwRM58jMCF+GZNFIY4ziezxxJ8OP04SiEyJEyAc5WQTnQlYvScuVXT8 VtMgBbo/L6+S/rpBdKWEM9DDArFsFd3pTnOL3A3Vwu8UviX7v/Ian1Zu14VGYP1tBHxJ AHxQ== X-Gm-Message-State: AFqh2kqXGB5iOQwJ9pJ1GSCaVoad+zs/vRV+J+R3efGMtqNQHcUbgNM7 Cl0NoezFPjxggJqgYKB/zZaG59Xbe2ypFUH8 X-Google-Smtp-Source: AMrXdXvqIgdj3Td3bhbmPTzbJOOyT4/J/2te86N72n0ColLseqbUttcP4SRSlPEAxUiknPIAkrJfLg== X-Received: by 2002:ac8:5646:0:b0:3a7:f599:220e with SMTP id 6-20020ac85646000000b003a7f599220emr83272248qtt.55.1672970927737; Thu, 05 Jan 2023 18:08:47 -0800 (PST) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com. [209.85.160.179]) by smtp.gmail.com with ESMTPSA id t4-20020a05622a180400b0035badb499c7sm22669184qtc.21.2023.01.05.18.08.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Jan 2023 18:08:45 -0800 (PST) Received: by mail-qt1-f179.google.com with SMTP id bp44so1212917qtb.0 for ; Thu, 05 Jan 2023 18:08:45 -0800 (PST) X-Received: by 2002:a05:622a:428c:b0:3a6:8b84:47ce with SMTP id cr12-20020a05622a428c00b003a68b8447cemr1471748qtb.678.1672970924763; Thu, 05 Jan 2023 18:08:44 -0800 (PST) MIME-Version: 1.0 References: <20230101162910.710293-3-Jason@zx2c4.com> <10302240-51ec-0854-2c86-16752d67a9be@opteya.com> In-Reply-To: From: Linus Torvalds Date: Thu, 5 Jan 2023 18:08:28 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v14 2/7] mm: add VM_DROPPABLE for designating always lazily freeable mappings To: "Jason A. Donenfeld" Cc: Yann Droneaud , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 07BFB1A000E X-Stat-Signature: nrnkgik5x8pjj9yfbga8bdrpdrrazo8w X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1672970928-283569 X-HE-Meta: U2FsdGVkX19BNfxSyZIfX6ivCGo2fWhkhmgu8DXnB1f0ERuV9tosScZ069KrgdsQrp0yVJpFvoyDf7EiJ6wfqI573gfPIQGNXD/lIdKVbD1ayNGBLRxHIjEc7mpxegkrl0la0ksStDcsuNqSmmtsqssmw0wzwM3aUh1Y6i3ZRCDWIqg8+BQ/zQN2yI0ncOEJEILsNe3e0vFAmTwQgG/gc/7T6XscDsrbyAPH4xVWE4M/4VMCHFiWDaFrNo8pEJfqOqweKZSVgxV490qeccFiEldUWal73eadnLOhkOesmC3Clf7qxfNNylVN2GPwb50b380pGZQDwozAu/vaFExcRQl3l1FLMkMgxeYgb4w+5TMRGiJPFhMukRZ1rwIMrkSMnjoVEukC4PslYA6BBp6DgcRSjPbDjZ+rmZXZexRDdTbUzxYGcxxE4ZY6uqSUPvn2nclMPSzOLZ48FYHIXvbZrWiFR7QbLU3boZmgAb67zkDTKRrlnkJHQlPhHrKqCXjfYzQJMSPHC5/y7a/bco9gtDs/HZqOmImbHaRtNfUh5bAkP571fKMGEEW7lMcCyc9F6hcRlO/OBoSC6SV7nUJcMbYBhP8urllcZp/LrOVNDn2o1WH3RshAV3saSmv0+qafSxBSp10dlzE4/XyXX+LhpdylX63U5HcX9liDxpE8W8tSLjaRIwpUoJvMhCWJAr+uSXwNebwAVDJwNq93wurW6TWrHiEvZ+Oh4WmSZ6Wju1h+Etbclq332kPAGUfULFsGEEmKlQIW1J1lROrg/z7QCEFNU2EzcVjU8FErk898Im35UecRr0IpIBjNvXGGjaVacPTTaryhzaUPktd0WABhEBDZbC4pFcnM2EV5sm0yDN2kBTNF1vEIUS5lxMALoe/VCs1rQPOrxLufpdeLtAOm/qwPvSQn0UnVBS8jnm299obrQjFBAh4yfxapW3RF98g9P90Y96edBRC5aQC13yU gIVZb3tw 8FYgONQEzTbMPkE/TkWGmR8rrix8OzxOappksEuT6lyaDHu04lpRAcd7Kl20XaDQswhvW7v6Rjw/x7hxGbRAWD90WqbO3IYJf2OARO2Qp+0pwXEYq6ZzY649qQBa4qJGjjJZ/QMQFDC2UpK1j7Wbql8DdfmSpaDlWhs3yhrbjMFSomPQ0VfGkLThZSikcKy7mj6NujJYcBk+kI9HAKF3TS+rIiwpOykRBWyIcaVrG6210MLfSdfmYSsXvlE+JCYxH20hiMepMcF/9YG1y41JO30M0beA0eb+pH5dfiK4Wjysb14PEHL2Jh4K/lxGz70H4gVzKDzBYJMRp81YKC7VZEh63Ng== 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: On Thu, Jan 5, 2023 at 5:02 PM Linus Torvalds wrote: > > None of what you ask for is for any kind of real security, it's all > just crazy "but I want to feel the warm and fuzzies and take shortcuts > elsewhere, and push my pain onto other people". Actually, let me maybe soften that a bit and say that it's "convenience features". It might make some things more _convenient_ to do, exactly because it might allow other parts to do short-cuts. But because it's a convenience-feature, it had also better either be (a) really easy and clear to do in the kernel and (b) have sufficiently *wide* convenience so that it doesn't end up being one of those "corner case things we have to maintain forever and nobody uses". And I think VM_DROPPABLE matches (a), and would be fine if it had some other non-made-up use (although honestly, we should solve the 32-bit problem first - ignoring it isn't fine for anything that is supposed to be widely useful). We *have* talked about features kind of like it before, for people doing basically caches in user space that they can re-create on demand and are ok with just going away under memory pressure. But those people almost invariably want dropped pages to cause a SIGSEGV or SIGBUS, not to come back as zeroes. So you were insulting when you said kernel people don't care about security issues. And I'm just telling you that's not true, but it *is* 100% true that kernel people are often really fed up with security people who have their blinders on, focus on some small thing, and think nothing else ever matters. So yes, the way to get something like VM_DROPPABLE accepted is to remove the blinders, and have it be something more widely useful, and not be a "for made up bad code". Side note: making the 32-bit issue go away is likely trivial. We can make 'vm_flags' be 64-bit, and a patch for that has been floating around for over a decade: https://lore.kernel.org/all/20110412151116.B50D.A69D9226@jp.fujitsu.com/ but there was enough push-back on that patch that I didn't want to take it, and some of the arguments for it were not that convincing (at the time). But see commit ca16d140af91 ("mm: don't access vm_flags as 'int'"), which happened as a result, and which I (obviously very naively) believed would be a way to get the conversion to happen in a more controlled manner. Sadly, it never actually took off, and we have very few "vm_flags_t" users in the kernel, and a lot of "unsigned long flags". We even started out with a "__nocast" annotation to try to make sparse trigger on people who didn't use vm_flags_t properly. That was removed due to it just never happening. But converting things to vm_flags_t with a coccinelle script (hand-wave: look for variables of of "unsigned long" that use the VM_xyz constants), and then just making vm_flags_t be a "u64" instead sounds like a way forward. But again: this is all about new flags like VM_DROPPABLE not being some corner-case that nobody is expected to use other than some special code that is relegated to 64-bit only because it is *so* special. Linus