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 6037BC021AA for ; Wed, 19 Feb 2025 17:18:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1497280248; Wed, 19 Feb 2025 12:18:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BC4CE280246; Wed, 19 Feb 2025 12:18:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8C54280248; Wed, 19 Feb 2025 12:18:13 -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 89374280246 for ; Wed, 19 Feb 2025 12:18:13 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 17F9E1A1BFB for ; Wed, 19 Feb 2025 17:17:57 +0000 (UTC) X-FDA: 83137351794.25.788BA27 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by imf10.hostedemail.com (Postfix) with ESMTP id 21FA7C0017 for ; Wed, 19 Feb 2025 17:17:54 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ojnD19Gq; spf=pass (imf10.hostedemail.com: domain of enh@google.com designates 209.85.210.53 as permitted sender) smtp.mailfrom=enh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739985475; 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=OVEokc++S9KH6ryzdoMossQu0Y+z5+h9xa01Nfet8/g=; b=8Xjd8RyLiiDh2FAYTBK8PcCZjQ2g4PqO6T6t6tvbekWY4K4WoDz0m6UmCNt9Y21ejtbVtg VoGXTepwXOrUQBP5ptLVrIyvgIM0NcsN8L9Omb6xgzT6b7wPcK72Fs7UoKXO2PItUyDhTJ jx3cOvCkH7NAA3fl4+gmJO7R6HHcHws= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ojnD19Gq; spf=pass (imf10.hostedemail.com: domain of enh@google.com designates 209.85.210.53 as permitted sender) smtp.mailfrom=enh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739985475; a=rsa-sha256; cv=none; b=TyNQZsvz6ddCmyT+OPslN/ctsobpii25hkyxe8p1zNYylh/dPO2N9UkXugYKbtekS5ksIk 1/MhJ8AIhS4nTIFkvSaSIgnGIaaqOly0ntQRyiVKMr+eOSETT34TB1mTxDu5BfBqZJKjTQ E98uh8LsLc2E6T1OkM9gIaJ6VoRcFvk= Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-7272f9b4132so5928a34.0 for ; Wed, 19 Feb 2025 09:17:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739985474; x=1740590274; 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=OVEokc++S9KH6ryzdoMossQu0Y+z5+h9xa01Nfet8/g=; b=ojnD19GqlMjKSa4mP4yoLbEuD25e97yKXfdgehqAmmaA83PDThtXk1+kDsGDNaQ/LH uZTmLThVG8EzJuwd470ZnyxbHFtIeB15EEgQ1klLqDB85jtn/coe1MJaV+kWBkDC2RNK FWMQkyK4zEGDdc6BPlJKmIk3qDsOQH15O+1XbElNGjNGb7/dCJaJvd0LLYCDCdCnuzdm p7bZNLgeV5cuSKCXbNd2ks6e+uekz6FFX71stImy8hkwfYoOiw35yuzJRSpFwKqQxBUW Dsc/M9UkqZBCdFLOqdfFGsaBVe+XLAAsiU3qEIAygq92IF9hdIqNflYDJggbVELaL359 zxMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739985474; x=1740590274; 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=OVEokc++S9KH6ryzdoMossQu0Y+z5+h9xa01Nfet8/g=; b=eU/TJze3Ebn++RhxaVZYnntOgPUN4HyVJpJY8H+T3P09HjsXV7zvzEC/vnAj7m40tn nCa1yRB2AYA39HgJyPquRD/h123fFrZubmgesuWExl9ahzhEiedxpTXmfJ8IW97rkM8s vo4hfMJLMzd/jfaCv8Ejr9fy8lZn6hwKiP3VDgl1bsvDO+yYlXb1rHkaWgNB5xwBZ7uT IfVxCPyOu2qp5oOdPyBOgdF8/fPGRfqRiYyNgWCwgVCR48WxCDI9b4YU5celdyFRYc2N s1neuKSmIktWoQbo4RGOu1yKJXw+i0/ELMXZrqovfL5Ul3kullY1wM+WRp6yHKLD398d Xf3g== X-Forwarded-Encrypted: i=1; AJvYcCV4F5dsJOAJDH8OjATAN5qwydLSGZGIKfeD+hasM7DbtjzArpF6NzHMr+CDanM16Amio91gotOCCw==@kvack.org X-Gm-Message-State: AOJu0Yx4K0cIglGX1tPErDR+XE1tnxGynrzgU7UPhuv3yo8V63KKzc7A bTeer7x64b2m5ccNch+9zmwMl0HXV9TS1lDs1RgBE8onMCWXVYRklx6lJn9sPsVK1qJPV9gNZAF DEQpfbyjbaeVXPsbBsZB85WiKTHB8vGbpAnYX X-Gm-Gg: ASbGnctvsoqb8X/B+YdpAQV23XIl7bAQWnR8d7qtNJ7yYeyn4Idrs6SP0wZK5SDKf0B LK/p0LwrGTBGlqroXOUy1m3nkyar0gcCjCeHrd7erzRcumlcdyyDObJXXeQdx86LiBGpUjw== X-Google-Smtp-Source: AGHT+IFtTKY1jDjL5dUAYxyA8Qit+rF+HdRs0rA/paAkjRr1rXODcHay0xhy+IxufTt79brO1JJ/4wMTQIJGiFmJfCk= X-Received: by 2002:a05:6830:388f:b0:727:1041:4202 with SMTP id 46e09a7af769-7273779be8emr4220238a34.21.1739985473786; Wed, 19 Feb 2025 09:17:53 -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: From: enh Date: Wed, 19 Feb 2025 12:17:42 -0500 X-Gm-Features: AWEUYZkrJhHGOE4gkmIH4jm_-jQkhQ0BXH4tsu9GjGg65iZ6RBKYUV0BMKZMxwM Message-ID: Subject: Re: [RFC PATCH v5 0/7] mseal system mappings To: Pedro Falcato Cc: Kees Cook , 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, 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-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 21FA7C0017 X-Stat-Signature: rxjuoiryt4b15n5xcppguburxjr8w9ne X-HE-Tag: 1739985474-619607 X-HE-Meta: U2FsdGVkX1/dAffshy3qaMeR2w+jUritWPe3tmXcs3AKRV470TsC3qljWPWdQopefxv4ujVSqFe/Nfgctf+evQ9x5AtB4SvkYzZeD+edhjBhwkjfb8j0oh4nUAL+UNfmQ7aikj9B+PofgpmQik/Ae7U7i1KbfKIZU/hcpVzS1lD1IphpGkqO3snKr1JzsjfJG1fmIn8D9MT4jLW9KjjmwKnx0G1XB0C3DrqElgfGwdkig2Mu9uaIKjKShg8CPPi+g/tscbNtkESMcFc2+qMnneWjdmlgGl7WRYWxvdGXE3K+vTPSlsbGULXcmxrN/wk1OiiAsFI0xl/O911gKf2G5uKxHm8t3A8ZOiXDhSPgJe6ZG3755y9l/7xsMNxaNwhfiGGbzCRDFByAQtxZ/CESX2uYBBvzjTR/JJZGWJaCYT4qucHkZo7Q4HMpOSfjCzT2kB21K1o9kAibxk5WW0MITFHCHFINty6p0mH9Kan2OyS88eGINVr3JhbzkuPZBFwDxwpsxaQTU4HcNfFR0bM9OQTT/k3/WTDwPZCr8WXyRqNHjfBKbyUY7iOecfsTDCbRk6scsHtMmEurr5JuCOoFqxtiq2Plj/tT6M/Qc9RcMmsQIhGM0f8LauGsUHgzc4iIvhwpicWKy6q/UJCgT2jQ4P5f5+J0ibBzYE4CDTPp9FS6QLGVJsQGqQ2bJVzjNV5+ymclfjgFbE1HvXyiBRTFQi3QD0Rfw9ibylOKhNtBv2SvGStskWt/TPuYzductXXdkmWzdDwuIFmz96t/4+doZVFC2Y7J7V6XWdpmcsS39tM1Gk1jagzdyMwqK4ER18ZutG7EnT96c+lh1lJ9ZFxRvXGlsPxGa0IoNnjqGpf5jIidIFkkCtngG+J5v1hSuhj1HPr6aEh5v1Z67A26zJEh58iL+pXezdYD7VDLQBsM3bUnkg/uEhKt3yXNJl0rdzEUG6k/gW3OqUPzN8AbpOS jlpi6Vu7 TqgINxfmFCjTj1lYHcSCiy8DMeY7lkcD9tF7HjfiCpfqttzilxtj9roAa1A8kIn2wAy8fuke5hlnezkBMJBUEtVgtyzeLMB9JjCFpr8P2crbsr4I77r4WbRysU1/Ao+dgBYctQ9cJlGppTTD5LW1X0iGYqE+CIG7np9VRlNBj2f4QRfoMlKsIdd4B+wxFvU6Wgg6AcH/FFOB6imIsR4C6K12QagHt3M3f5i39q7OkMPn7FSseten4+iSRs1iF58uU0Vl+10S+52hQk271DmbjN1xWdC913WBCbX3pfeellDgG8qShmMyTrx+dkT3+MiVjjj7ZCA8S29IyLbFLu9TW6T2Vcf2JzKxR4z7JGZcfujzbk9Y= X-Bogosity: Ham, tests=bogofilter, spamicity=0.006874, 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 Tue, Feb 18, 2025 at 6:18=E2=80=AFPM Pedro Falcato wrote: > > 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 w= rote: > > > > > > > From: Jeff Xu > > > > > > > > > > > > > > The commit message in the first patch contains the full descr= iption of > > > > > > > this series. > > > > > > > > > > [...] > > > > > > > > > > FWIW, although it would (at the moment) be hard to pull off in th= e > > > > > libc, I still much prefer it to playing these weird games with CO= NFIG > > > > > options and kernel command line options and prctl and personality= and > > > > > whatnot. It seems to me like we're trying to stick policy where i= t > > > > > doesn't belong. > > > > > > > > The problem is, as a security feature, you don't want to make it tr= ivially > > > > easy to disable. > > > > > > > > I mean we _need_ a config option to be able to strictly enforce onl= y 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 ha= ve some > > > > way of avoiding the disconnect between somebody making policy decis= ion at > > > > the kernel level and somebody trying to run something. > > > > > > > > Because I can easily envision somebody enabling this as a 'good sec= urity > > > > feature' for a distro release or such, only for somebody else to la= ter try > > > > rr, CRIU, or whatever else and for it to just not work or fail subt= ly 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, an= d > > > mm would use this to know if we should seal these mappings. This seem= s > > > 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? Android's a bit interesting because there isn't really a "binary" in the usual sense. an Android app is basically a shared library of JNI code dlopen()ed into a clone() of an already-initialized Java runtime (the "zygote"). that said, i'm not expecting sealing the vdso to be problematic (even if i'm not sure how useful it is to do so, being unaware of any exploit that's ever used this?). for me the tricky part is when it's used for regular user shared libraries which seems the most convincing use case to me, albeit mainly for app compat reasons ["stopping apps from poking at implementation details they shouldn't, which later causes breakage if the implementation detail changes"]. the irony being that it'll _cause_ app compat problems by breaking all such things all at once. so that'll be "fun" for someone to try to roll out! it also breaks dlclose() (unless your dlopen() was with RTLD_NODELETE, which is not the default on Android either). that's fine for OS libraries that have already been loaded by the zygote, but hard to make a default. that said, i do expect games and banking apps to be interested to try this when they hear about it. anyway, in general i think an ELF property per-library sounds reasonable, matching what we have for arm64 BTI. i have no strong opinion on the system mappings and what if anything executables should do, for the reasons given above, but the elf property sounds reasonable. > [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. > > -- > Pedro