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 E5D7AC02180 for ; Mon, 13 Jan 2025 21:27:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 789E86B0092; Mon, 13 Jan 2025 16:27:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 73A336B0093; Mon, 13 Jan 2025 16:27:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 601C16B0095; Mon, 13 Jan 2025 16:27:14 -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 424756B0092 for ; Mon, 13 Jan 2025 16:27:14 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F1D07A036C for ; Mon, 13 Jan 2025 21:27:13 +0000 (UTC) X-FDA: 83003714346.09.B60E091 Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) by imf18.hostedemail.com (Postfix) with ESMTP id 114861C0008 for ; Mon, 13 Jan 2025 21:27:11 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="hXfW/5AU"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf18.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.170 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736803632; 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=nX7paUWVQzYOHdolBm2Ggf1i9fxv9lpnxlA6gAwDKu4=; b=k5NHcNqYFde8Xk2S2PFjpJD7EJbXGf/Wf4lv5wN9BX37gGuVnXI60S917YMSVixkUjyrX2 F1XESLI/LJJXEaTZaJoQmfSWMeVR4C2Dr/i2TD0iyTXw2LutviyPp97KF6ptu/Xaxh7oAF 4MkzoUxBFVJq0kAPVnBfEvY+UfLra2s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736803632; a=rsa-sha256; cv=none; b=Bhz2Jaq8Xmvxx9vSSk2n5mhNIzVC80St8tqJ24/cfsPvSaJ92uiVqqHMaKUNnFZglLYaEy deGeVYrp9iErrWcE2s4zZz040FG4GW8BycKNHqSExjJRYCauj1HlBN1PM/XlQEs6Dz3aNZ DcbMSWxdfWvFoAmFXKA2rTzZKG6HfXQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="hXfW/5AU"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf18.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.170 as permitted sender) smtp.mailfrom=jeffxu@chromium.org Received: by mail-oi1-f170.google.com with SMTP id 5614622812f47-3eba783ec88so491091b6e.3 for ; Mon, 13 Jan 2025 13:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1736803631; x=1737408431; 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=nX7paUWVQzYOHdolBm2Ggf1i9fxv9lpnxlA6gAwDKu4=; b=hXfW/5AU9VsV05aeCzunjhkWfydCqs3OtaY7lEaRyUXgwAc/B0QjjrAqSnjOpqBIRF jzWwE2f5lFN1Bra70tx8TtkMkyavLhmP6MkBNq0Xdc6XeWvqobyayhfJ8NSTh12y6aVE vDh2tpHMcTOl5vZQMcu9O8mQhwlqutSnW2Scc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736803631; x=1737408431; 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=nX7paUWVQzYOHdolBm2Ggf1i9fxv9lpnxlA6gAwDKu4=; b=O6N+m0jd4MFkCDDXOFUHHK94pAknfe9IQa3xfcaixEPgmJKnwnLl0N0VN7uz55gXpF WULo4y2Ze/Mtvp8LnamOFveUnLN/wsPqLOn9yNJuAEgDrnRVGnRhPn/5KxeQuWpei1IE QUpVYUv7Q8ei9rvGMrIVy2SwHSc1Mga9q50smW9rZzg3fjloAhbtIRzHsmKLbfAQjYHZ yR41XVbJLgLq7REslPgQGHjaRWNTLryFYBafLm0QBSfCLorU5FuZQXoYx12ssc+oVcv/ RqNeoFijNaSXWMbT6RAstB1G/tdrfxx2PwJuiIIPAxIO3frW1Z4JsGY/9CzAxrTbxcfd urxw== X-Forwarded-Encrypted: i=1; AJvYcCVbi+tSWrFAp61f6dqdq5lzvJcrxITd7wKKgY0C2pabTJFjbo5PwwP9E5cm9RbIxJVwP26kbCMAIg==@kvack.org X-Gm-Message-State: AOJu0YyLunqc7cKShyR/kJOD1G/qUPWHeq/ul4kJdbyAjD/9jcNv7Mp3 MOXINRVYYkvwrN9YRm4Y08ppTvmtRO18/+YhPpYirHlIedsVtBRe+rkyudEeNhL8PwulnBUks8M pufiL3Fo0BNU+wJjGIbS4iw3qw2yiX7S3cn6Z X-Gm-Gg: ASbGncvtfX9iPH6umHrLNPSAXsdBrk2BPB9OSEziQi1o8lzpxBV0bWmybrR54eepu0H 0+jcmQyST5ufQVtDJ//I7W49pRjzfNRqNrGOCimBezQM7dguVEarnjfc5hnPXsRGtu7s= X-Google-Smtp-Source: AGHT+IFn6qaJ4GZTnnEzK3QHkIiNlV0r0kHgV7xdebKFhv3DtFqpeHH69/5MdaV30LdCYF0hZOEJSRqzSIS/U00SX90= X-Received: by 2002:a05:6870:ad89:b0:29e:55b8:3865 with SMTP id 586e51a60fabf-2aa066960c8mr4328842fac.5.1736803630761; Mon, 13 Jan 2025 13:27:10 -0800 (PST) MIME-Version: 1.0 References: <20241125202021.3684919-1-jeffxu@google.com> <20241125202021.3684919-2-jeffxu@google.com> <202412171248.409B10D@keescook> <202501061647.6C8F34CB1A@keescook> In-Reply-To: <202501061647.6C8F34CB1A@keescook> From: Jeff Xu Date: Mon, 13 Jan 2025 13:26:59 -0800 X-Gm-Features: AbW1kvaCvgUnDTBFFtklwcjCd_tLy64QyQ-5neuhPbLqhT9OYgtbrHnzBNQ5NvQ Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: Kees Cook Cc: Lorenzo Stoakes , akpm@linux-foundation.org, jannh@google.com, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, oleg@redhat.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org, adobriyan@gmail.com, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, hch@lst.de, peterx@redhat.com, hca@linux.ibm.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, Liam.Howlett@oracle.com, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au, Vlastimil Babka , Andrei Vagin , Dmitry Safonov <0x7f454c46@gmail.com>, Mike Rapoport , Alexander Mikhalitsyn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: f4ynjeam85om543kd3m4qm596uk7dkxq X-Rspamd-Queue-Id: 114861C0008 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1736803631-475145 X-HE-Meta: U2FsdGVkX18bEJj5t9UciHE5c9h3oHhbzkBu6/VyEhF0+w7rPWjcpgn346+szoJH7a0VRb2ECtBIK8OweCHRy6PyS2F25JGCKIFV6/TYtYy5Dm7LJwvkdMErgDRpWGKQrsLBwhwxtMB/ttpxjHvkMbTxUmXNa11leLMjH7nyIkLSxxVoQRv/fFURW3ph10PaFm9aS/c0Zefb6ITaF5subKqj7HcsTAGcpKzQlkQgw/Wor4KoDEwK40hOR+jUbE6hpmPqpJBPCCr5nfKhwXB9VQXaM6B9bWlrh2Ewhyqt3l3PpCrhBVV2H9vNAQ2YxtLpBuTlRN56/KCBIfut/8pyOM6IPJqq2P+9ge1zEq/X4/LuOnArHlogJX3dwE28scF/xtFNGcjmtCCYAWw0UDTI4bMqvLQ+s52ILCe4f8/8hymxAlykNGW8F7U59BYkpTQo9AXM3ZaofxTa1YEqVzpyhqfOc5N0LU7xTfCrcYCebqfUGfS4TE/JAML1ARIhOq/iPq3iLe5EATPAkyW/AxM2x4eEqZmFk6VpCr/W/YcTA1wD/CdpqOwCLsYnx75vCCdqM+YBvgj18c3IWwVnxbYuHtBT4xVOETt/zkpz4Rt7gj5y25hfX6k/i4cJe2qUM3/RKLK94qm9pwBIUqMhRBPxxN7/perb4JHcd3nH/G6HOmDK5g76+M2ZoDS8z/hthxuX4Wu76YjqKyszrDt4wXteVx/2J/U1EvDtxZ9JMmH34HON6/7uTYF7P4MxmO5Elxbv9S/khxHefLHrQ92UCgFlT3QAhC1OFCuhEV6qZriiS1n9wf6keWTV6GKKWfKNCixgxPG0Ipo73agu/ETUAUed+xlWVJ4TG4aPVdJ0FY1t9WY4rEzhKBnihwfCJX94DIvJ5VQuZgsWQfx/C+nFa0fyN2vHW1DQhaWZQ+Gnfy98HZ8hxjsHdwzOTdoM1uN4VDNFe1HoE8GSKplNlmzrJ7X wKqY7Cfb Fx9YnVCPC9PIzj0KzOHM2ahvW68ULesQPQEqj3oeGc5QCfA9mvcLnvqoZToQHFSJnHqcJaLgJTda1uYdm+ppLmlMswoq9P0hUVPa5gbbygrUrjF3VRUs3tbOljmmMtId0zFyMqQAb0CgfBZ36UbqKUwt3LeOcSzC/+Lls5NRzbI/vMpsnte5Cm5H2hHo2Ch59Ark/pHhOLh/CmtCHB/z/OnLh91NVKmliJVD7U6leaAxr4eowDeC6VM0d3IW92Toib4JCpYYzz+B2kmNj3I/WlFsCwvGDyVt1xp+ARGTtjFx88zWksxKtx+1Tzp+drYC2vHbI X-Bogosity: Ham, tests=bogofilter, spamicity=0.000237, 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 Mon, Jan 6, 2025 at 5:12=E2=80=AFPM Kees Cook wrote: > > On Fri, Jan 03, 2025 at 09:38:10PM +0000, Lorenzo Stoakes wrote: > > On Tue, Dec 17, 2024 at 02:18:53PM -0800, Kees Cook wrote: > > > On Mon, Nov 25, 2024 at 08:20:21PM +0000, jeffxu@chromium.org wrote: > > > > Seal vdso, vvar, sigpage, uprobes and vsyscall. > > > > > > > > Those mappings are readonly or executable only, sealing can protect > > > > them from ever changing or unmapped during the life time of the pro= cess. > > > > For complete descriptions of memory sealing, please see mseal.rst [= 1]. > > > > > > > > System mappings such as vdso, vvar, and sigpage (for arm) are > > > > generated by the kernel during program initialization, and are > > > > sealed after creation. > > > > [...] > > > > > > > > + exec.seal_system_mappings =3D [KNL] > > > > + Format: { no | yes } > > > > + Seal system mappings: vdso, vvar, sigpage, vsysca= ll, > > > > + uprobe. > > > > + - 'no': do not seal system mappings. > > > > + - 'yes': seal system mappings. > > > > + This overrides CONFIG_SEAL_SYSTEM_MAPPINGS=3D(y/n= ) > > > > + If not specified or invalid, default is the value= set by > > > > + CONFIG_SEAL_SYSTEM_MAPPINGS. > > > > + This option has no effect if CONFIG_64BIT=3Dn > > > > > > I know there is a v5 coming, but I wanted to give my thoughts to help > > > shape it based on the current discussion threads. > > > > > > The callers of _install_special_mapping() cover what is mentioned her= e. > > > The vdso is very common (arm, arm64, csky, hexagon, loongarch, mips, > > > parisc, powerpc, riscv, s390, sh, sparc, x86, um). For those with vds= o, > > > some also have vvar (arm, arm64, loongarch, mips, powerpc, riscv, s39= 0, > > > sparc, x86). After that, I see a few extra things, in addition to > > > sigpage and uprobes as mentioned already in the patch: > > > > > > arm sigpage > > > arm64 compat vectors (what is this for arm?) > > > arm64 compat sigreturn (what is this for arm?) > > > nios2 kuser helpers > > > uprobes > > > > OK let's not get ahead of ourselves :) > > > > VDSOs/gate VMAs are treated quite differently by different arches. So w= e > > have to tread _very_ carefully here. > > > > I believe PPC doe some 'tricky' things and may actually want to unmap, = for > > instance. > > > > The problem with this kind of change is we're doing something fundament= al > > that impacts _every possible combinatorial combination of configs, arch= es, > > and use cases_ for each of these which we seeming - just assume - will = have > > no issue with this. > > > > This is insufficient, deeply. We need: > > > > 1. Strong justification (hand waving won't suffice). > > 2. Very extensive testing and checking, and _proof_ of this testing bei= ng > > performed. > > 3. Buy-in from arch maintainers. > > > > So far this series has provided none of those. This is why I am cautiou= s > > and pushing back here. > > Sure, I agree. This is why I was suggested the ...ARCH_HAS... Kconfig. > That will provide the way for 3) to happen. 1) just needs a little more > details in the commit log, I guess? The goal is attack surface reduction > in userspace, and remapping shenanigans have become a recent avenue of > attack. > > For 2) there are limits. As you say we may have "every possible > combinatorial combination", which may not be feasible to test. But > making it available for the common cases (and of course testing those) > makes sense. > > > And I absolutely will not accept a user being able to turn on a switch = in a > > known-broken configuration. This is absolutely unacceptable. > > Sure, of course. > > > It's equally unacceptable for a user to enable a feature that is > > untested/confirmed on an architecture. > > Agreed. > > > So let's be careful about Linus's edict here - the operative part being= 'if > > it doesn't break things'. > > Right -- I should clarify: I don't mean to say "it should be enabled by > default", I meant to say that we have a common pattern for making these > kinds of features available without hiding them behind a build-time > Kconfig that would have put the features out of reach for system owners > that only use distro kernels, etc. I was pushing back on an earlier > comment that I interpreted as rejecting boot params. A boot param (when > other aspects of the system are sane) is needed for this kind of thing, > and is the pattern we use for providing optional features that distros > can make available without enabling them by default. > > > > So, if we want to have a CONFIG_MSEAL_SYSTEM_MAPPINGS at all, it shou= ld > > > be "default y" since we have the ...ARCH_HAS... config already, and t= hen > > > add a CONFIG_MSEAL_SYSTEM_MAPPINGS_DEFAULT that is off by default (si= nce > > > we expect there may be userspace impact) and tie _that_ to the kernel > > > command-line so that end users can use it, or system builders can ena= ble > > > CONFIG_MSEAL_SYSTEM_MAPPINGS_DEFAULT. > > > > Again, I hate to push on this, but I am simply not going to allow users= to > > enable features we know break things. > > > > Users might not be aware this feature is broken for CRIU, and X, and Y = and > > whatever else we've not thought about and enable it thinking it helps > > security, and end up with a broken system. > > This will never be a bright line, and I think choice is more important. > For example, Ubuntu builds with CRIU, but only a tiny set of tools > actually use it. (I've actually been considering adding a boot param to > disable CRIU features since they undermine some aspects of userspace > security.) > > Regardless, yes, if we can make this work with CRIU (which I thought > there seem to be consensus on), let's do it. > > > This seems like putting the onus on CRIU users to deal with a known-bro= ken > > thing? That seems really unreasonable? And people would just have to ha= ve > > the right userland code to work in the kernel with mseal? > > > > Yeah I oppose entirely this unless I'm missing something? > > Hm, well, the primary goal is for Chrome OS and Android to use this. If > there is honestly no path forward with CRIU, then hard Kconfig conflict > it is. I'd much rather have it available for anyone who wants it, just > like we do with lots of other features. Why force people who want this > and not CRIU to build their own kernels? We have all kinds of boot params > that if you set you get a broken system. > This patch is intended for ChromeOS and Android and is feature-complete from their perspective. To simplify v5, I propose removing kernel-cmd-line and avoiding the complexities of CRIU/UML and gVisor. The KCONFIG is disabled by default and will only apply to ARM and Intel architectures. Later when a generic distribution wants to enable this feature, we can work out a solution to handle those complexities. Is this a reasonable path to move forward ? Thanks -Jeff > -Kees > > -- > Kees Cook