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 89808C02183 for ; Fri, 17 Jan 2025 18:20:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 193006B0085; Fri, 17 Jan 2025 13:20:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 11AFC6B008A; Fri, 17 Jan 2025 13:20:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAF826B008C; Fri, 17 Jan 2025 13:20:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BC9696B0085 for ; Fri, 17 Jan 2025 13:20:35 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 48AD145B51 for ; Fri, 17 Jan 2025 18:20:35 +0000 (UTC) X-FDA: 83017759230.14.CC4BA39 Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) by imf13.hostedemail.com (Postfix) with ESMTP id 5189D2000B for ; Fri, 17 Jan 2025 18:20:33 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=mJ4f6S82; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.41 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=1737138033; 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=a/fo6mTZutKR3QAHE0Pj8Nd1lbI+SJ+/TzDYibg9toM=; b=55jw5SvQYpp35tBUaAFBs7DkjcUFd2+i2IRIznNNULLA/Xcr8oJTh0r1TNnE/r6DmqFsd5 2tUMN2DuNhLggNbiL8a5RLNb/wtd7ca96TXntIZcZvGwWmhiVJUp6pd7/neltb1PbIMU2a pknL/WLV9SQ0g0cDsH4BSWqI/QT4e/Y= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=mJ4f6S82; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.41 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=1737138033; a=rsa-sha256; cv=none; b=bRlZDmx92hV0xskHOvvQ2jzTgX5ui0v37c2PcxD4VinEaNmDS7O3eBaxNpruW9TcDSraS9 ZIWJYL1UAKieImEgxh0kkB4dMQLobhRavm5IEsRJrnSPGSvBL/5emJq/sVQBLeDiIOlKm7 Qb7Zalz+1o+hBtkSvsPGOwuJ7iDqB8U= Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-5f2ef96ac36so73439eaf.3 for ; Fri, 17 Jan 2025 10:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1737138032; x=1737742832; 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=a/fo6mTZutKR3QAHE0Pj8Nd1lbI+SJ+/TzDYibg9toM=; b=mJ4f6S82N0+Z3m3tEQF/LJEoOZ7wM354BfYjm78SQe9M1SbuU6xgLoJ3EJTHfUDpI4 85D504/3VsnAKMw023q01E8e7L8o7Qrc4kqoJOeJC4Gt1A1tniu6VjnDhpH/ZJ67u6U5 UBAayLA9tDWx3S3C7/oAEkevLOInUd6XbEGW0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737138032; x=1737742832; 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=a/fo6mTZutKR3QAHE0Pj8Nd1lbI+SJ+/TzDYibg9toM=; b=F4hzB6y1A4Wx5zcDyqWJemhpCHMVeOaGeBM0lXm2kyUszqKCJi2Kz9EnqpcUH9D2oB 2lgRktoFDjKJd8UTN+5Q/WAQQ5TOqRf5JxBU13An4VPiVwVh4gfL+BYph80t/vfal+Ff HvmxvNP47bYHzROSD6r6uVtBJO0Jnt88SfG2AzyQ+3MCxr+294peZFWQpfISV481AIQF lcV88Br6F71Yfeiii4qLKTv/vgJs9XdCZYRD0YzOAAlASu4JA9wGJ2U6TekfHXL5NWz7 c79SwChmfmTcYXsQkgPGaEJcZYXrKyvWXt6qMPvLs+brmBSYvnXE22gtrYh3xj4sFou7 jiGw== X-Forwarded-Encrypted: i=1; AJvYcCUcg4jUUg23CgemLUl0D53VqFdRTzboDqDsbs4Yhy/GjuQd0WevP3TnqDnkoJlrWKkA/MZLg48+wA==@kvack.org X-Gm-Message-State: AOJu0YyHKQ4h+jLDGMuzsTG2WgrDLG6ypkFPkOkbL98WvFEIBfOKR9og S+QssCK8ddqCm5JHrCl8EM6rU8QuBiRdN2CIbEa2Bnrwuu8ed9hnjirBhOpApMcFO38oEcIYaCk DD3LSCYgyWV4fZlIu3ttpZBv/Jjdul5F5Dx3j X-Gm-Gg: ASbGncv9SYKSk7eZ6IetmrbinGX/zjJO9I6dp/PfHgJsLIBMkpZLtYi28tjgHOJOPgu cNYVTFWq4o28/Fs3k6a4Wr2dE5sRGEqyYV0bexrrhC26iI8MdhVc0UZb25pv39taiDvw8Kng= X-Google-Smtp-Source: AGHT+IEl14ZsVUuRQs9kENiOI/ccHALGPnLCzkhX2kYLVq1g67aUGEjWWSC3kkfQ60mKfp+6ZE7STELJxCWfkQ+V3xQ= X-Received: by 2002:a05:6870:218c:b0:29e:37d7:3f56 with SMTP id 586e51a60fabf-2b1c0d516b9mr698878fac.12.1737138032234; Fri, 17 Jan 2025 10:20:32 -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> <5cf1601b-70c3-45bb-81ef-416d89c415c2@lucifer.local> <7071878c-7857-4acd-ac27-f049cbc84de2@lucifer.local> <2e5de601da34342d8eb0d8319dcf81ff213c7ef0.camel@sipsolutions.net> In-Reply-To: From: Jeff Xu Date: Fri, 17 Jan 2025 10:20:20 -0800 X-Gm-Features: AbW1kvakDKAevh2HLCVhk1nyOYdN4y1OuVm2uoByUvbbZ392IzJafigOqPdV0eM Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: Pedro Falcato Cc: Benjamin Berg , Lorenzo Stoakes , Kees Cook , 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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5189D2000B X-Stat-Signature: sf6ru11m74tde91mzbnbb8dgfkcwxmtn X-Rspam-User: X-HE-Tag: 1737138033-852563 X-HE-Meta: U2FsdGVkX1/iaDu7HizD23eoSINRinvq89rpSId2HAp9plE+gms9M6gHO/cbqJJHqlMvkJYjIa8kK9JGq7RPc/RqDVtSNI9yObFxak96AbSA1sFj5nLA1HRU4ZUM15+H7dGGVHi6bJkVLS2rdsXmHfwjz1e+PVqsm9+bN8W7O6nbXJJHIZhjG1pbSdazDbTiBf0bz/gpwF6YQo3IjLfORThB04hIp4SFzgRQuTIPpGAjvYnXp+p/WW+b97Mi4lPQOr35+1T5OOSz0WE0TY6TCMUYDpelNY/t6efN6TGtfwI7ADoZywUUa1CmrpAdIGbWMS2zL7T5OtM7TzjDNUD4SxMY2wui0ER3SDFDtK7sl5BBvlPUjx5+VoV2EMFEYbz8PIYyY9xp3OrfzmtQKJF1H6pDXKGqy15TObjvgwoQzRod2tkWcxgUERV0+V0J2lBgGbcXlfbpTPy7QSpLcM7Dq1ylTD22wyOdVz2xmxHW0ia7edQvfzdmOyvnX6V+PpZ2lLu5ROw1+eLsX9UZl5S6mMHjqQQreDzA0Zck6iDhh92R2p1qu7kE4EhdqFlWvtLrp9xajp7qeSN2RSloU4cyNiXwLb2r0qDKSI/zr8dR83xkJ5MJGLxP5E4KKexQTyYoGMqF91kqR5J9y8hmIiFm3zLRkqLz+L2RbDc2cvhcNHtCXPMlJ+Q4+9xkZU4i3nMIrPaKADiyQMT5Yr9oQUHE/a/3AYsTphNkhKxc1vZNUNEHKzjElyzUTIEVz230rQEKLXMCMFGUBeXIQXl9Xbz2PshjJ/cBrRuxZULgpr+7JY89y0KmG8iu26tBWtSJMYdekrsftDULHBZVNItkrjqV0fOSlBrwHblXTnlC81s2faAbSUDKA3QTUkbGJcEWdUS2vI6ygTjeiz0/JdGw2A9h20VhGekxxbKsOxCpRfHeGR2m7A24/N6W5zL0sr8v5PudLFutYBjtsxdDuguEw7s fmvtPW0k tvgmEcB2NT8oxK5C2J7hmjurmXupr//jYnp8Bv/zYdS3Iw80n02j1rZrZo7hbRdHcJf+dDRIrALsM9NTfcDCq5ydDCUbcn3lh+niWtyEtEJF9IxOI8wYrv+4VKzQ2000UyQbQq7ZKxNLnes/A++2msNkLh0oE0H7KMY5WdCC031bUS8ZvlK/Y7e1G021LwN3vewF+qOqDDRBtvkGIdh5qSaR/ZpxR6ehMfIjZG+NUClRTcfuy8Ki+QpUdtlCuDT2nhV9hu2cVd4W6R8xRXhTzaMVkp8kmmoyEkf4isbbboU9L/lrIyDSTSJnvKFabiwSPKFx/yBPLPU+3+9y+5GbJ5E+hLJSpl+avZyl7wPwokehXQ5sKjs2pQg/nmg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, 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, Jan 16, 2025 at 9:18=E2=80=AFAM Pedro Falcato wrote: > > On Thu, Jan 16, 2025 at 5:02=E2=80=AFPM Benjamin Berg wrote: > > > > Hi Lorenzo, > > > > On Thu, 2025-01-16 at 15:48 +0000, Lorenzo Stoakes wrote: > > > On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote: > > > > On Wed, Jan 15, 2025 at 11:46=E2=80=AFAM Lorenzo Stoakes > > > > wrote: > > > > > > [SNIP] > > > > > > > > > I've made it abundantly clear that this (NACKed) series cannot al= low the > > > > > kernel to be in a broken state even if a user sets flags to do so= . > > > > > > > > > > This is because users might lack context to make this decision an= d > > > > > incorrectly do so, and now we ship a known-broken kernel. > > > > > > > > > > You are now suggesting disabling the !CRIU requirement. Which vio= lates my > > > > > _requirements_ (not optional features). > > > > > > > > > Sure, I can add CRIU back. > > > > > > > > Are you fine with UML and gViso not working under this CONFIG ? > > > > UML/gViso doesn't use any KCONFIG like CRIU does. > > > > > > Yeah this is a concern, wouldn't we be able to catch UML with a flag? > > > > > > Apologies my fault for maybe not being totally up to date with this, = but what > > > exactly was the gViso (is it gVisor actually?) > > > > UML is a separate architecture. It is a Linux kernel running as a > > userspace application on top of an unmodified host kernel. > > > > So really, UML is a mostly weird userspace program for the purpose of > > this discussion. And a pretty buggy one too--it got broken by rseq > > already. > > > > What UML now does is: > > * Execute a tiny static binary > > * map special "stub" code/data pages at the topmost userspace address > > (replacing its stack) > > * continue execution inside the "stub" pages > > * unmap everything below the "stub" pages > > * use the unmap'ed area for userspace application mappings > > > > I believe that the "unmap everything" step will fail with this feature. > > > > > > Now, I am sure one can come up with solutions, e.g.: > > 1. Simply print an explanation if the unmap() fails > > 2. Find an address that is guaranteed to be below the VDSO and use a > > smaller address space for the UML userspace. > > 3. Somehow tell the host kernel to not install the VDSO mappings > > 4. Add the host VDSO pages as a sealed VMA within UML to guard them > > > > UML is a bit of a niche and I am not sure it is worth worrying about it > > too much. > > I've been absent from this patch series in general, but this gave me > an idea: what if we let userspace seal these mappings itself? Since > glibc is already sealing things, it might as well seal these? > And then systems that _do_ care about this would set the glibc tunable > and deal with the breakage. > > Is there something seriously wrong with this approach? Besides maybe > not having a super easy way to discover these mappings atm, I feel > like it would solve all of the policy issues people have been talking > about in these threads. > There are technical difficulties to seal vdso/vvar from the glibc side. The dynamic linker lacks vdso/vvar mapping size information, and architectural variations for vdso/vvar also means sealing from the kernel side is a simpler solution. Adhemerval has more details in case clarification is needed from the glibc side. Additionally, uprobe mapping can't be sealed by the dynamic linker, dynamic linker can only apply sealing during execve() and dlopen(), uprobe mapping isn't created during those two calls. -Jeff > -- > Pedro