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 D221EE77188 for ; Tue, 7 Jan 2025 01:12:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C4C26B009B; Mon, 6 Jan 2025 20:12:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 474F46B00C1; Mon, 6 Jan 2025 20:12:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33C086B00C9; Mon, 6 Jan 2025 20:12:53 -0500 (EST) 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 157AE6B009B for ; Mon, 6 Jan 2025 20:12:53 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C19AB805D8 for ; Tue, 7 Jan 2025 01:12:52 +0000 (UTC) X-FDA: 82978881384.06.66C7D03 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 137DE40008 for ; Tue, 7 Jan 2025 01:12:50 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Sg+/UsdM"; spf=pass (imf07.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736212371; 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=I/n/WOTB/tJLrnjEXoSLViUWJwl8B/Ds2gEX3pFScXg=; b=1M/smWt7O9Is52LsCPTWsQtwXlFM65PfuZm8KsJuCfA8XqZAJ6QNftB6+MDN0mqlvIQDBr 3wLgUEzAnF9g2k05iqXeHT5f0p7tU9TZiB8mnxOEtsNQir8F30i0obEE4LDClwwn08l9kE zI0/MtDJd98t1ZXkzBoNioyklj2P2FM= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Sg+/UsdM"; spf=pass (imf07.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736212371; a=rsa-sha256; cv=none; b=tPof3u478STdJNSGYTyLoxt6iPDR3AZGrTEGjnKOKl+5LozGnKF0ZOmC1dt77zVPvAAO0r 629ja7kwR06lASxY7YTxdriBX55A+Pl4Zp2V2EgFnOT94iwxW0cDgUdGQfwMqxNhad4grH tFgRK2l4dr/4eTVR0JHUNcU/h1YYoew= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CEDC05C613D; Tue, 7 Jan 2025 01:12:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94C39C4CED2; Tue, 7 Jan 2025 01:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736212369; bh=q1z5WtS6vKHnbPI01DoVbop19PAY9r5OTM6/6KAVsTc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Sg+/UsdM0apxmn3E8JxvhtJwSgj8fV8Xk+RL2Vv8uwygA4HRxCumxyhZcp1+wDpU9 tk90APAMMeGgKdv+NvEAnnY5Udqm/TesNdhzwomaj1+XCsWKyB6mWihaR3aIvE5n1F neah6DK1OJ5VepOBVxKN43IOrVIIRpbv4tH3hgayCv/cqQIdlDG2+p0t3Igj3paLS6 AwT81aLGJeYWZnDC8TjrOuQ27ccTKVegqO/Wdx/g5fZ08dFToU14OoyyhFajvZ0BYx MYpghp4OxO//7DzqdcmWZJsY1tm9+pHLlHk8ZUYj0UM4oU3mS+5Kn2R3LQlaHVSxT1 rP/07o11QPyMQ== Date: Mon, 6 Jan 2025 17:12:46 -0800 From: Kees Cook To: Lorenzo Stoakes Cc: jeffxu@chromium.org, 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 Subject: Re: [PATCH v4 1/1] exec: seal system mappings Message-ID: <202501061647.6C8F34CB1A@keescook> References: <20241125202021.3684919-1-jeffxu@google.com> <20241125202021.3684919-2-jeffxu@google.com> <202412171248.409B10D@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Stat-Signature: ikcc8dwhp7joe76j95aahnis1waom8to X-Rspamd-Queue-Id: 137DE40008 X-Rspam-User: X-HE-Tag: 1736212370-947111 X-HE-Meta: U2FsdGVkX18sVSLGjIXlXBiwNKSUc4o9nOuBbmLwjb8GV2YRma+CZ8xBl2GqS7ixkUcrElAT7UfIqdjp+WknMUZg6jYcXPvJaWrZkvbpyfSXEZYQyMyQ6z5d0Om/1BRP/bZyRghao/fDVNVkJejVlQN/FqqXG91uFpnN795/o4qjUsPyOg4udLWTZzWdye4wqCcB+16tlq0NgMAuZOzdVdaXs8Vqvq/nOUd3zd69g5PbbNMCbMsvTExeS3lqyJila+ii/vy2y7qP19T4W8OXkPoq6m6+foVXtX7/IkYfcdKjDO9OA4TKZsnyMWMijLsKVYefVhJKPcFftoINAgjlIBs5PT0/L2oAN0CDBggydIq1JfQWkkhpu6MkHNMRzgpbaK5AeiFMMTGV9O68KIaaQk0hdYXYcBjM3T2nvMFpUL3uMzIedWcknI1qm25zwBY2s6P34uAd/70Q4uBg7hqbRBWqnDtRI26Tpfvuw5tUcwW5Igs/A1T1neWrHHCVpcQmzpHakNCNjHOfxwUZoLLwJF14yspzYtniRVFxhOeizSAlYHyXiNACxwHb8bq2UfntaKTceoVGUke5BtbfU6qd2Og0sSRRWtQAHbIfZDJSP5wGTawqAL5A7TlIMtmZ5GyDgH/IYGrWJTtOpzxmkLRo3Xn9QnqocoKIlcBXkymxNVqw/KKyxeUjDICJgVsLxo5aOZgl+raLGpvhSiwr2DV4NuCVF5DPpJr1oyfE3ssrROceyex0P+QC8q+7URXS2EceWwEY4D9xSBgxgoL8nNsc7gyRUb6MwymS7b0qRupt4r1Kl1OCP25g72DrFH6mV/i+RmKaspfWn0mebHZStNCqeiGs8+J7ECAgrA3QIhUDqFIQTExTkfibvgbwu97TvIe1ChZvPv5Iw/QC/txgpyAIVbUS9h/XUNqo2kswFgIUt0SCXsFhgK7cuLAp7JYnUCkWLmaq0afuVVBitPILb9x P7NgxXI9 UXtT2ieiOh999hBqOlPwbTj/Q1CipteZuLulUW9zhZ1gjIsLUXbDOuCA80zWou7p/VkqvZNbC/b+bDtSGOcgGBRwCki1Oyp7ZONikyeGskz5P4wPpf3nVFmMVwhbYDuj7ADiDulE1FKYyo47LiZJ4EK0nQ18BHOwrS52IgZctJIaminp8lNftdbCfxvkYALdDJdPYqQ1fHQc/3ZJlxFvLEbpOGefF5UqTs795qX/aRr4ZBFsJS9gOG/RGu/gs3Gy6maTBPudq0+N42fFDudUT4LAitI5Atxvzt5mQR1arILa1rMSc44p4FtwPubJoN7aq355X0NvdJtGNLYwUduAvBKouIDhfpIX0swqE X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 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 process. > > > 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 = [KNL] > > > + Format: { no | yes } > > > + Seal system mappings: vdso, vvar, sigpage, vsyscall, > > > + uprobe. > > > + - 'no': do not seal system mappings. > > > + - 'yes': seal system mappings. > > > + This overrides CONFIG_SEAL_SYSTEM_MAPPINGS=(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=n > > > > 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 here. > > The vdso is very common (arm, arm64, csky, hexagon, loongarch, mips, > > parisc, powerpc, riscv, s390, sh, sparc, x86, um). For those with vdso, > > some also have vvar (arm, arm64, loongarch, mips, powerpc, riscv, s390, > > 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 we > 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 fundamental > that impacts _every possible combinatorial combination of configs, arches, > 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 being > performed. > 3. Buy-in from arch maintainers. > > So far this series has provided none of those. This is why I am cautious > 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 should > > be "default y" since we have the ...ARCH_HAS... config already, and then > > add a CONFIG_MSEAL_SYSTEM_MAPPINGS_DEFAULT that is off by default (since > > 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 enable > > 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-broken > thing? That seems really unreasonable? And people would just have to have > 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. -Kees -- Kees Cook