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 E5366C021AA for ; Tue, 18 Feb 2025 23:18:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 222D02801B0; Tue, 18 Feb 2025 18:18:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1AD052801AE; Tue, 18 Feb 2025 18:18:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04D772801B0; Tue, 18 Feb 2025 18:18:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D97B22801AE for ; Tue, 18 Feb 2025 18:18:49 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 89CEE1A0759 for ; Tue, 18 Feb 2025 23:18:49 +0000 (UTC) X-FDA: 83134632378.20.536EDD8 Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by imf26.hostedemail.com (Postfix) with ESMTP id 92D48140007 for ; Tue, 18 Feb 2025 23:18:47 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L+QvqAjO; spf=pass (imf26.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.217.43 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=1739920727; 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=cJZKYboTxb8eI3E86OVhHv0iNOUs21llNDOF1MXgUYQ=; b=jzG2hcd8kJepS9cXybXtHVPZahhtQt2zRnSIG2tM2OzLnKk41KnY+2+kwjEFmVuNw29sgt wbqy/ubvLY1c756VMYGxr3sLrkbSys6vVUJP6yB0rmlfwF+keur5Zq0SBc5iK0ppjwxuPM n9U1KPUJPG+bV7yKKXwoYs+0L7ZwExA= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L+QvqAjO; spf=pass (imf26.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.217.43 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=1739920727; a=rsa-sha256; cv=none; b=EGeCZJE3vjPmbYzDXcKrL0GCeRqukOKmFpCgK8xcCGPbyWclKrBu6rhC9BfxOp8MLwyxdH su6qH5Xnrw5BQogFRs4j8KAAlc7AXUX16ZhEzWsZJHEUAWuBJbtJcC7Fojs+fI/iwmITdA KKi60Y46zySWmLie5i0i8Lt6VWnnx2E= Received: by mail-vs1-f43.google.com with SMTP id ada2fe7eead31-4b9486a15a0so188357137.0 for ; Tue, 18 Feb 2025 15:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739920726; x=1740525526; 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=cJZKYboTxb8eI3E86OVhHv0iNOUs21llNDOF1MXgUYQ=; b=L+QvqAjOLnKw0SwnNfpeG//aw+jYnqOexy2zdiqM31RntyNCM7dK5EVvGnYr64Uopv /lNt4HgS9F4rVq+5mWMowvF73nln5QOndMWCNARrcdgSM4UR3Yve33SPuLlIwiRSS60H avBHxI/6Rf9oFBdK7b3AEqwZrZxpxJkrBZZGYJ/iwcILHXqHDY+FJeUSYVJCk76NhoDq /LKF329G/kxoQYoKfqDpub/tGWMtFd309meda3Rbfri7QVHZqRCGmVWLfmg6k8zB94hf G+Jyns4WO4tf8quVsQYlfNf4F1YIO7zejmYcaPX+kbloVMs5k1hjefe698gaXPSoo9Rt YAbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739920726; x=1740525526; 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=cJZKYboTxb8eI3E86OVhHv0iNOUs21llNDOF1MXgUYQ=; b=DpaA9RXtpecN7Kk1OcUczP8Znisw3Hcg0k7iJ3DAaDs9V/bWXXWTg8nd2YNw8533zM 7MeJaiWBlOJbE5p1SImQ5u+AkwHGuW8avZLM0sc4UacM7QW6FteRIejlM/5sDboy3CRW iYAL3+m8jxHsrVhvDF9jCjq6IUNer4zgWvYBSXwQr9yDmZH0ppySpfCQ7hN8+RBowq2g ANKQeW0xA1nWXRUGqEhCdriSN3YBhQ9htK2ffRB1NdhOgxo41uqI0OA/GbLwVONIO1qk mtX/mDGUEGEmNoOmD7Y9wyExaxmem1mLFvrfYF23nTq7DAvA5kGtoE4Aty+RzDiTaTPY uo7Q== X-Forwarded-Encrypted: i=1; AJvYcCWIKsO6L7b+UWUTk7fFQIqyJj0h1EAaQyDEA5Wb+yz6Gl/g64RF271zlIaXrIIcBvwDnbCWLxZtBw==@kvack.org X-Gm-Message-State: AOJu0Yzs8sI24fz9JbbyBYWKCUPYrz3c10nFm2KlHXDURMohwL7tXXT4 1I5Kj9vpJWb6Yd99zUmDHk+cIqihVRTbEgWYtG2Y3tPOPGHsMKFoRnxVirYZbjc9LKUSi/PoV6x FSHc8v4kUUzgQirOjE7kgCDhZ80Y= X-Gm-Gg: ASbGnctbarqt8mEn1P77kBm8L7YoqNNmtJaMINdNPTGP2wNM1NSnT1/W2u5Z9sKfm8j 6UHg0grxLl8to94bOGO8mhQ9Tyt4OvCU1blFJ1mtpVz3iEsnn1PByGgSY6iBhkj0q+oxnPlemt1 75TR8B8kC2hJX42pDzhMv1nZxirKwm X-Google-Smtp-Source: AGHT+IGKGQRQAl8RdXEgVYEV0wpJE87L/FaWCi6brr9B7QBb3fpm0Lts0CWlx0AMzHd2VMZ1ZcRSNSvzuIQRVBJawkc= X-Received: by 2002:a05:6102:f10:b0:4b2:9e5d:baf with SMTP id ada2fe7eead31-4be84525188mr1413338137.11.1739920726529; Tue, 18 Feb 2025 15:18:46 -0800 (PST) MIME-Version: 1.0 References: <20250212032155.1276806-1-jeffxu@google.com> <7545d5eb-a16e-4cc8-a9e3-5431be01aade@lucifer.local> <202502131240.A57C749@keescook> In-Reply-To: <202502131240.A57C749@keescook> From: Pedro Falcato Date: Tue, 18 Feb 2025 23:18:34 +0000 X-Gm-Features: AWEUYZnpYHWvn6nqeVyLXVg13y8CRbOGKz08G_TnkGN6y5dwD6CgxjUxA5BE0y4 Message-ID: Subject: Re: [RFC PATCH v5 0/7] mseal system mappings To: Kees Cook Cc: Lorenzo Stoakes , jeffxu@chromium.org, akpm@linux-foundation.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-Queue-Id: 92D48140007 X-Stat-Signature: atotjg3etau7se33s98adufwtdzix3ru X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1739920727-297643 X-HE-Meta: U2FsdGVkX19rbE5LlM1FW+XWktiYXtIiPVkQCzKzaN12DxmngWc5qTGY5qt83ocKNcBtr5y47BUrpKEPXUtFhWhZSPXpU2h4nzJDwfSJm/TLTOrHkI8f+SxstCBxDT3XC1JAxGZRvzYgMIwUg78xXYzEx/D8OPJeS6oYNxPSmeNXt8LGBC48Iv3ZQofsFhKEQT9Hk+lz5vw13dORxqEdJs22CUcRvem4gt0nJq7QtLo19Z1jnOAP7c6dYnhoQtSingoxJ7JUadbv8WZKmmwI6xMDMPTkoPXEPR5sSBYOHF2BDKvHAfrUhepvlSqa1pWGKPvrVMdx5fHPkOVECfpcgoabw21/g4DXKNdHRoU6AyHZO6wT2//QqWVk6ggN8Glf6GlGpTmWvDN1kHUkyCIa+/yD4+GgKUkrY9eUL87OQjSxUSC7c40iKvjYP87fttVos9ErqAfZL1YJxXid2QkYb60b84F2o2LHvXyfS8RXM3PomWR2Fr0lVEsXOigq22s0nVFgt2+ZvOisynBOgTEVnblLY0YxXdr2Zyq7crzIsVL2PO8C1kA3aeVMFl12IrqgI9AliU+q2jrVEI/N27CXu2WizvfIA2K8/0E/YcP1zmtkRacoV3EVD1C3qj9gTOBEfoRaspgfmJiPJRFnICkxodllau8xnWIwih2sEV5yJ3ZbsF1yD6npSQBJNf22t4HVvCNFXa7HuIsfdYmM57rQp4B3qMmUYd1nLk7uEP7C7Dy4IE7M4yc1pwcamhSrbP0qiTMvtE8E+q/kWu+qjl2oVlIbo6UzL+oSM5kM2evBy4tsMX0L9QYnUmrtgu1lR0fm72W4IkY2WrrnJ5U0jo82e21tttYl6cEdfo1FzdqYFW4iwMpPk3VDKAQsEtTmxwj0oMpbKbJkxxvoTCU6PXckHbqjf3eEjnWzIgMtoqxZP0cDln2yyt+/HIIQBhgDByl+BJ0Qcwxf0NWpHSQzn2H EiUyI+wx lVv0WCfQQ58eizo+knhoTyTtqTHCeX0vxYaKTyPdoU/n7JZijEpTvULvMWV1SV12T81HgTFoySQFtlIoyc4HIML4m2sclF5WKnRMlU4HDA3QAcKXz8r9p7F3oZXgMc61IJeZe/jFsHzf0vCmYd4ZHTYNguGvNEApzXorQdmrqSSMlw2BinXeRASVVuc/fdcNZ3IslH4WW45bGRNs678fJlbEw7ubh2B6BOXjGn+LWIg6wdSmk5FRu9G5pflpYnr1bmIb8YYOTee6OTOEm6MWg+S1ucGIEEgCrH/QC9nQP7Psm5N9/i/6lyLM+Igl4SBIzK11Nf98wpQMnPcLpm17RgTvR1PVQrM8B5AS4u3VJ2KddU9gqsIEb5QRpQlpvz+sv9TY0MihynamHqb4edazQs05L2o7QrIfhZhS/apJe4p2d5zHSY+JCRQVtGHqDb1gSjQfxPO4w+xanphOxc3MF0jc7i3n5+sV2+lpDjGB0afMBFs0d6yNJ5zCO7w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.006755, 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, Feb 13, 2025 at 8:47=E2=80=AFPM Kees Cook wrote: > > On Thu, Feb 13, 2025 at 07:59:48PM +0000, Pedro Falcato wrote: > > 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 wro= te: > > > > > > From: Jeff Xu > > > > > > > > > > > > The commit message in the first patch contains the full descrip= tion of > > > > > > this series. > > > > > > > > [...] > > > > > > > > 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 CONF= IG > > > > options and kernel command line options and prctl and personality a= nd > > > > 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 triv= ially > > > easy to disable. > > > > > > I mean we _need_ a config option to be able to strictly enforce only = making > > > 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= some > > > way of avoiding the disconnect between somebody making policy decisio= n at > > > the kernel level and somebody trying to run something. > > > > > > Because I can easily envision somebody enabling this as a 'good secur= ity > > > feature' for a distro release or such, only for somebody else to late= r try > > > 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. Th= oughts? > > It seems to me that doing this ties it to the binary, rather than > execution context, which may want to seal/not-seal, etc. I have a sense > that it's be better as a secure bit, or prctl, or something like that. Th= e > properties seem to be better suited for "this binary _can_ do a thing" > or "this binary _requires_ a thing", like the GNU_STACK bits, etc. But > maybe there's more to this I'm not considering? Doesn't this exactly kind of Just Work though? "This binary can do/tolerate sealing". I would blindly guess that we don't have very opinionated shared libraries that do this kind of shenanigans unilaterally, so that's probably not something we really need to worry about (though I admittedly need to read through the glibc patchset, and nail down what they're thinking about doing with linking mseal-ready and mseal-non-ready ELF execs/shared objects together). The problem with something like prctl is that we either indirectly provide some kind of limited form of munseal, or we require some sort of handover (like personality(2) + execve(2)), which both sound like a huge PITA and still don't solve any of our backwards compat issues... all binaries would need to be patched with this prctl/personality()/whatever call, and old ones wouldn't work. The semantics behind GNU_PROPERTY_MEMORY_SEAL are unclear to me (maybe the toolchain folks could shed some light?), but it sounds like it'd fit perfectly. I suspect we probably want to parse this on the kernel's side anyway (to seal the main program/interp's segments)[1], then extending them to the kernel system mappings should be somewhat trivial... I don't think we'll ever get a program that can't cope with sealing the system mappings but can cope with sealing itself (and if we do, we just won't seal the entire thing and that's _okay_). Deploying mseal-ready programs could then be done in a phased way by distros. e.g chromeOS and android could simply enable the corresponding linker option in LDFLAGS and let it rip. Other more mainstream distros could obviously take a little longer or test/deploy this on all programs not named gVisor and/or after CRIU is okay with all of this. We then might not need a user-configurable CONFIG_ (only an arch HAS_SYSTEM_MAPPINGS_MSEAL or whatever), nor a sysctl, and everyone is happy. I glanced through libc-alpha again and it seems like the glibc folks also seem to have reached the same idea, but I'd love to hear from Adhemerval. Am I missing anything? [1] we should probably nail this responsibility handover down before glibc msealing (or bionic) makes it to a release. It'd probably be a little nicer if we could mseal these segments from the kernel instead of forcing the libc to take care of this, now that we have this property. --=20 Pedro