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 9FA9AC02180 for ; Wed, 15 Jan 2025 19:02:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EBA696B007B; Wed, 15 Jan 2025 14:02:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E41BC6B0082; Wed, 15 Jan 2025 14:02:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBB69280001; Wed, 15 Jan 2025 14:02:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id AD7DD6B007B for ; Wed, 15 Jan 2025 14:02:41 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DA43BAD7DC for ; Wed, 15 Jan 2025 19:02:40 +0000 (UTC) X-FDA: 83010607680.23.CDD8F10 Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) by imf27.hostedemail.com (Postfix) with ESMTP id C66884000C for ; Wed, 15 Jan 2025 19:02:38 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=K2lCxtR9; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.170 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=1736967758; 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=oR553TrwrqpCCgJhzSi22uMSFUqd9KOEdzBBC2gdpdM=; b=aqLyCLW4RX29KxAC+44i2W8GAAHMDdYNWO3mJBDP+p15foNyFJJ7f3//mzZkTxU2ASJvLa 398CgI4SxY3JF8flwHGqTK7jktZFXzOb7qtZ223GgKBxsGmpw7H+w/NmaAvvS1pP84aBHI emqL35WUmhUDVjCENAJwpv7FxK2v+RM= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=K2lCxtR9; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.170 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=1736967758; a=rsa-sha256; cv=none; b=hbRlUW4XP4kQ9whNFnGLXHI4WjwK8JkM29Gb/B0uCojsJDc57z8tdCH++c++NIgLJ/gTH3 z7T5Jiy9A95FYutB42cDibiS87yPzrmd6uJqQt9LGxRXvvFUZGfbhgD5hInUpJeRipsqbM FQ27PtGaU166xk1o303+oICTwhJJQP0= Received: by mail-oi1-f170.google.com with SMTP id 5614622812f47-3ebc07d3d0cso19515b6e.0 for ; Wed, 15 Jan 2025 11:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1736967758; x=1737572558; 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=oR553TrwrqpCCgJhzSi22uMSFUqd9KOEdzBBC2gdpdM=; b=K2lCxtR9OhSm7Y7Oy/htSohF8wy54Q0KC/46OyFkwCD0352bXYEiJgqHN3cX0IOV06 WllqFVmw9b+p1j283HXynpKvCIELnVd9qrXw2v3qeY8sBH4VwTXx5nPgvXbONuKqBH1x kKqNtiEhphaiKGjfQlrcVRSve4PvC8W2Q1iE0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736967758; x=1737572558; 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=oR553TrwrqpCCgJhzSi22uMSFUqd9KOEdzBBC2gdpdM=; b=VB1WC3SYdMWDegQswl1WdXp9xcWpPFGDh49xf5x2eZYiok41t03m/uhnUYZ3Fo6LrB 9/CkR4oo5xEDZdfgKsK5XjkYqFaGgGyz91wg2rdldaVu71nodGvzNIP967G8a3ixZBY7 yFeEbqs9fTGX7a3g+kpSXLcz7cKW/cjXmyuxU1fwNCgmfu0fbUqCMu4u0zOASMk7jy54 yvndtcy8BPOuMd3HFGA7o/UyonXvgB1LAC5+yoHoWKxytBiQnuqQ8XS2d2oOByUMyWSB +aKYqTd7UBA3miMB9Sj871JgOfbP+IGBFKjoqac4NB3h0geSL8Kgi/z6i2wEUI1IO8pr oJDQ== X-Forwarded-Encrypted: i=1; AJvYcCVp3GwobbqFEnr3ZWwgrvJMchs2OCfQOFqtEt/iGRElHa2AbkZ87+rQ0OIXiB+vC81+mbGoQ65l4g==@kvack.org X-Gm-Message-State: AOJu0YxPLKZxFmSN1bMjx6J1mo7g8dNmw7dU1Qg6TE/03cKABoxKzqmF BNif7wZRPL2h3mwyB2XJieJYtKPHUZBM9FECUViv2MBlCeWCxUYYT6mCxSX+rdVpfi7XWbQFIq0 /ArSGjCJYEX0OfWHhNQ4D7pZjZtvMxjEY6sG2 X-Gm-Gg: ASbGnctjl4O198dY5xjmjUpxyG7qQVp2Qvcg1/TzgisaN3rtwQCUArBZXD59c19m6iN 9s40UV4UwKOzFWDjVbmYDpjCRGheKsrpV2GukTiUdSuLy+G8AUv0usmSwm7Nm4leHR1ZfWIw= X-Google-Smtp-Source: AGHT+IHJDYeJ5X0NO40gYrCx6Nf+CyMxD/lyuS+UJt1ruVzlXnqHay0LNFC2x3q6Z8XDTFcnvw2j69mY7aWEtcnWIuA= X-Received: by 2002:a05:6870:de17:b0:29e:1875:222d with SMTP id 586e51a60fabf-2aa06530726mr6681786fac.1.1736967757563; Wed, 15 Jan 2025 11:02:37 -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: From: Jeff Xu Date: Wed, 15 Jan 2025 11:02:26 -0800 X-Gm-Features: AbW1kvYn2BAPo5WR7fYl8bHiH30P-gCiaywMoquNyqXZp_TgZxuUPDbEj7X10Wo 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 , Benjamin Berg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Stat-Signature: dm5juguo97541ker9guuq9bzp8bxgc7n X-Rspamd-Queue-Id: C66884000C X-Rspam-User: X-HE-Tag: 1736967758-289776 X-HE-Meta: U2FsdGVkX1+2UHEWdWgtgsgtPEOmUShc96TYvA1eUPHqf2pvBOHSrMf4L2kG6Efr8rHtjBr3NJ9Z2u1toYSVIVAKbRgGLwdYMa9Lhfqqu0tSyphJrHI70hzhw5m8KMo6GbD8wcoKr/D80nl3e0S1iER3eyXYvez+8sui4Oe8HQCpbHVPen/EdNd1aD5/RIzQdv7ABN5/jFx7NzQxNXRco2nrQIO0g0m/qYz0ffs6ROsuJzidCXSsGb101CN21UGEKl8TEAWkqUgKTXbZVZFTxN6eFTgekpZnF22mLz3Fdt1AwmqP8AMo8MuDh/6/bMVBEp9KIO0i/IuNE7HHvC7goFF1id9d7imHjkunxRSDnmmhow6wdslmzAwGExcg6BUYOWAc1F+ktlyQQcmMKrD1iNTxMs1EVLLEdsbS151wBUWwVlS9Bn9ErJShtVEOCWfjFMTCWooOKynnIJh17aChngLVxUHGESqXujg1HMrMTmMQlSAkdTyJewaWpeegqzAYetR6FzoH5JwV11TclnqFXnUJ2nKmY10pvSQ+8VcSWaq8CgwjPhfbv9gBP+Squ0mLfEmWvRNCeaM2YaR+l8rsHrh1vTkXqw8snAtDCUwiP1FYCnGyb7erzOaVmqXLB2pI84mG+JUTsGM+QDHxDwBtok9syKuqmzYV1ZdjM2RhqlVgpf1HOhPFMHPt5BTc6dcn9DgjvAT1oEolb1lMMuKDH5YyOF+cjaXzAmw2iIvwfVXqvNUshDk0XDuxNR+yPc/k8j3mgceYCtrYjW45vNoc1nE6sBAdXyOFjZvWfw4H0PW1aVE8Q6ay5YfbQ76S/HFWaGiZhEPeHNkHqcBcpDM6fXpr9Vs/J6yhscH5L1NfRYePQNtf9F77PkbkeQpq/Ms1/yxMONoMg3+ufjpexIqfWUVPCn6Ele5tzjHUBkEJ1cygHq7mG2aeYxElbmWKpJDsgR3whKWIkC3IkfbkzyB /BxJuhF5 2417TGYue7fJAujxbvLBeW7YevL4K3e004xnoWp5JuOJU28p9ioGA18wQ5tppKEUPerb+uZCXyXoxEujY+zOFCaBMbDAKxt6/n6SDfYDPqueWvttIItrDJT6X1vHLw5k09SawI2etnFyawfGRUXaQ+EysDk9svF8QytmWuKFuNqHjXGIpFdyYhfbO1cg0Hribh7WMe2NAH9MERXTVAdSvf2LA82QH+MKGfySB7+lEQ+L22HrJFFrJskJymHzZ+i7dwS+aSa8Qp1MX3RXH329Er0jzr7ccEu/ItdfJqt9RxWzJvlSqxfji76Je8Ege6Z6y0DBR X-Bogosity: Ham, tests=bogofilter, spamicity=0.000013, 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 13, 2025 at 1:26=E2=80=AFPM Jeff Xu wrote= : > > 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 prote= ct > > > > > them from ever changing or unmapped during the life time of the p= rocess. > > > > > 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, vsys= call, > > > > > + 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 val= ue 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 he= lp > > > > shape it based on the current discussion threads. > > > > > > > > The callers of _install_special_mapping() cover what is mentioned h= ere. > > > > The vdso is very common (arm, arm64, csky, hexagon, loongarch, mips= , > > > > parisc, powerpc, riscv, s390, sh, sparc, x86, um). For those with v= dso, > > > > some also have vvar (arm, arm64, loongarch, mips, powerpc, riscv, s= 390, > > > > 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 fundame= ntal > > > that impacts _every possible combinatorial combination of configs, ar= ches, > > > and use cases_ for each of these which we seeming - just assume - wil= l 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 b= eing > > > performed. > > > 3. Buy-in from arch maintainers. > > > > > > So far this series has provided none of those. This is why I am cauti= ous > > > 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 reductio= n > > 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 switc= h 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 bei= ng '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 sh= ould > > > > 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 kern= el > > > > command-line so that end users can use it, or system builders can e= nable > > > > CONFIG_MSEAL_SYSTEM_MAPPINGS_DEFAULT. > > > > > > Again, I hate to push on this, but I am simply not going to allow use= rs 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-b= roken > > > 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 para= ms > > 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 ? > If a complete solution is desired, we can continue to discuss the open/unresolved items. This summarizes code logic requirements/comments. 1> Enable the feature per architecture (Lorenze) Current state: Already in current patch (v4) 2> CONFIG_SEAL_SYSTEM_MAPPINGS Current State: In v4, this depends on !CHECKPOINT_RESTORE. This dependency is unhelpful for gVisor and UML (which don't depend on CRIU) and should be removed. (next step): remove !CHECKPOINT_RESTORE dependency. 3> Per process prctl (Andrei Vagin, Benjamin Berg) Current state: Not in v4. Andrei suggested using prctl for opt-out. This shouldn't depend on CRIU/CAP_CHECKPOINT_RESTORE (since gVisor is a different feature) (next step): Add this opt-out prctl under the new KCONFIG: CONFIG_SEAL_SYSTEM_MAPPING_WITH_PRCTL_OPTOUT 4> kernel cmd line: Current state: This is in v4. Lorenze commented that the new kernel cmd line doesn't have effect on the 32 bit build, so users might think it is enabled but not. This is due to the fact that the 32 bit kernel doesn't support mseal(), i.e. mseal.c is not even built under 32 bit. Standard practice when processing kernel cmd lines with incorrect input is to do nothing (no logs or crashes). Addressing this is difficult unless mseal is supported for all architectures. These are all the code logic related comments. Did I miss anything ? Other non-code related comments (threat-model, tests, etc) will be added la= ter. To simplify the next version (if no agreement is reached), I can focus on items 1 and 2. This would satisfy ChromeOS and Android, as well as distributions and users who don't use CRIU/UML/gVisor (likely the majority). Items 3 and 4 could be addressed later. Comments, suggestions, and alternative approaches are welcome. Thanks -Jeff > Thanks > -Jeff > > > -Kees > > > > -- > > Kees Cook