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 35FCFC61DB3 for ; Fri, 6 Jan 2023 20:54:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9263D8E0002; Fri, 6 Jan 2023 15:54:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FDB78E0001; Fri, 6 Jan 2023 15:54:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79E018E0002; Fri, 6 Jan 2023 15:54:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 66B5A8E0001 for ; Fri, 6 Jan 2023 15:54:10 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 12831AB5A4 for ; Fri, 6 Jan 2023 20:54:10 +0000 (UTC) X-FDA: 80325576660.25.B4B5277 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf22.hostedemail.com (Postfix) with ESMTP id 0ADD4C000E for ; Fri, 6 Jan 2023 20:54:06 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mHfJQe+g; spf=pass (imf22.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673038447; 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=Hx90KHhU8bhVZYyJdD0xUhBrODJv6CQBI4Q/rYgClzA=; b=0K68MV+R8TipDCT9FFKMXsqZhofUcpN7KelqcKyH40rx8XC3t+n5+iNTlVcDGT0Cx5+ubb IjoHMc5ftMkqKB9quq/TQINxXvGjmre5t1dWN3oKVEt0KHjs/Ct3pydCGJpEpeJ9K8a57d p9I60LlyhaGVOxkocnRW9pBkmh4c0hA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mHfJQe+g; spf=pass (imf22.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673038447; a=rsa-sha256; cv=none; b=29maBqtAZbcrRSWGUy6mlUxqNEzNr2tkKy2kL1tbzlVDuN4J8oSV4WwBH9amkqhautQFZX 4iLHtPSJLqyWwDohP8tTNv2HvjoASq7Pe/lE5wXRNd+MgVcWZwUkPFP0ZU1kxq0w+kIK8q 2WCr5IGcwkE9+2BE0H8z2I45pimf1/M= 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 519BCB81E86; Fri, 6 Jan 2023 20:54:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9744FC433F0; Fri, 6 Jan 2023 20:54:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673038444; bh=2XFVyFO90sv15IXbHfuoR96vEeg0uVA9f6scATbkw5I=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=mHfJQe+ghzVdgZxSVelgm1jSG5vA5KgBsk91CsnOdE6+vYEnKP07FXxBqc+wIWjNc /ney0ntA5oVoXHpljLmbG/ptlT/69CqOGDRiBfs67lVR/GpQtfA4SFKxt6Hqv2BrBx /Zil7U7xTEbnwogsadNwFzIvOXp6M8oDMMmGpSRt/t2pBweXijPjNQBXjJ4Hz0fpTX qSPyHb2Bu6mdIo6QJC/HJCYTeL5tzoccdmge+vm1oc6K4rSnBht9HhRe3PbU0FE3ZW aP0OkfFtzOACThVhMDHKsjFKc34/bLpq9aJjwF+moBB4D8aQh33Cwmke0C/NvktWH2 FqeZFd7BC2/Uw== Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 798D327C0054; Fri, 6 Jan 2023 15:54:02 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute3.internal (MEProxy); Fri, 06 Jan 2023 15:54:02 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrkedtgddugedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepvdfhuedvtdfhudffhfekkefftefghfeltdelgeffteehueegjeff udehgfetiefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id AC89E31A03FD; Fri, 6 Jan 2023 15:54:01 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20230101162910.710293-3-Jason@zx2c4.com> <10302240-51ec-0854-2c86-16752d67a9be@opteya.com> Date: Fri, 06 Jan 2023 12:53:41 -0800 From: "Andy Lutomirski" To: "Linus Torvalds" , "Jason A. Donenfeld" Cc: "Yann Droneaud" , "Ingo Molnar" , "Linux Kernel Mailing List" , patches@lists.linux.dev, "Thomas Gleixner" , "Linux Crypto Mailing List" , "Linux API" , "the arch/x86 maintainers" , "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 Content-Type: text/plain X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0ADD4C000E X-Rspam-User: X-Stat-Signature: dmomurmts1p6iq733f39ti9qkgoeh37e X-HE-Tag: 1673038446-433972 X-HE-Meta: U2FsdGVkX1+PFBzDh8FLxXeNmDgbebsZZ4tQyJm1e18ROtsxdjxcfjZkUezwoTO9Sq2wLxQ0yRZVUmNLSljhh8pAd7+gWTwx3DB3grE0Z6Dyr8rjLGfeHlJPnrFBc0oKHGMXOx/Xfc1PhinOsc8aqJ0D638hCXaDsocjOaLAWaKPVJCMvXPqyCsdGbJCeHbc6k+G/AME7VMytB3v5nZi7Jw7ZbHgzK7IhHYHlLr+PXfIjA7oNJ5yS8wKTH9hgEgYxoxGSAXGEggAP7Ul98D3v3MuxG06Cp6GK4MdY99csrN8KtHLvfJQdqx/QKaWVM0gt07D0VRcFrwwAEZFjhUS9VgY7kvzt/BJdJVx2v/Zh5wxwc6ayEyk8VcIZtyqsIeqmYOm/YtGjAGcDQ30ob3bCWmY08IaaZKiZevLI0+YH9T8qliF1Q0dQsMJx/e1ayXzD+pHbeuCWtwy5FUJmZilrDyTB6Sl2JJrHRKfaxVg6Aa3UWRoHiCatSnj2WuV275bZjptk7i1h5ELEhawC2EbAKAkkMuD0BtUT44uEsIo5xvhB4lnTgfS6SHs1txwaBUVUmn3EccWD1vtcta9XMXxS+AGF2SeD64oIVBIH06chsTalgARMHYSTWTIoxU5RNH6VcS51mwB54MKswwLhUXuqZJi1JA+3FLRre2v2EVe+EIQvZX0217mxDbDLYut7ciMcSfBrJPRXynmdjOi8VolnXIZTOjKnL7wc+VwmmDHzonYZkez4/cVEeE5H1B1hQFqMXi+Iu7E8N1q7XyAOIIgjhoNSjg1Pq6C/AUG2P2U1vXz2JKWCjk0L5Jlm5fqpVTHEF/EJZEoAmWkzNa02kq8vKijHgbQLhxPPwcfM3WO2KPip+YG8FASMljvy6kIU66LjVmYbtcB6uVv8O1coWMFvt9Wrcu+qbsChHjRsSpM5G3pVxxWZFYx+zwab6CeglyTsdrBc6M4WI4NqcnLLFQ iSg2tUtg zhqwCiZrZL4tueOLSMGVdQjxByjaeJWTHzglT536ENrKO/9TowUJxaVYobsfUZqaks+sdi1Kru7TWqcwRRWGz0oPaKjW+8tAzA9XheuMAXQU7I+I= 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 6:08 PM, Linus Torvalds wrote: > 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". I'm going to suggest a very very different approach: fix secret storage in memory for real. That is, don't lock "super secret sensitive stuff" into memory, and don't wipe it either. *Encrypt* it. This boils down to implementing proper encrypted swap support, which is not conceptually that difficult. The kernel already has identifiers (mapping, offset, etc) for every page in swap and already stores some metadata. Using that as part of a cryptographic operation seems conceptually fairly straightforward. And a nice implementation of this could be on by default, and the kernel could even tell userspace that it's on, and then userspace could just stop worrying about this particular issue.