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 DDE7AC02183 for ; Thu, 16 Jan 2025 17:18:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 718CC6B0083; Thu, 16 Jan 2025 12:18:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C7BC6B0085; Thu, 16 Jan 2025 12:18:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B6156B0088; Thu, 16 Jan 2025 12:18:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3E6E36B0083 for ; Thu, 16 Jan 2025 12:18:31 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BF162160B10 for ; Thu, 16 Jan 2025 17:18:30 +0000 (UTC) X-FDA: 83013973980.24.B6FD766 Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) by imf08.hostedemail.com (Postfix) with ESMTP id CC6A9160018 for ; Thu, 16 Jan 2025 17:18:28 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Vx+bIDPc; spf=pass (imf08.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737047908; 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=NIb1wl7rZ3beW2GNNrOqyUi3HQyIhkAMG063uoHeVxk=; b=MtcpaQNd2aNq6xPPQMkntZ6MaIxySVQG6+OSTvsgSBsyf8F+YBfZVw7zYJY+BYqqbzir5o Y3m2giRkGRv1lACSk4tOyWHl5cSRZfpj9yGM2FKa7/n/N+Yf9goqfj5fDvXuuqVjylQtya r75dQ6XNjxC6KKkIBj+jQ+3mtq9Fnvg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Vx+bIDPc; spf=pass (imf08.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737047908; a=rsa-sha256; cv=none; b=UwwgMkWHno3KwXodmu+R4UscPPJYN05d5Cg58y+feo1Zw3ytqC4wK43eL+LUCsYA0dXgA5 hhA48GAPylzWQwKhtyfGAETVZiVsAhi4dhb7WO2P+77AMMwam/ijmBj4VxE6SxHVFFAuk7 t0M8XzCLfJxd+sxVc3YpYcHG7wFxrUQ= Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-5160f80e652so256269e0c.2 for ; Thu, 16 Jan 2025 09:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737047908; x=1737652708; 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=NIb1wl7rZ3beW2GNNrOqyUi3HQyIhkAMG063uoHeVxk=; b=Vx+bIDPc5/yGKkrle2WAherZKKSpW6fojCF2aeYVk9Pu5icAq4dMrtq9zZvwjTRoeL z/0ON3SPTg7+KwItGR3To/OKcaCb0d7nMMf8P+/24waEemqE2ie+8jNKqahCS9aShZNl IgWBQX6n1Hg4nUKXAPegEKd3X3f5KV1A/++IejXqgUA0jw6IhHtiZ2nZbUx1AJn0Zpa9 sbRNanTBgRHUAm20bPaEJx4H5+yPwrx3LufKgnRI0htkl0GdympDgMxF+Clxc4YSiKyl gl5g9dU+K6U+XrSoPgvgJAnb6+yr5Dg7paZqnpor6GTRw00bhlbEH4Y50kY92uCx8p6+ 6rsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737047908; x=1737652708; 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=NIb1wl7rZ3beW2GNNrOqyUi3HQyIhkAMG063uoHeVxk=; b=YfSBCLQvjYQFksyXROtVwEAp9wFDWzGBFhTgudTMg2nwcvTuClFY4jFQ+le+7wzI7Q nXrH914d+9ABA7UP4+jdEVf1hcno0Tbdd+kCCKGtV6cOLQjBYLEDE3xAb7FcybaPq8On xDT+ZwXn48aJEBGmoaEl+jmmsUFYdYRBVJfm7lUbMLPgjJktibkqA7zCtRwos0FjbWnG 1LNRE7n27rsT4M4wR6St5Hko6o7HQ4f7b7nJJFA4r3PE9v79VkUaFpx6hIn6K8yO9Jjk o1kE4qpRA5B7VRbchlcH/NTU1hd2QdR970BGuJniAhZWjF1bFLVXKqvjkZn3KwbjcEmu Rkqw== X-Forwarded-Encrypted: i=1; AJvYcCV26k9p7tzZpKrUPuteSP8qDnY99eoYIsR7OPgtigCIEK+We1GiGr1BcZlZ6qP60yBtmkjFU2sByw==@kvack.org X-Gm-Message-State: AOJu0YziELRi53J1dpSeKzylbCR4gJ9c5xEnq8od5jMtdi0UzWTgT2jE vvd6F+ay5YhryArpyT0nJa01eZqxxCNmm0/kSwetUim07ul37AP3O01hQ/LqsD0LnGdz28Q+9QY 44wYSnaeEj5kOrHTz6SWJ3V+axaY= X-Gm-Gg: ASbGncvtkWbAaqC6Ptu9S6P4YSJx5aqIakwd/keTF+M13HCFTekqGFqmojhfjXQ+mKi 5ioR0iBABpxuUYLGB/Xw3VcHkmpoLjcwMyGlnp1tVQo+1hRVNpIwCjfUv6msCyyBCkR8JLw== X-Google-Smtp-Source: AGHT+IGX+jGuDD23RFL3nsTA1kL7lcKnOBfgvlGI+womNk0s9t15qFzK++xtH4xhdlRhm2ifQuE4QMXDNgbJR5ot5JM= X-Received: by 2002:a05:6122:3d04:b0:518:6286:87a4 with SMTP id 71dfb90a1353d-51c6c46cf5cmr29833446e0c.4.1737047907748; Thu, 16 Jan 2025 09:18:27 -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: <2e5de601da34342d8eb0d8319dcf81ff213c7ef0.camel@sipsolutions.net> From: Pedro Falcato Date: Thu, 16 Jan 2025 17:18:16 +0000 X-Gm-Features: AbW1kvb2icL8t-nMNbmK_a5xHlHYzrBc3Ijc7KF3gMPnlQvD5I3msU-Bte2Tok0 Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: Benjamin Berg Cc: Lorenzo Stoakes , Jeff Xu , 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-Queue-Id: CC6A9160018 X-Stat-Signature: 5ctkryoe9754bqt5ajh3zdoeq6b594xz X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1737047908-295178 X-HE-Meta: U2FsdGVkX1/YGFJbrQTVFS/6MbqzZI7oMxrS4r5UvU7GlpN3QbGDSQUfH03Q1IOqSoX0nJJtOmzj2wXZNae9nI6/JnkvtWt5hZ3VZ0dA01wUCKHZUKSDv5E6TfGfx3BREHVMvix6BsdTwB11VhYtjLZw/QmZZloA7PCi46HYR9sv1vl0YYWDyZth1PrvBDWNLVIl/kDfVOvysAWtuw1cVFW6zPm66A8IJ8Yyey4hffuXqmw3DAWRgjCyWmdstnowWNVSTa649dFT3vNqlFaLB88yofCTvCwzqZr1ms/OIkJCe/CkgLKKn6bc3jd1TfGedfT47kyPetMV1H5mckkDG15SBM+kp9WNVaHPCva42lM716vn1Eul95YxU/X+AlXEXAZSW2xZxB9Cub0VouiYiWQams1b2+pe0BfwzP2/kB5bShDSI22md0wubFJDXP9o8l2iC0XWht/0P0IVLJjU8X7oDgYt3nPaQ+fbkSEWV75eKzWpKajB1CkdgCQNmsnRn5Z6qrlp16nyfCFNRXNao1GlJvAiZfvLLdc6NT2dEySlduLPz/EU0cRPMvPW6N6gAw2lxxxwwlSugysrUmKikE42VLvLwCitTiUdb/BlrcxApCqtT5O8JVgFgY8UNUarnirFRieTdmsWAf1GwlFoQLTK4KV3h/IWOZFu9DXtRFvlDwykVq4Nwq73RiDQFeyvi8JFRwqyCwwebWlYqQvv9IoZlBw9g2SZiKL8T60pYi357dvJQjpXAwYZoanPTwXugNbncWIM3hdnOLum9fa5l7x0xsBNjApWrS7BW9Iqi2ljpz0mUWQdH4gJBk2WQpmnXlvrfu4ic7NtDGcTpinCxir3AGn7GrLkm6hekVyr9Qbjp+FMobO+KDIYsu5t3RYJyUkcIcJHp4OulZ0SDXUz0BofBNB9+POI7hEZQlrJAyAq3OiZ+XZY82NhCe32Syc1jd1o1+tiCC8A2V+Nx+G mC6cM+or F0sBlSkuW3/or8Z1zHNAoaHyRIDeD1KwrmDfB+RgSNqylZSnavTn/AST0Jg7sa5pbZgRBvOFWqczGP4ZUqFonoVqL12lg6DpR48J9SydDas997k9EtcQfhRikLi6LP8E2uJoTcWZ7ubsnIwmU5E/fy52FARl6NSXOZLRgPNFDzqFsL39u9yH+8gz0ctAKlhNoIsD8PidJfdXWeQIlzW0DtEanydAHnq3af124H8yj4o/WapRFYq2r439cQuwC2Uzd0OQyWWWBCAO6d2iIYhmutrLTWdU/pb7fcPoaMGm22BwR9kSILXsV892gWFWrnOtTh6sxIPmQImnQ0I63gj7kU33J1GD8zZT6UOUo55xLqVwVGKGYh9HgEvyEsCJAZy7D/GLmfZPi8PaC1SCVr/OKGPTVCdskG5+SFT+WMBDpJUNx7QEsA4LDLB3uTawVvnHFRmI4gS8/Ft26kUChxXICbexpO+Pl/c8qm2IKup5bQC58LNX46Aa1x0WUiKoF1q20CjNy X-Bogosity: Ham, tests=bogofilter, spamicity=0.000264, 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 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 allo= w 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 and > > > > incorrectly do so, and now we ship a known-broken kernel. > > > > > > > > You are now suggesting disabling the !CRIU requirement. Which viola= tes 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, bu= t 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. --=20 Pedro