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 31C70C021AA for ; Wed, 19 Feb 2025 13:47:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD9BB280231; Wed, 19 Feb 2025 08:47:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B897228022F; Wed, 19 Feb 2025 08:47:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A029B280231; Wed, 19 Feb 2025 08:47:04 -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 7F3C128022F for ; Wed, 19 Feb 2025 08:47:04 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 089E7141A54 for ; Wed, 19 Feb 2025 13:46:49 +0000 (UTC) X-FDA: 83136819738.24.888A90C Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf11.hostedemail.com (Postfix) with ESMTP id D28714001B for ; Wed, 19 Feb 2025 13:46:46 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=a4c1nXCO; spf=pass (imf11.hostedemail.com: domain of adhemerval.zanella@linaro.org designates 209.85.214.175 as permitted sender) smtp.mailfrom=adhemerval.zanella@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739972806; 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=ko00ndovSDIn9wXeXsjiQM4wpEigh6jTkcvJNJZTbVw=; b=q3Blwb0EAPHRbbshUYiHhxpBf3OH+Nh9QAd8DoiU4iTDMzrS2EPa22XmF5ZbRcHAAn8ltY uv9+V4X7H7+2LQajh1Kd9frYhQzo1+xt+1TUoye6eHm0cU5FnTHjw05ONRYgjAsRF5MwNT I0s3s1vzbCugxF/5JzoyOOKNQV5+4Po= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=a4c1nXCO; spf=pass (imf11.hostedemail.com: domain of adhemerval.zanella@linaro.org designates 209.85.214.175 as permitted sender) smtp.mailfrom=adhemerval.zanella@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739972806; a=rsa-sha256; cv=none; b=3FOnxRBvAfloGzPFrW4Y0gfaDziyk2JH+Imo0b5OFSzvFdDgVvFQRjXsC0KWG0D+r+EOsT +MRf58U11KEBx9F2IU66tX/5z7kZSgxpDWfJNAiqn2wGJiOvBLnBQ8VqVJ4Qup4ZrcctnT xFqKHTypZ2YBzrsnIN0jPcPO1GNXILA= Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2211cd4463cso70634785ad.2 for ; Wed, 19 Feb 2025 05:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1739972805; x=1740577605; darn=kvack.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ko00ndovSDIn9wXeXsjiQM4wpEigh6jTkcvJNJZTbVw=; b=a4c1nXCO9kDhyYmnzwc3iAJmDNgQo7g9nm9oQRYrrdE8RSRP8r93wMNWDzWLTyp9HL JxenG8bphCWfmZQyCRPLfCAML3xMaxWOUV3IZ8HVdUnFqmVn7N6Aoh99gIVWV/ZPUHdT 25ucK+6EwVqgmO0cVYQ2iC7P2PocVx7yWV8/bbeLT+933ZK7hqjTdR5VXjCj+4O+iG6Z X7tsmRoHO9dCf8xAJMFDY9131pQjmJSynR7sE1FLetYCr5sydEiuv8vMiJXwkF31mvyo 1qQ+KrTeXzQ3W0qNojA4EBMwPRUh2SMLjrawTsEvFeS1BYSfua1ir/RtmkCL1tBOpcxt QZHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739972805; x=1740577605; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ko00ndovSDIn9wXeXsjiQM4wpEigh6jTkcvJNJZTbVw=; b=JIngKt4WH0oJmYOzTV+mETdYGbdrUYiTRVHzxK59Hvp5z7VLuasb+hYvSARiQaixUQ WgE5KD9a2jNbb8GBZL4dF1qo3XH+rG4xScU9V5YOefIi1RBXEQyFaIRiRnEmBKhkQDVK wej2O2wrjUAjNwkTV74F9Ag/dr+xogkyi2slJ6Je0YSgN/vMXBv8FQoV51/c6Q3O7w8p ha9Xh0Gg3JsZeoWD1Vx3cnpt5w1pYt9bdJDy/yg7lIAUufpPM7ZcvxX3zJxKjTMJRt2O QsJBRgbEmUwj0hRFE1CXa3lhU+KGchqn9DAt8gPz3DjQ9bAJxf4US9tJKiXQHiLV0H2L 2J+Q== X-Forwarded-Encrypted: i=1; AJvYcCVFcFHC8yWYY9g7N5MO97OusegMjamYE0qJxTiYkQx+EZNdYfIFhvPU1LOmwFA39dZTKpXr7gPUNQ==@kvack.org X-Gm-Message-State: AOJu0YwDxqk/23TIEc+8aq6tcMWoJFq1+2VjKiDf5+Z6hpfTH9C+86cm 11amt48Uu+d0qfBoDjNNBu2CcmXZX90DbVqp65u6sWJVcOMntmzt24Pyzu+fOGU= X-Gm-Gg: ASbGncsD2A/EFBO4fk0gAqhIYqVV54Nlbl72lSdFI6oP+JLhMARBl3ygAcfLg18YOwV YbwxqWZ7ngYcsCyR8MW+rZqNM1XwTJlo2+vPSXg/NIT4j3K2+SBDTHhnGxuGZaUa+4QPIhiiCBC Z/5lSK0gSwfeqBkt9S4GLH3Ds/4x/AV3MKwQk4sqIqeJMuqPzbe7uixlol6f4aaVvrohBwsxg+1 35ytubvPVjrPSI4abxhMcDumGygwYbLOWfcAwBXlr1AbOdLWzV3xkWo+8upjK5ctkKuw0A+Ihcj TJGXRi0uwzcE6Z4V1owPukjhyebfdk74wbtkHsuvGM2LZ6GfgYa1mZ677DdxZW+nHp3S/LT10i+ 4CC9FagUHd405ZUw= X-Google-Smtp-Source: AGHT+IHzud8yErWxQizk2X9LlTm6NcH2o64l3dhMPpAt69MusAto549t5CGCBpRameWQHlsswQzXpg== X-Received: by 2002:a17:903:2cb:b0:21f:7082:1146 with SMTP id d9443c01a7336-221040867e8mr282114035ad.30.1739972805371; Wed, 19 Feb 2025 05:46:45 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c3:f704:ed29:494:9f22:f6c5? ([2804:1b3:a7c3:f704:ed29:494:9f22:f6c5]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-220d5584dccsm104054335ad.205.2025.02.19.05.46.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Feb 2025 05:46:44 -0800 (PST) Message-ID: <191a4cc2-5c35-43f1-aaa4-01395299590b@linaro.org> Date: Wed, 19 Feb 2025 10:46:33 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v5 0/7] mseal system mappings To: Pedro Falcato , 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, 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 References: <20250212032155.1276806-1-jeffxu@google.com> <7545d5eb-a16e-4cc8-a9e3-5431be01aade@lucifer.local> <202502131240.A57C749@keescook> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: ywfsyqr195uau4xesks9yyn77djbhdqm X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D28714001B X-HE-Tag: 1739972806-464981 X-HE-Meta: U2FsdGVkX1+1AAG92EOFEiYA9Z4zQCUJTG+NbfO3gIdgRsyB/jHkeUFJIIvQU+DuG67slYR1mzcsjlS0a0Vo6XCv3O2IIo+jxBJECjKMEK9Og62TcY0p5KuNjFcOYSsgOD5GVjq8JdswTdQY3iswFKxNau99FuQwOrqcn/0J4JPKXo9GGTnaH05ruieCxN7i4R7vtBePBVqfdeyFWmQ6Bdew6KClw1xvQgX2vltJL15UfvTR6XSjuRkMrnsvnIxHn78uRguJgT1LrIIEyyFJdXAiLlPcs681VoBhI9k+mK2rPh1pmUhc4JheT1VCJjDjNY03WSw885q1Jgut/2+Z4Y6l3dJb6tMT0a8hMuWzfCBZXO/LpRH+V2cEI67q8AzWrBWcEq0UE84kbl6dcqwRcp1/N4zXKwll/Q8P84hrSke+bu79UoF/ATVEiQMaWxGw5hkip7H9qy5rT8pyEUG3HC9NAg3EmQGpRGFaLV0xZNfRRjOsHJ/NspSTat11cE1qfh5P/0UWVi3EusQxFs6LVmUFximtCrst/vvDwb3TCEys4B+8Eog1q6iCGohNGqGkhvU2ukjElHai1/l+hRLmKvIdtcRjDe2EK40TX1JBrV/dwXSUFDXt/WTkZhBPIvUaUpizVla/e6qsJjz/slKfV2v4n8Xoy4T4WgvFaNp+paDGAVfKtGHo2yuijQoST/hUwJi+g/OE1xjpWA1QLMATDoeWrLi4Ev/AvtGcB8EQ6W+6f0b1BiJUE+SpGh7Nk7l3jOh8o24kOof9JUQh8d2qQUScAX4nqEa2G+3NOIMDQMVPXNH1J3kSoslA1cGdDdXqtLgje7pMAh+dQrAy4DNvnfrG0Y6fnzmaU45ZG2WfSY318D6wBnyUQ8D9lK3nHoZgbiDRIY5K9dIbE1zzge/8SkS/ffMHg5Hk6pyJ0dv9YTScIzLpydO3Xh1f0ShS2pQ3RUCqtR9ITE43JVCxwdI 1vTXmbsV 6KIiRWYE+lQUhRO2gK6HQV/NQGyL8AfdM1eBieEQFdWkvevXq3KxSJuS44uCxoje/vBHMdIwWZQDAdpHMXVZW/tMwQH0m+l7Rzhjg/Bp/JMu68MjpDN79B4C212dR1FaEFfMF4521JPxl7Fw4GuJ/KvdmhZqDGOkyrhWJsT47LxA0Dz0df6N5oE/nq5hLkPIZpCUFcMbgk5TcdCcW6wz76gcVx3x0OTDtSQQfNz+WGQn7Ac35Jlc7g6wmy6uzWiJGEnPAB/jCUwYD89mjk+NPwAmsZaZ1cc8UX9E2NbygK3ZE0z10GIecug1gJHvNJrvSXp3tTLp7M4BLA0QlhGWdmKgGQUsNPt18WagIPSj2dFM2H1IPCOYYq7SKhVXMZoK+V607u2aKqn7DOUqO4cdX9DGkdi/GVLH0fjm1CU1Pyb18eZGMO/DVnHE5GO20ZVvACOpGuZsVFg+shfAAlAAiNNGqrafFvxz12IAmstYlotY6G9SdP4jKA7FwDtMKeRM33+eN61WiY9xyXI8x8210V3AZVTsxvKLuUKRXn2Pkxcje/gXd/WUeBGouLpjykTRPU4XNst+OLNHLEup2NqUKYg2VOfJFV7cxxCtaVD0pYDSbONe3TMrFESVXvg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000134, 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 18/02/25 20:18, Pedro Falcato wrote: > On Thu, Feb 13, 2025 at 8:47 PM Kees Cook wrote: >> >> On Thu, Feb 13, 2025 at 07:59:48PM +0000, Pedro Falcato wrote: >>> On Wed, Feb 12, 2025 at 2:02 PM 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 AM 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. >>>>>> >>>> [...] >>>>> >>>>> 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 trivially >>>> 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 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 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. Thoughts? >> >> 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. The >> 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? Hi Pedro, After discussing with CRIU developers, I plan to change how glibc will handle GNU_PROPERTY_MEMORY_SEAL to allow a more smooth enablement in distros (the latest version is at [1]). The idea is only enable memory sealing iff the main binary (either ET_EXEC or PIE) has the new sealing attribute. If it were the case, the loader will still check if the dependency has the attribute and seal accordingly. So if for any reason the binary does not support memory sealing at all, like CRIU for the snapshot restore phase, it just need to be built with -Wl,-z,nomemory-seal. It is also for the case for libraries, although I think this will be rare. I will also work on adding a way to enable partially non-sealing sections, since Florian has hinted that he wants to use on some libgcc metadata (similar to how RELRO '.data.rel.ro' works). My initial plan is just mimic what OpenBSD does with PT_OPENBSD_MUTABLE, which only works for ET_DYN (and I think it should not be a problem). But it is a userland problem, so no kernel support would be required. > > > [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. > Keep in mind that GNU_PROPERTY_MEMORY_SEAL is currently a glibc extension and I am not sure if other runtime would be willing to adopt as well. So its presence can not be implied that sealing will be applied by runtime. [1] https://patchwork.sourceware.org/project/glibc/list/?series=43524