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 C488CC3DA7A for ; Fri, 6 Jan 2023 01:02:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C02788E0002; Thu, 5 Jan 2023 20:02:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB2618E0001; Thu, 5 Jan 2023 20:02:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A530C8E0002; Thu, 5 Jan 2023 20:02:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9425A8E0001 for ; Thu, 5 Jan 2023 20:02:26 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 57EF71C6376 for ; Fri, 6 Jan 2023 01:02:26 +0000 (UTC) X-FDA: 80322573492.17.B2C5F2A Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf07.hostedemail.com (Postfix) with ESMTP id 9B49240008 for ; Fri, 6 Jan 2023 01:02:24 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=groJ1iJJ; spf=pass (imf07.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.169 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=1672966944; 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=E2zTyAKcMSHj1NuBZpldWBfP/uR4r0Oo4FG0pR0Pc4o=; b=hmWn/jclnlQB0dt3oOY4tTrhux7/QTELLjMmFAAweMxnUQ5C2cXYjb+OztHICcslwD7LJA QuFHTJWyuacyfEY1UN5Dwsaj7bhUWuhoiqbHbHVBbftCyZXYscq19Mo7AUqvYq+KCgfPqc p5tTBuh3Iziwr+HEFIaofB8yag8X9PI= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=groJ1iJJ; spf=pass (imf07.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.160.169 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672966944; a=rsa-sha256; cv=none; b=WYziHJub7KVSnEWRj99N+s2sGpJai5Wz4wmdxOt2qzBCVrwVYXpqasMFSfa1wbDIqeOPp2 s7YuvpNpSX1st8+ZE5AyaXS8kQrbliufhLMvhWVmFp8CaWkbxXXZWxFPzfyKkgs9dALLmw PvClQoyiyIRAjuGuI7v2/Zhnh5+N1tE= Received: by mail-qt1-f169.google.com with SMTP id h21so848869qta.12 for ; Thu, 05 Jan 2023 17:02:24 -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=E2zTyAKcMSHj1NuBZpldWBfP/uR4r0Oo4FG0pR0Pc4o=; b=groJ1iJJAbzkeoFY5z0vFFmU8BFSk2iIyzy4jspxCVqwwWmPsIsjEfRdLdBElbBGOT EmrM5lijkGvSvr3nKF/I3GI8riFE7PasAhLLNA/4T+m976ixjVmwz3IcMaPuxSRT3Kgg txcqpXsJ9kof2smhhnslMFaxYEJR/ApjGac1A= 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=E2zTyAKcMSHj1NuBZpldWBfP/uR4r0Oo4FG0pR0Pc4o=; b=0LUSFyZ0GfSk5F/bn7AX1Krt8UbSZ4anOI3NdoPb36WbS2uEmS1RCk7q7x8I6EilSG McIAoFuGv8/1/HGKnaDURlQdlr+pNu46qy/ko9Wg/jVDjSpYmUSuDi/bGeuE3aP7QIwA U1j7ZuFwfrtxVdkEDSZ0HEDzxzrrcN1mGNSOO5PAcyg32/xGmRfhUi0sHOG62o9hFE0D dz41jHtO+SQQdo/MjFYhJ7B+8eUXf1kdcDtPtVPi7ltQvddL1CkEi9kNd+FwByx3NXAV oCvuih1hN54OVahwdVHkHxRhqI7yaOqyZb3FXjTczPYjfZpm603uRWehuyR+NQk9bQ+C Rx/w== X-Gm-Message-State: AFqh2kowMyt7+wOJGDhaAB1G9SKevVdjArGhNxE3AQQ3ijcws5OyJOxX 7RWzs5bqtX3wRipd1i6ckQc29wLNhRii051n X-Google-Smtp-Source: AMrXdXvHa5oMLiRqrgs1hoBvluFfuwCvzrdWrc3ir7U4yGxCVtF2JURIZlvf6KyaEAhuydOl6WsN0A== X-Received: by 2002:a05:622a:2285:b0:3ab:a047:58ee with SMTP id ay5-20020a05622a228500b003aba04758eemr39246443qtb.25.1672966943266; Thu, 05 Jan 2023 17:02:23 -0800 (PST) Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com. [209.85.219.50]) by smtp.gmail.com with ESMTPSA id i7-20020a05622a08c700b00343057845f7sm22587808qte.20.2023.01.05.17.02.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Jan 2023 17:02:22 -0800 (PST) Received: by mail-qv1-f50.google.com with SMTP id t7so114532qvv.3 for ; Thu, 05 Jan 2023 17:02:21 -0800 (PST) X-Received: by 2002:a05:6214:1185:b0:4c6:608c:6b2c with SMTP id t5-20020a056214118500b004c6608c6b2cmr2487246qvv.130.1672966941474; Thu, 05 Jan 2023 17:02:21 -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 17:02:05 -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-Server: rspam07 X-Rspamd-Queue-Id: 9B49240008 X-Rspam-User: X-Stat-Signature: gybtd39e4tgwjjpqpcy1gqwqn8m5yd4a X-HE-Tag: 1672966944-359082 X-HE-Meta: U2FsdGVkX1/uwaOGl2yBe8MG9IImxgD00v+mXrswKZbSzZJ4OSQWYesPRYPv5Az7xtXLJjenHxav5sZfAJio/W2wjwEg5ls8/MhbrgHGQt9b1FIeFFp4Kn79RNm3oAr4CRrm6Z4aWe2qqAemWgSQa0ZsSeNCP4pRFVPplJq8qgiFirLTXDmHsphqO26hBjAVkjNw9Y1uQdsVNQAZf8hz41p5bJDxjc5KTLzO8fdFnfz4k+0jx/4VirbHSLEGN8s8W6lRufiFPPoZmlbNChhecD7lSwMlcXeTsKODkXdJlBD3wvpLuPMlKH0cSX0ccdTkl6BkVDX/MLarRXiCXLwA6LMYLZdt52Iczq39Ls/+/MSeeRglQyEZnuySeo29yq7P6p5edy5V1bG6NqoSgVyMRaK+IvJKCWlvtftKQZ2unSaeet7aeltpSx9TNeRX0WNNLqVKGqMtHmC9V2EL3d7OgXot5H0D3pj/iSMXY6XWs0BsmzV+BK+EBcbG0xlNubhNWlRIBmFq5PFX4E5iFEXd1h8bUsgjP/Ous9cTtkiACvmum9paNN0k+svapx/L9UIWaCWzqSeFrfUSHLDu+ABVfd7Bwl3o0ZQ7abKhYIwjAquNu5+dQW/37NAh7Z1oxVvmjjK7TRvjc24vnLeFyC4vAMFO/JQ1w19qx0UsPdbo5488y6Jl5GfLoGxz58+qCyCwcYlbV7ID/d8nNnQAvGJWcqkMwdXl/yEZk4dXsK8vf68SuKhQWFaH4Kx7AuaHsadZ+NDbTrHgmduDhIvfVpOtWrA9woPvyeS2F5SXxfk5eo9tfNBnkZTrgPlpwkMhXLDedbFsXu9JXYdRQlho2V/KrhAR2CavsMcYE2ATj3G7rdCiUTAT2ZBzm9Wsj66X9Svi2Sx4lQR5D/9JXfUB69nKKSBhk8UT7rotGNoEmYbQxqT053VmRJkL5zUez6ytAhSsIcMA5lgnWX+ziE6f7os K0n4BAaB bA7RNOSjwxTkeqw9fmLougjm9VZDAJHu3q5/EZ6W89buoeGcgBxBBdv+Hw52NN4G+j1hMfJBK0n+AZf/JOI4v/IL3nF2lm6ChBu1UECsAX4ROx3qQ4NZueK9KgrnPVbs1CUWLihdqLAI6QZ0xP4Lx5sygEvIvzxuFBSwhiFbWhALDKX9DvVkbcuIg5qdxoBmb+gPylGKyxIg6WopPAzxPyB8qqM0ScOBe40QDyzd/fJrf1t6q9EILY7lykKIEsEg6eAuMkPXvaG/XaU9cbilldrwvVssveNCS3S/I2HrPJu8r/vCOiKXQd6Sma6Df5hBUouX0RAjkm7qgYurDYbF5L5unRw== 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 2:57 PM Jason A. Donenfeld wrote: > > On Thu, Jan 05, 2023 at 10:57:48PM +0100, Yann Droneaud wrote: > > > > 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 No. We don't take stupid statements as a motivator. Stop with the histrionics and silly security theater BS. There is *nop* security in "MADV_WIPEONFORK". You claiming that that is "security" is just making you less believable and me ignoring your arguments more. It's a complete make-believe fairy tale. Why would it be "security" to dump random state data? In most situations it's a complete non-issue, and nobody cares. And those situations that want to be extra careful, and are actually generating keys, those situations can do all of this very carefully on their own using existing machinery. If you don't want a core-dump because you have sensitive information, you do "ulimit -c 0". Or you use MADV_DONTDUMP that we've had forever. And you don't want to have wipe-on-fork, because (a) if you want things to be wiped on fork, you just wipe it before the fork (duh!) (b) but more likely, and more relevantly, you want to make *DAMN SURE* you wiped things much earlier than that if you are really security-conscious and just generated a secret key, because you don't want to leak things accidentally other ways. (c) and you can use MADV_DONTFORK to not copy it at all, which again we've had for a long time. And if you don't want to have it written to swap, you're just making sh*t up at that point. First off, it's a purely theoretical thing in the first place. See (b) above. Don't keep those random things around long enough (and untouched enough) to hit the disk. Secondly, anybody who can read swap space can already ptrace you and read things much more easily that way. Thirdly, you can just use mlock, and make sure you never have so much super-sikret stuff pending for long times and in big buffers. Fourth, if your keys are *that* sensitive, and *that* secret, just use /dev/random or getrandom(), because you're not generating that kind of volume of long-term keys, so the whole "I have a huge random buffer that is super-secret" is a complete non-issue. So stop making stupid arguments. The kernel is not supposed to baby-sit programs that do things wrong on purpose, and that are literally trying to do things wrong, and leaving secret stuff around while they do a lot of other things. You guys have literally MADE UP bad examples of so-called "security", and then you use those as arguments for bad coding, and for bad-mouthing kernel developers who just don't happen to believe in that bad model. 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". Linus