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 E68E7C021A0 for ; Thu, 13 Feb 2025 20:00:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6200A6B0089; Thu, 13 Feb 2025 15:00:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CEA16B008C; Thu, 13 Feb 2025 15:00:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49691280001; Thu, 13 Feb 2025 15:00:03 -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 2B5A06B0089 for ; Thu, 13 Feb 2025 15:00:03 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CEF2B1C8E0B for ; Thu, 13 Feb 2025 20:00:02 +0000 (UTC) X-FDA: 83115987444.17.5CA9AB9 Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) by imf19.hostedemail.com (Postfix) with ESMTP id E6CAC1A000E for ; Thu, 13 Feb 2025 20:00:00 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="FvmoOcH/"; spf=pass (imf19.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.222.49 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=1739476801; 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=6A/tJxO/Tj0qrEAzN+EeAFZ+ugKQgrcetXab+VVZsmc=; b=7jnuwH1Lrf1JkHGRjs4z0sHVZWrBkEho/fP3W1n1AKzkQRL+ZdmLI67zR/nf62BJbF4udD mMHnFjP5Y1ZLrN6nZQKHY6M7Gy/JhDV9DHY/sVpkNEYGJh7meIUu0/qGcQ3+lpNHUgmT24 gIhlcJxm23jlIXMDXABKLQlcoj4JE+Y= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="FvmoOcH/"; spf=pass (imf19.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.222.49 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=1739476801; a=rsa-sha256; cv=none; b=rR7NEzOGuJfoucZ5vIk+TUgjArnOosTJcDnTrLZRYAv9AH/ZEJwL7VbG5oRAxWXZeYiFzk dENE0NnhEACdsObsrx2GurE3c6Q82Mny4mQOd3JRAxnw1meSO1MxpVSpDN5ogeVe4TRB75 0lOSgyzxOlDR3xmcWd55p8lqdzYL8D8= Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-868f322b8dfso308681241.0 for ; Thu, 13 Feb 2025 12:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739476800; x=1740081600; 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=6A/tJxO/Tj0qrEAzN+EeAFZ+ugKQgrcetXab+VVZsmc=; b=FvmoOcH/3Vkzuj4tq0n7I1A0f0T9DdFsk/DMFFkEY709qMKEbtflgrP4xJOTs/YuQo zQ1FZ+tKb9FRxiU5bYdHrEhk6UV8SYDkNti20ZtURKqK/K0YeKeN1w8gZvrDD0QxiLzZ j5j8stm3raMiyMvgDtNSybew3viBtbUDAt/0Au1dIqU3JgkTOvdHtwarL9rhIXyPa23y lRhkDaJ6dvDcE4ndKzUS8cBg4OlLTJTHWIKTFp+wKuQOtMlKa+fMLA8Np1mkVdeciscx 7tGcAj1DiKljxfyDGb1eCkk5IHvJ56AQ59MLYE4Zrj+77sB8Te1cr6vlq9pgVHB3n4i6 ZJXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739476800; x=1740081600; 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=6A/tJxO/Tj0qrEAzN+EeAFZ+ugKQgrcetXab+VVZsmc=; b=RA53k39RnCa8AAIyeNsqJcWzWL3gWiPMRbUZySY9XJJ5iAIBjUvrXPCZY3sfS6m7+C OAOVNlgbfLUeG/OAGzRj9UrCJERcSoJXGXUcziulHK3itkhCY/r84vmvJxdoGyMLfPKi f3SdbnLSMZeGqOiZLvx7uE32mnZ2c0IJ5nYAqJUd9BPx1/WOx5ZFwQQhle899T/uCnTg lBcmHRUHZHVvUgJNkYQIu2NEB+271ayCYHnsbDq2zGZuRhyuPtO5p15n2cUN2pRP9+mR v5uAQkW15yiQlksqgHzhUWm3VVrsVHel5PILRxtECMr3yD8tlsra+j1QtHWUeO0zW+Ah KP1A== X-Forwarded-Encrypted: i=1; AJvYcCXFpnA95tM+tjT4ooYZREqxBSwx9HA+auvLTqh0Ao7jNWxB4JrY/LwxK/goirWRzSVpH0BVXPcB8g==@kvack.org X-Gm-Message-State: AOJu0YwB1+gYR35X/Fds5t8cXNaI5gNwZ5bgnxeM4Bqb/dqlkaMjfDgq EB5T3fqDNaedgsGuhqQUVzt+QfnUTyrQ6M7hzR1xOiuJiWuiFDuy8vtK3j4rHb7ze+mN4I2SrP9 1JU3UTEWyWyHN7NpTSC8Ifh0kTgI= X-Gm-Gg: ASbGncucCnhAsnqaS1ULkcnMZTclsDb+U/v6k43ZzqKrX7W2Vj5Td6aTgcgU1//N93x 4oPsCNCtfALpox5of/aCk4sRst4xxiuqPdFi3LfNvJNh12EUO+os8JZY8jgGGsb4HUFtIvbwWsw hO5SsjIhXrho388nIz/StZkzmfHVcU X-Google-Smtp-Source: AGHT+IEO95cRIlLgN+fMIWfpOsxsRmwWcSyCKFAAZvLEYT9kzpmLQTi+dGvN2ibBkJmLjNqJiRwihu5i9SGiHmeJcgE= X-Received: by 2002:a05:6102:3f11:b0:4bb:c5ad:af1a with SMTP id ada2fe7eead31-4bc04fba69dmr3372366137.7.1739476799879; Thu, 13 Feb 2025 11:59:59 -0800 (PST) MIME-Version: 1.0 References: <20250212032155.1276806-1-jeffxu@google.com> <7545d5eb-a16e-4cc8-a9e3-5431be01aade@lucifer.local> In-Reply-To: <7545d5eb-a16e-4cc8-a9e3-5431be01aade@lucifer.local> From: Pedro Falcato Date: Thu, 13 Feb 2025 19:59:48 +0000 X-Gm-Features: AWEUYZnnvu0UeOQwhhCdIYitvKbnr-kOi8j-etdFPfc3PQhlVh6nUZJWVPm76sA Message-ID: Subject: Re: [RFC PATCH v5 0/7] mseal system mappings To: Lorenzo Stoakes Cc: jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, vbabka@suse.cz, Liam.Howlett@oracle.com, adhemerval.zanella@linaro.org, oleg@redhat.com, avagin@gmail.com, benjamin@sipsolutions.net, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, hch@lst.de, ojeda@kernel.org, thomas.weissschuh@linutronix.de, adobriyan@gmail.com, johannes@sipsolutions.net, hca@linux.ibm.com, willy@infradead.org, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, peterx@redhat.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, 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, aleksandr.mikhalitsyn@canonical.com, mike.rapoport@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E6CAC1A000E X-Stat-Signature: 4askoo1jdxwykjogh1e5ar7ypsufdkp9 X-Rspam-User: X-HE-Tag: 1739476800-876298 X-HE-Meta: U2FsdGVkX18/ImVymgzXDb1AG1IScix30I1BKpIfa+zW/ozCv/NGN2Nn/+weYXIZffx5qUUmnSSS2irqZ9fdncYmVX9YbeBeGOuXEU4oW6f6lOGzePwu5VzTMY+0ysVVMuYVWvYG5YmtvdvMHY6Yhqu29Jgz4zt5Iwhr7FY4S8bro38C2jdFoGi6dewhqO0g1+3oXSZi4dxoeLoRylCQmZmGDVPQxGZ5blntBVtoWkwIh5aVxM42e3nYA9hLehO2AHAtbx/PUviRHnxIVPhaHIhfDFel74j+rcGI1VMynVCFGRG8KLIMzrIp8Hn7fymeRGKOAaaOowebjZ7EpG/84YRurF+dP4BbPtjJE/49RP+tS8FN3QoYUGXGBilf+t/tJvdOUaG7lwKnj96XUlY5ZlKfZgSxEIusL5xqJ7u5VIvy29mjyHvDJoauTY/LAK+m+ED28eG2W3e7HImSrCFV8Z0SO8dwGtlO1n8m8QjhdH5RLZcqNpqNVmWBj4/nMGlLiCqbn1/10XA/wBuEtJD1zral1xJ8T20UnbC0ac8zYJQCcnsG7B01dsrHhwYF9S2c+ndQKeiiL+MIs0ZKoCA/BGkBLOiihp5NEt+VrYVAZcgEcp+UDrb62bndoHvdSIOqg3qCMD01KeqrODb3hbjDPDi2T81TPhG8LygjvUVDrvTsN9BsG0btnHqTdh8LKL9idcNRemcvkozvO1qTX16X4SGkg6gCKZPjRcs1+Qmrg4IS+spNH9MykGTW73GCkn3BSrgVNjQ6D36hgU4FeQC1S6SgiAwjVVkEIUCu3DiE5b458WEm5DEmCSP1uYJt2R3ni93f2U/1B/woW5kR4MvhocVtiKPgPN9M7TQIcPYda6X87p8GB+LNsPCYf4EUpzd+mEcgIC3S+Knqhi0ADWI8FawJyGayMMhQ4GS4zMb+ODJYZly2lk/KTWQOWE2jr6cyUrl2VErTPOCVoSh6BeS 1BZBV8p2 2NMHVw6zPeuzsSqsLdrE7W1ljm489efY4bW2dZ70ogFGAM4OjSHIUm7K/8sjnoL7Fngt/55k/R2jabFRJLelD0zPNSLFtB1wzTnhMlg7FswSqtBGHatBoASUm6kGoFXmzQdsusYoaxYy//uix9lYa8jMbIRPE7iVnTxms6pvpMC+hsdOC74Ok2jZ4rTsrcXU6ncOM4a/nsjdhKZuiYy80nXaWvVSvqAhn3SUmF6DyxXOKI2xaEMdfWCpBS0Syi/mvqrzh2t/J7U9Cl+k8Wt+F0vqadeiJd3buZenCBpJAxirDoWsJsv8SicLKOYI9jt5D8Z7UbaGWyQx187XWfjO0J/0EGuREXVkq3mjAW+O1JzwqiD/DpjjRBY+BJbWQJbr0x037pwfOe/M0YbmublO0sdI9eIv72Qgwd/kfBWsE//Sz70nSmqbRHA48mBB3zPrSuCmHiwQVIjCrv7xEmPC36bpEXQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000137, 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 Wed, Feb 12, 2025 at 2:02=E2=80=AFPM Lorenzo Stoakes wrote: > > (sorry I really am struggling to reply to mail as lore still seems to be > broken). > > On Wed, Feb 12, 2025 at 12:37:50PM +0000, Pedro Falcato wrote: > > On Wed, Feb 12, 2025 at 11:25=E2=80=AFAM Lorenzo Stoakes > > wrote: > > > > > > On Wed, Feb 12, 2025 at 03:21:48AM +0000, jeffxu@chromium.org wrote: > > > > From: Jeff Xu > > > > > > > > The commit message in the first patch contains the full description= of > > > > this series. > > > > > > Sorry to nit, but it'd be useful to reproduce in the cover letter too= ! But > > > this obviously isn't urgent, just be nice when we un-RFC. > > > > > > Thanks for sending as RFC, appreciated, keen to figure out a way forw= ard > > > with this series and this gives us space to discuss. > > > > > > One thing that came up recently with the LWN article (...!) was that = rr is > > > also impacted by this [0]. > > > > > > I think with this behind a config flag we're fine (this refers to my > > > 'opt-in' comment in the reply on LWN) as my concerns about this being > > > enabled in a broken way without an explicit kernel configuration are > > > addressed, and actually we do expose a means by which a user can dete= ct if > > > the VDSO for instance is sealed via /proc/$pid/[s]maps. > > > > > > So tools like rr and such can be updated to check for this. I wonder = if we > > > ought to try to liaise with the known problematic ones? > > > > > > It'd be nice to update the documentation to have a list of 'known > > > problematic userland software with sealed VDSO' so we make people awa= re. > > > > > > Hopefully we are acheiving the opt-in nature of the thing here, but i= t > > > makes me wonder whether we need a prctl() interface to optionally dis= able > > > even if the system has it enabled as a whole. > > > > Just noting that (as we discussed off-list) doing prctl() would not > > work, because that would effectively be an munseal for those vdso > > regions. > > Possibly something like a personality() flag (that's *not* inherited > > when AT_SECURE/secureexec). But personalities have other issues... > > Thanks, yeah that's a good point, it would have to be implemented as a > personality or something similar otherwise you're essentially relying on > 'unsealing' which can't be permitted. > > I'm not sure how useful that'd be for the likes of rr though. But I suppo= se > if it makes everything exec'd by a child inherit it then maybe that works > for a debugging session etc.? > > > > > FWIW, although it would (at the moment) be hard to pull off in the > > libc, I still much prefer it to playing these weird games with CONFIG > > options and kernel command line options and prctl and personality and > > whatnot. It seems to me like we're trying to stick policy where it > > doesn't belong. > > The problem is, as a security feature, you don't want to make it triviall= y > easy to disable. > > I mean we _need_ a config option to be able to strictly enforce only maki= ng > the feature enable-able on architectures and configuration option > combinations that work. > > But if there is userspace that will be broken, we really have to have som= e > way of avoiding the disconnect between somebody making policy decision at > the kernel level and somebody trying to run something. > > Because I can easily envision somebody enabling this as a 'good security > feature' for a distro release or such, only for somebody else to later tr= y > rr, CRIU, or whatever else and for it to just not work or fail subtly and > to have no idea why. Ok so I went looking around for the glibc patchset. It seems they're moving away from tunables and there was a nice GNU_PROPERTY_MEMORY_SEAL added to binutils. So my proposal is to parse this property on the binfmt_elf.c side, and mm would use this to know if we should seal these mappings. This seems to tackle compatibility problems, and glibc isn't sealing programs without this program header anyway. Though= ts? > > I mean one option is to have it as a CONFIG_ flag _and_ you have to enabl= e > it via a tunable, so then it can become sysctl.d policy for instance. sysctl is also an option but the idea of dropping a random feature behind a CONFIG_ that's unusable by lots of people (including the general GNU/Linux ecosystem) is really really unappealing to me. --=20 Pedro