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 20B18D2E02D for ; Wed, 23 Oct 2024 09:17:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A39636B007B; Wed, 23 Oct 2024 05:17:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CD656B0082; Wed, 23 Oct 2024 05:17:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 864136B0083; Wed, 23 Oct 2024 05:17:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 68C826B007B for ; Wed, 23 Oct 2024 05:17:20 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 29DCB8029C for ; Wed, 23 Oct 2024 09:17:05 +0000 (UTC) X-FDA: 82704312726.27.AB80AC7 Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf18.hostedemail.com (Postfix) with ESMTP id D47601C0018 for ; Wed, 23 Oct 2024 09:17:10 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="QzO2va6/"; spf=pass (imf18.hostedemail.com: domain of dvyukov@google.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729674961; a=rsa-sha256; cv=none; b=mqrbbuWlXXaqPgpgTpl0a/B03TvjFLrZCzZ5QL7PhrfUfbgHvwwPl493l6Quz8ZHQvpELY EgW/QMXvrawYfLn4fzViIGwkHPmfYMYiQgemjJ/mRTuFzJdvZ07UKH2L67h5b/BXDFGg70 0AlnAGH5yoYpa0ndHavVCNu/IhubGnk= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="QzO2va6/"; spf=pass (imf18.hostedemail.com: domain of dvyukov@google.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729674961; 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=wtB++VIztt5HrzVDtGHAG03WXfiePjTR9YlbhZgm7nk=; b=IelgpuFxbBXFVqtpenCVl5uECgoRY4uz8cCKqL3KocxFPqCkPrXZ2tp0YYoCa+hBd8s6tk QcIQUQalg5LNeVaYZHT4CDzGLHc6YFvUHgvabSPcJQfJokn795UcK+Wovao3XFUzTmXYTz VIqurOP+8WB3I4J9cSO9OM6QoDfJ7zE= Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2fb4ec17f5cso62395971fa.3 for ; Wed, 23 Oct 2024 02:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729675036; x=1730279836; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wtB++VIztt5HrzVDtGHAG03WXfiePjTR9YlbhZgm7nk=; b=QzO2va6/PncnUosDhmrGDP4OKHoodgfO9gszKTpY9KEymAj1XqyPhR8c6BVVQET86u aYGaRX2NVhA3jx5rExmRoSqoZ8IyxDzLsvllUd7HX2h5CUPFvcPLjdrEpAwwHDrDbJ8P PQUx3J9XcC55Nl2wiaIlRUyp9RyZee1KDr1g264CYirDiwNjxp2Yvfefjhkooz31IE6w KOkS4dDEfuESsLSU/W4KTEbEfP9WTWeK6oWRkdiHsNXtFfVSCku8xWT1Ggn/eeLcPNiw cFFnSwfZCObF7IbiyPCkIxNgJAqN+CygJIHO3aXU5RwlG87pBFwZmi6JH+2gAZz4f8FO hIFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729675036; x=1730279836; 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=wtB++VIztt5HrzVDtGHAG03WXfiePjTR9YlbhZgm7nk=; b=FIkXBs44K2VJeyWJQ0DQ6XXrbRiR5yjX9ZTLt9xnfQpGA8bnFuhrg/JOnIWiGWOhg+ sbCRSrY17eyMBsA/FauS9UJAH6LU76NaqbnMC6PZP9Dz+XCDJg6XM1MEloHHPJawqUmJ x4QefTfkxk7BFJUk28j4d+RX18YYASZPeHocv+3QjJwO2KMT5sP2MJkrwWw13ZBroSvD mCXcm+vBjtv3eOGJfS4ZW4e+FYCzSsSXW/B8ZNqBj1FnfBMEkf1uRjLhzdkzEHSCTk+1 nmfZ9GkqJii/Fbbf8kafijkXQfbrUIqbs4Gv05Avj1DAjLfoJHj+FhUY/X8IgwwEPhnm c/xA== X-Forwarded-Encrypted: i=1; AJvYcCWj65o9xwkwX/oWbbAMxfs0HWW+J5+Ewz6DyuDgbr6gIhmxEXjBsBIaojj3zwMb0AUcVU2A8OOoqQ==@kvack.org X-Gm-Message-State: AOJu0YyOWHFlOdZlT8LoW642JdRFJSF+QB+MPL4JrVxLKyGCcEG0LXah 2i/FRueK9WrvcjHeRhKEkXyWsVUoIOp03wAx+xqJ+mksmdyAF7wwPauTHpaJ8MXIxBuPVJfNB72 Zl5pH0e60fCCliAAID3UfkS4xi00WgERpU3pY X-Google-Smtp-Source: AGHT+IFvkPWDLHQT3Gtx5JJGGOJecwZ7B/rbkd7cgrlXZ9fP+lFzPxCiaYSOPYzYujteUjqgXjdomewJxB+DT79mLAc= X-Received: by 2002:a2e:a9a6:0:b0:2fb:565a:d93c with SMTP id 38308e7fff4ca-2fc9d33a85emr9429421fa.1.1729675036276; Wed, 23 Oct 2024 02:17:16 -0700 (PDT) MIME-Version: 1.0 References: <87a5eysmj1.fsf@mid.deneb.enyo.de> <20241023062417.3862170-1-dvyukov@google.com> <8471d7b1-576b-41a6-91fb-1c9baae8c540@redhat.com> <5a3d3bc8-60db-46d0-b689-9aeabcdb8eab@lucifer.local> In-Reply-To: From: Dmitry Vyukov Date: Wed, 23 Oct 2024 11:17:05 +0200 Message-ID: Subject: Re: [PATCH v2 0/5] implement lightweight guard pages To: Vlastimil Babka Cc: Lorenzo Stoakes , David Hildenbrand , fw@deneb.enyo.de, James.Bottomley@hansenpartnership.com, Liam.Howlett@oracle.com, akpm@linux-foundation.org, arnd@arndb.de, brauner@kernel.org, chris@zankel.net, deller@gmx.de, hch@infradead.org, ink@jurassic.park.msu.ru, jannh@google.com, jcmvbkbc@gmail.com, jeffxu@chromium.org, jhubbard@nvidia.com, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-parisc@vger.kernel.org, mattst88@gmail.com, muchun.song@linux.dev, paulmck@kernel.org, richard.henderson@linaro.org, shuah@kernel.org, sidhartha.kumar@oracle.com, surenb@google.com, tsbogend@alpha.franken.de, willy@infradead.org, elver@google.com, Linus Torvalds Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 5yja99so7cwfb7q3irdjsrhakwdgwjsg X-Rspamd-Queue-Id: D47601C0018 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1729675030-456130 X-HE-Meta: U2FsdGVkX19UfioOT9vcCPEHTNgpV/XNsHnWXVLnXg5Kj7ri8CNVpla0baNkig03JSHjqXi9EP01D5/pF/1LKaw4HBSDuXGKK+duyVQSamDAhl+w5e5rlItOu8qcq9Lrf2TcvZguoVdXipIzFP+7uXDOjZS55bXwx6tC1Msrd6xaw+FnFGwlU20rrVxlTvMytem0MIAf+BgYNiHJTRKrApI4joWKvrm/boo28zr9VLIf+sKHKO7ZU6I1VyK6/DBf1wvexzNEFr+qKnYHTOsDTHfNRlcN+VQChIdJpCuH5MyDswBY3MD/G26JoKSSrQhU8cu2ARVGUyYW2UW4Q6BHg2xTS5h61uyShTLLhWUI6CUSI0eyxRfKNda/AbMNly0qhKG3Fcu7DwHRVyIf1+EZARvZt4n3P6w11lKaj03RSEpBKDHOMTc0xlFQXH1w9S+b8LhUcd9i5cToBKrXKqW6BczNT/7+ofzX4bl2ojs5Cfmsu80NzKW9C5TejZPRlRrUUzTfsFPlFH6Ed7PwPUspg1yvAlmF3BAvpnjNJt0NQI74J0POCbqnfWtzvo6vOKNX2+K+4IW0xb1xij+l8bZ4UlNiDwc4wP3c2/clo3dl2HP9zDjjYehGznhcuCZbKC8CtgE6sJMxkxxbck5u4hpyE69OFivBPww1+ZLcrSpi9bgxxzIRlyE0mTzAnq48zdhsAmypMkgeap9JATZjY5vfUMDx7mWzYKqbDe/O51TrkVjH7iFXdOayizBrUZK5ip0mr8jB2FuXIA3PSw13uZZiDT82dq+kxhHmkgeIGMJgk4D4Z+3Ahq8KeNybQpqUjhuezSn07ZJc0/4hP2BT4P/auLVLjpj7k2Us3dH0+zjmxCmMdcigUHuqEiqVzuUYktKY5DcTzPJjVrsnA6qK1KVX+TdEzKsm6KwREx+Dyx60eZs73PYVRInYo+JTI2jt0Yjhxtd9p5BUjNQzXg+7qKd vwEJpn25 +Qvi7OjiwNAMWeyPM3PCOEHqd9yqU9X4npYDyJnKMVwXt55Fm/A8qG5EY7N0YrCGOFZW7YJYEIaQP1QZnbi981vys7pJOOsnduZUC9JS1q4XJ9t3OoYaKcHu90pcTEquXztKxGFWgoNKTkDzC3Yiu09Ln8zjophw/COUoLxRQzWWLqvY4AGiD0SrAmU8QhEfOADpH X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 Wed, 23 Oct 2024 at 11:06, Vlastimil Babka wrote: > > On 10/23/24 10:56, Dmitry Vyukov wrote: > >> > >> Overall while I sympathise with this, it feels dangerous and a pretty major > >> change, because there'll be something somewhere that will break because it > >> expects faults to be swallowed that we no longer do swallow. > >> > >> So I'd say it'd be something we should defer, but of course it's a highly > >> user-facing change so how easy that would be I don't know. > >> > >> But I definitely don't think a 'introduce the ability to do cheap PROT_NONE > >> guards' series is the place to also fundmentally change how user access > >> page faults are handled within the kernel :) > > > > Will delivering signals on kernel access be a backwards compatible > > change? Or will we need a different API? MADV_GUARD_POISON_KERNEL? > > It's just somewhat painful to detect/update all userspace if we add > > this feature in future. Can we say signal delivery on kernel accesses > > is unspecified? > > Would adding signal delivery to guard PTEs only help enough the ASAN etc > usecase? Wouldn't it be instead possible to add some prctl to opt-in the > whole ASANized process to deliver all existing segfaults as signals instead > of -EFAULT ? ASAN per se does not need this (it does not use page protection). However, if you mean bug detection tools in general, then, yes, that's what I had in mind. There are also things like stack guard pages in libc that would benefit from that as well. But I observed that some libraries intentionally use EFAULT to probe for memory readability, i.e. use some cheap syscall to probe memory before reading it. So changing behavior globally may not work.