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 4E004D3C530 for ; Thu, 17 Oct 2024 20:35:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 93C6C6B007B; Thu, 17 Oct 2024 16:35:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9131A6B0082; Thu, 17 Oct 2024 16:35:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 801AD6B0083; Thu, 17 Oct 2024 16:35:09 -0400 (EDT) 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 621366B007B for ; Thu, 17 Oct 2024 16:35:09 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C31461A150B for ; Thu, 17 Oct 2024 20:34:48 +0000 (UTC) X-FDA: 82684248234.07.0108BF4 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by imf25.hostedemail.com (Postfix) with ESMTP id 0FABCA0029 for ; Thu, 17 Oct 2024 20:34:59 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="Vzrm/yrj"; spf=pass (imf25.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.128.46 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729197259; 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=8dlsU4BSgea+jQl1c4v/WF9/raVOBoEHI3bZllwES5A=; b=JpIM6ILdp/6RcbMunoCH4q7yRuHI3q8Q6LyxGl0YHMeO1B1ygsi50sehASieOBCidNEN8U sMqz9UNYmDXNdkn8O2TPQAMBIC46Xb8l8W1pbmLIVhuC7kdQL9A2yDph8F8TJK8jFSqono SnWk7O+anG2BoGxw55hMnA89pJK1AE8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="Vzrm/yrj"; spf=pass (imf25.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.128.46 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729197259; a=rsa-sha256; cv=none; b=KjuAumrfrOW+TNbJOF7paitDhvoH//vvkIwR8Xd6YD8ob9jjr4pfaj0t+Hd1lAxPvYwhYF rgd9xeXGQewvNeEVoATK1Pr5YwIl+tgkpKvItQYH8tOh40bztW5B2Xqd141oQifHiTrihG J7rXef+dsQZIqB2y2nFhiI3hPH0y2r8= Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-43155a6c3a6so1655675e9.1 for ; Thu, 17 Oct 2024 13:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1729197305; x=1729802105; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8dlsU4BSgea+jQl1c4v/WF9/raVOBoEHI3bZllwES5A=; b=Vzrm/yrjSP0J3Q9XAdwrucaqwYwEa0Wi/V6qsGyRayyDQg7jWXQszjQ+wdZ1Wx6dCq FW7VRKzru7tPn3aKX7QThRnIWhhUDJLqiWubDb/94tOGCw8rKhNdVyK8Vv8OKEcjMKl1 RHBb0HhDnGjLmmJEgBBf2eAwhaOKcUANzIj84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729197305; x=1729802105; h=content-transfer-encoding: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=8dlsU4BSgea+jQl1c4v/WF9/raVOBoEHI3bZllwES5A=; b=f7sHQd1eFuevAJoaW9b27cMGdiHlFhgMuCd6olEiA+WA9IxhNcvFkfcCScQzi6oLxY e1RO8vquMTTTTlJYQWNU+zx7XnhbJS4hHHFVIbT6tO5loSijUPTCkaZUeMSTGiGlNDnQ uSAoCgXS5/fKbpVmvZUX92n5WKC7kLrrhK9hMUmHcIKFk1H4AvsVQO7QORhmKpwj9Rmi f0ZKeMV6JdcJLsYWJSn815VHpLue1jq+syvYZrkEiife5jYMn7u2U3jXPPPPL8TwhrYT jG+jnvD7lHK/eoF6GKtUzZhe9FpmkwNvRN12f71jEW7b2+ddvWOB14j+73HNGyYdamr/ BYJw== X-Forwarded-Encrypted: i=1; AJvYcCXEg5wF8izsE63i7xf8j2sqGEZiU+O38lblX3uDMYTuQSbFD1VLrz2Ucu+/pXhwVVZbqtMXECiM7A==@kvack.org X-Gm-Message-State: AOJu0YxpwwAGxL8bfUDeWTW+yZmztxpNiAcZ942yU15YUw1Jxq1IctZj z466AuTPXJVKReDMA2KBP5tab0Cfs4cstKdvd0MtMc0zYwTc0J1mHt3nmASTFlS0X7B+c2qfai0 5nXmE+AVunxkYovoXxBzjRiV3ew/S1pWCk8vj X-Google-Smtp-Source: AGHT+IEnAVG6P37ZI7J79pIs6tetL7SrTTg3vZvZ52j79TfnZhM42LG6dLndso7dEGUcrk8ZVXHBhehUL0AgCVG4AME= X-Received: by 2002:a05:600c:1c0d:b0:42c:ba6c:d9a7 with SMTP id 5b1f17b1804b1-431585e5c5amr17495305e9.4.1729197305529; Thu, 17 Oct 2024 13:35:05 -0700 (PDT) MIME-Version: 1.0 References: <20241017005105.3047458-1-jeffxu@chromium.org> <20241017005105.3047458-2-jeffxu@chromium.org> <5svaztlptf4gs4sp6zyzycwjm2fnpd2xw3oirsls67sq7gq7wv@pwcktbixrzdo> In-Reply-To: <5svaztlptf4gs4sp6zyzycwjm2fnpd2xw3oirsls67sq7gq7wv@pwcktbixrzdo> From: Jeff Xu Date: Thu, 17 Oct 2024 13:34:53 -0700 Message-ID: Subject: Re: [PATCH v1 1/2] mseal: Two fixes for madvise(MADV_DONTNEED) when sealed To: Pedro Falcato Cc: akpm@linux-foundation.org, keescook@chromium.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, corbet@lwn.net, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, jeffxu@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jannh@google.com, sroettger@google.com, linux-hardening@vger.kernel.org, willy@infradead.org, gregkh@linuxfoundation.org, deraadt@openbsd.org, surenb@google.com, merimus@google.com, rdunlap@infradead.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: a3jjncrdbkp3nti5q36gd6hy4abgae3d X-Rspamd-Queue-Id: 0FABCA0029 X-Rspamd-Server: rspam11 X-HE-Tag: 1729197299-13016 X-HE-Meta: U2FsdGVkX1/FSqcZRH8D5KHyr2B6RB6ID3vsDGvwaUXj/YAO8jPFlCR97SHqnmX0PDFZxqasV4lQFpulHW7L9yMB+VNiCkaKYhpjYlpcbNeKhBQU1AfL8wnwGlqCklhGnFSQ9O9+bn34mIXBgsTxHbsGARNzRvDGc84ifzOD7W7lisdcOWNNPjgSoTxIWQchexZMbaizxQwYlPSXvKmTZE1jaR2KRnwLnfKuGOieIulFcnFFPZBo+k4GwGmBxOSvZlsUVm6AN22Qtlb/ANArDoLgmcl8YvuYhuUtBttdvAXlq2FuGzD0Bh/YCHYwOYgrSwWP+3uWjas4gL3vjubC7eJSn2JfCIECpjnClZd5IN4cWiP2u1LPXtwZ9Q9f/JLFihg8ixcv6MncZj/YtqAtHU9jOYONtckr+x5d06PzKVf3YMtr9bE1hhtMDI5A2K42mkgRC07k1xpGMxzK6zYC1LQgn087K4kaiekiCc791490z0cJzconVAqzXT8qSbOJErZSUXDwxNmckFJ5+kNPCSeBwX7ktjRLIGQw0dkcyadVwoobcAMb1Wsvn17PuMV5qQtFNSbyzO3fxE28+l5MXTwST6F+hP+yquI4HyDd06lHrXNxRhObZhxpEA350L5V3mZsKOY2SX5xgff4NAb0IPTlhcguHAiMySIGB5731gHQyIyQXhutbjBXB2IvCp7Pgb53jIagb02kVhExSoTgKE6I4jb/TIKoGVkDXEV/kN3ud7pPNFg4kWC7qc7ISnKVJa7nElZ/vexpXhjE93G4QEDu0Sr6Svqqg8Z2s008wE2GfpFqDVI3pAc7Q6pIgZ6kuVz4XJiGCJ3+MKc8N5XBJi/DAFB0/OQZ32Hn65WwHW79fLS1BsBv3ci96Aih641k8YVZBOdykoplrDcxkJYMl67ufvWQvNTqsXx1vpViDZGtRHOXHgGelySEDH9+ysmyELmgPU1JCFj8VELA39w emscwkWc lR7UQ6NrrMRopimQku3iirg3LXRS/sTKZytHykN2PIxmYw4GQ9ddzBCq/NTSibljtOdflO7jXWTiLoi6CuSf9UnFLKoHNzNZ13jvFVwMuWWUxS/roOlEQB1bD+V1GMpU9u1SfS9w0+YW8jm0ZDZK25IfdmtqCBYil92L4zwB5JzD/df1fS/v1BwPPE4oF5lwzHf+g5EmF5bjBjRzvAhXFGPqUqNcmu1fzBougChadq8Rtq26Xp9OZMJD5K2MMTeli4KrzUAHA/i0KBSVE7s4i82dvPpsWdZB4wKzxrn1K668KvRFJ/wxS0qU8ZUJ7TtAtdZ3EX7lgpU6Y3bwzQTlFccSWpw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001298, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Pedro On Thu, Oct 17, 2024 at 12:37=E2=80=AFPM Pedro Falcato wrote: > > > For PROT_NONE mappings, the previous blocking of > > madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits > > memory access, madvise(MADV_DONTNEED) should be allowed to proceed in > > order to free the page. > > I don't get it. Is there an actual use case for this? > Sealing should not over-blocking API that it can allow to pass without security concern, this is a case in that principle. There is a user case for this as well: to seal NX stack on android, Android uses PROT_NONE/madvise to set up a guide page to prevent stack run over boundary. So we need to let madvise to pass. > > For file-backed, private, read-only memory mappings, we previously did > > not block the madvise(MADV_DONTNEED). This was based on > > the assumption that the memory's content, being file-backed, could be > > retrieved from the file if accessed again. However, this assumption > > failed to consider scenarios where a mapping is initially created as > > read-write, modified, and subsequently changed to read-only. The newly > > introduced VM_WASWRITE flag addresses this oversight. > > We *do not* need this. It's sufficient to just block discard operations o= n read-only > private mappings. I think you meant blocking madvise(MADV_DONTNEED) on all read-only private file-backed mappings. I considered that option, but there is a use case for madvise on those mappings that never get modified. Apps can use that to free up RAM. e.g. Considering read-only .text section, which never gets modified, madvise( MADV_DONTNEED) can free up RAM when memory is in-stress, memory will be reclaimed from a backed-file on next read access. Therefore we can't just block all read-only private file-backed mapping, only those that really need to, such as mapping changed from rw=3D>r (what you described)