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 4B0F7D3C530 for ; Thu, 17 Oct 2024 20:49:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF3916B0082; Thu, 17 Oct 2024 16:49:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA3386B0085; Thu, 17 Oct 2024 16:49:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B696E6B0089; Thu, 17 Oct 2024 16:49:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9A3E46B0082 for ; Thu, 17 Oct 2024 16:49:32 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A08CE1C747A for ; Thu, 17 Oct 2024 20:49:19 +0000 (UTC) X-FDA: 82684284732.15.82B38AC Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf02.hostedemail.com (Postfix) with ESMTP id DA22580012 for ; Thu, 17 Oct 2024 20:49:10 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aPxsUESi; spf=pass (imf02.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729198122; 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=2Q8gmzOdl//bRG3iPJ2MKUkse51Vm7Xefy/9rAvHyEk=; b=jwPryQJ5aqTZGqW6nWbEW1Ojl41Tm0lA5uphX1ColxLt/zNRuBIjyyzNHq522nkZeBYI5G J4U8KTvUHTMqx0sjDFm75XGxqGgyfpgjGSoVidpQeDFBokqL/hfFzOwOuGmh7YONvjJcZu EzqfZgL3RrzSbRD07tgobxSuaDKXRrQ= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aPxsUESi; spf=pass (imf02.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729198122; a=rsa-sha256; cv=none; b=BYlfrK8uV7KhKgC3VblHj5PjphDfb4ePOzdMRA3qtrIy4VHthla33eAFNdpdfNkpuGTEJM Tt68SDCKPsEoce+ciAqoycRNE01Opip2w/HuqPdEgz0CckS7UQYKdEQh2HFaSzv8jS1z4F 3hPno+QUJdbXK2IpuCMLQ/t5sTu9NX8= Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-431548bd1b4so12357645e9.3 for ; Thu, 17 Oct 2024 13:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729198169; x=1729802969; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=2Q8gmzOdl//bRG3iPJ2MKUkse51Vm7Xefy/9rAvHyEk=; b=aPxsUESilpoYGoju0boU13lnH8pBz3aYZQzmMGW+pWck19Q5CHroUfI7TiPA/94LTv TjBcbBfERF4WiM2HrH2AyvmNJqEx/OdE3KPPXiiITtrWmDRbGglU/4J/28FIPDEJHUC+ iC1rnlJwo2/pq5iHjVzUQSIUpQTEaB0CyIR+WGAYSHST++sxGnGCUtC1li/RWVrcNLC3 1tTzIDNaYLrIIXYA0qLR+/pIc4xksOn1QmkXzl/Btar2qGy3JmI5ewCGCIESUtoauKmn 0fpkiTEUUJmmmrieRICO61j3cAnHAgeKdbfZ6VJKRaAE7uW/9TGBjjIw/MXs4DigBDxZ aZIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729198169; x=1729802969; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2Q8gmzOdl//bRG3iPJ2MKUkse51Vm7Xefy/9rAvHyEk=; b=lgF+RkGnNXsg4Gr/OZ/XLrOesB9Heljivz6HzPFOlscZeMuE5rZgnQoh6WAVMTV2kG zMAtQOi85QBpanCbURp3yZE4gU1Hs6hyZPaZlJSANM/lzrvBpYm3RZbL7C8stfIFCwY+ sdwYR5Ah0FMD233OR6aVbkCLyaVeNVmuF0VRf/hFOaHyCn8R9hCnChhdQPsWHo7feUxm pxvXUqbYI0/JzGRdtNPP4UDMOw3pH5by7hVPPXzPMoSZpHAwh9JtGebVh52WtYYrGgqd d7hjUJRkgEMlNQ8+LiKZxft+13uckpbwr6PSlRjIjxQfzEL+l8cqaMOkDDTfTP/droU1 bexg== X-Forwarded-Encrypted: i=1; AJvYcCXqt0iKUnsABtb2Y0H1JVCcMxihxnwiecbnrZThsMpV0Pl+KCewUJFzUwaQCYCyMKBsrNA/mixrCQ==@kvack.org X-Gm-Message-State: AOJu0Yzt1OFoUWSPQSjSvXNs0riOzn7oHXP++by3cV+5rJeqargNRSUi wCYqFOuO+7tvLCf6AaspFJBRE5FV21X7dy+tcvXuDEqQJ61f+JBHtGaMNRgT X-Google-Smtp-Source: AGHT+IFBYwy2F++3ncPm55qG+21ejA1wmCaAToncm0YEYTbr1Tq6m/UqhyTCk5HXpSwCEXGHzwhGHg== X-Received: by 2002:a05:600c:4ed2:b0:426:64a2:5362 with SMTP id 5b1f17b1804b1-4316163b8bbmr109125e9.8.1729198168453; Thu, 17 Oct 2024 13:49:28 -0700 (PDT) Received: from PC-PEDRO-ARCH ([2001:818:e92f:6400:a118:25f3:b27f:9f34]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43160dc9396sm3426395e9.13.2024.10.17.13.49.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Oct 2024 13:49:28 -0700 (PDT) Date: Thu, 17 Oct 2024 21:49:24 +0100 From: Pedro Falcato To: Jeff Xu 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 Subject: Re: [PATCH v1 1/2] mseal: Two fixes for madvise(MADV_DONTNEED) when sealed Message-ID: References: <20241017005105.3047458-1-jeffxu@chromium.org> <20241017005105.3047458-2-jeffxu@chromium.org> <5svaztlptf4gs4sp6zyzycwjm2fnpd2xw3oirsls67sq7gq7wv@pwcktbixrzdo> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Stat-Signature: s6gdzuso8f8ck5fe1asaku6jhcizgzt1 X-Rspamd-Queue-Id: DA22580012 X-Rspamd-Server: rspam11 X-HE-Tag: 1729198150-202103 X-HE-Meta: U2FsdGVkX18TSRExjj3bgblEkbNxpeoTGusp/5gtAhc8uI2OQ2ti5QcLgtGqkXNNfO5GBe6SxE3ahCNFSaKM39wtTGKKuhPPN6+t09WLKXm4W08IILMq0pNA476FmWbz6uQPEF3NkiRgXZE6lJWORMnPWKkL0K9bgTJ74VmUKhZEBE33rfU3qfJYopau5HELL1wIJs1QSWeIvqS3mOcjBvTXHaMLXT4P2vizi8yhvIS7WvpAegBENwegPXjJYq7s4E9bFnArnCNqlabY9dr+AgTs7eaNE4BqNwdL/z3ye2hZOyk9NKmLboCsbx3DH7fEMspPyTp379rgHo2rePfo+7g3YVDX3GlA0DqQEUEdpSotFxXFRly8tM3Nii7ZVuBwZr5feOw4zKba9uVdKz7leOqJXoXpmILAaJc5sKW5mM7+52SDPTPfGkT2JtfjnKgDK7NhVvjauBL3fCDyJxzNbQem+KKWdRJ02M0UfxVkzbqOiIffqMnwVu0P5KpFitSkuMoM0W660VTeWCAlk58Np9Nn9ettd7LRDTgkmAO6cf3todjlJYm8OoA6BZLiCK4XjbNqIJYcyLsfxLlpWc6AT5s7ubW2l+wti0lY5QHiKl/YY8WrUuXUAT2M1ACxyuAd9375cfdYW8ZIg7dNRrPjZxiPYU93/G62SkC3rCLkNQJG2xOofrid6kVOxPjomgQjiFUyjP1wYur68F/Ex6/azrZu51uYF4sOyXCP4kelwAFePa34ZVfD6GY+Luy2ayz/7Azvy+ZrA0YCFvXeTUIvwRfRdRJ+vwbfLEiHqXeyNMiWdaXZps18auTakSV8ozGgNmQaPByU7sbQiAqbo+i2hcZpgQ3aEzKesnXv2cTMCqcO7Gm/r53Z22s+OE2s2ivaL8ovt+V5Jps26VLg8BfDchg7JdjiSL6bAb8LcspnfWc8S4ne1EZMh8NFPUrl4B6e6m4HvXhE5Ct/p2N3h5S UyQsVvvk S4kmM6G4UXE1dpyOw1uYgJr/8FDhTtSLwEs3QFtiP0xmS2blC25WuG71fol6nfmn3q9cIilr1cJp3U8YXkDEzA3Y1ERpHeb1rUg034MzR1JE6Do+sgCoviS7iOvVP9YsKsTVoCQPeq1eoKEa5EPMAngZTdvDvj1EvDc1+J5Vjyu1Cmc8wOrsdl7gYP60P0A58iNGYrOfZ0fUV17+3k22lx8mh6Uxw00zcZzS9oP4EUyZXdu0rARtKtpz4ZQnYHDkL0ZpTjHz8gCYQAf74dAIT7QlKe49h1h5PZmn6gfpXw/c0SdBykGxFgyR1kPDcs6ZWN5t+GUlN/prGbMgoPuZ9YKAtqKig5nj1SzdHYkwLt6saFA1ktsouHHIIMHJ2HscuMnCcZz8RXezpO5aYlCP0YCPjLb9OMm6ZE/QHz4UVXmOXiaL3bXh3+F+H1jO+DVSYWxXIklF9DKkXvPUX9sLsxHa1CAW48d/3WUMPjAXEcZBb6JILH6INr2yqkFS9S8/kb8DGhS3vA1NSX6IgUeOuB3gGAQ== 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: List-Subscribe: List-Unsubscribe: On Thu, Oct 17, 2024 at 01:34:53PM -0700, Jeff Xu wrote: > Hi Pedro > > On Thu, Oct 17, 2024 at 12:37 PM 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. Well, making the interface simple is also important. OpenBSD's mimmutable() doesn't do any of this and it Just Works(tm)... > > 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. And you need to MADV_DONTNEED this guard page? > > > > 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 on 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=>r (what you described) Does anyone actually do this? If so, why? WHYYYY? The kernel's page reclaim logic should be perfectly cromulent. Please don't do this. MADV_DONTNEED will also not free any pages if those are shared (rather they'll just be unmapped). If we really need to do this, I'd maybe suggest walking through page tables, looking for anon ptes or swap ptes (maybe inside the actual zap code?). But I would really prefer if we didn't need to do this. -- Pedro