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 ACFB3C021B2 for ; Sun, 23 Feb 2025 02:05:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 398246B007B; Sat, 22 Feb 2025 21:05:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 353556B0082; Sat, 22 Feb 2025 21:05:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E8F36B0083; Sat, 22 Feb 2025 21:05:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 003DB6B007B for ; Sat, 22 Feb 2025 21:05:51 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8D3E3121E05 for ; Sun, 23 Feb 2025 02:05:51 +0000 (UTC) X-FDA: 83149568502.18.630C3DD Received: from mail-oo1-f53.google.com (mail-oo1-f53.google.com [209.85.161.53]) by imf24.hostedemail.com (Postfix) with ESMTP id A1CBF180007 for ; Sun, 23 Feb 2025 02:05:49 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=XHM7Ulzj; spf=pass (imf24.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.53 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740276349; 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=/2XEj1hbiH6o5CDpfSnYdqt5AMNqF18Pd/CIj/Ve+KU=; b=bHH8mF+v2lxOqe4KHq6PUg4QuOyXUEqgr73mnwbCvgeZ+KCF1SLnrbDUHKeijtizRwZ2TR vBOzUoknto2DufnnK/tjxfhVD5cGfMkxtrK8IdhtyXso9ymIjoWe4vO1sKrQzzhe3/qMHx xmDylOlByWC14JY60DLQj0iS56TLxhw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=XHM7Ulzj; spf=pass (imf24.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.53 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740276349; a=rsa-sha256; cv=none; b=W+Y9siXR8ZDJBehcR9W0sdm+X3hiLTCdYX1V1NugkAa2aEYpJ1JWUF0lN9RmyZgjVr4iHR St4ZDjLI0DH29XNlymH7vMNeMKjwkiei5pb4i0q9kMGhrk0IOTHGCvY47jRSNVK4rUdpVf mDloL1CA3PF/5zAb2AP3t9b1f4IRONc= Received: by mail-oo1-f53.google.com with SMTP id 006d021491bc7-5fd31d25ebaso28151eaf.1 for ; Sat, 22 Feb 2025 18:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740276348; x=1740881148; 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=/2XEj1hbiH6o5CDpfSnYdqt5AMNqF18Pd/CIj/Ve+KU=; b=XHM7UlzjV6EnR6SVIyOWn+zEW+FJGOua650pao/1rbh0XOWeotJI82u6pNcO2/zTLG TRG8BlD45zdsuf/hQV6L7Gbs6FaCfnCrXXoakyca85BQnYoUf3G8uPIsjArrF3o4as0s bKoaile1p9Bw6iQMjKYH4WeiKE2KXFFwDVtcI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740276348; x=1740881148; 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=/2XEj1hbiH6o5CDpfSnYdqt5AMNqF18Pd/CIj/Ve+KU=; b=EMGzxfcdApFbW7U+a7l/dVXFj/oVN8fCV9clUpKxkMxdWjsQilfMprd/VBySc3KWjx pI1bS1sJJ05qfq9xhnG+X77I417Vk4ZvMk6DOCfRM/tcqQAIUGrDVURbJfRltpKt5obU Kd4XqkASLP11JcI53Wrh57fOizsuRK1u6T7ahbbCW2kW9F8PiIF+Av/Cm3xlTdlbQE1o b1x+7jgnS/N99YHXnui0cpYvycofMeSIu4p6cn4lkrTSxrjdXrzJWMNhGG5qwjzd8dP2 6txtAHL+WVOoDA2/DnzwnF0gtZFtV3YGnaoUDxEr/oUf24Abwp4vRVQC7Nfi8eJy3ml5 C3Vg== X-Forwarded-Encrypted: i=1; AJvYcCU/P3pAiQzg/mYObvfadPs2n9kj1BjPJMfmRwBQAAhK8OSFcAPOWpoLzHZE0fOD6DtVA/dRXb99lA==@kvack.org X-Gm-Message-State: AOJu0YxPFnFbw8tK5th9BKFYdcoxVSzVkeLa0s60PZA8GplAFPdncu89 BcxPkfjteS/lHZrd1Evp4v5HGv8UJmn+VA5n2N47fXl5sizhu2cicBPUJg10avoYpEW5QubBQcI c+7y7SG0wnDPmjeG5lke2IcAZOf57nqWOXhRr X-Gm-Gg: ASbGncsF7ZDS44BA9iY8DTvc1Jg1LNJh8dnjmhdlCnWCpez0wz4z776ArVEZt+OItMW oJDqR6+laKh0Xk29oRfkssLnDfDOw8bTGCen+/S5iTwat0DzgBtNvUoEBoT/JfVEZi2AviWY3DA 9QE7GBrRrE6AtEfBQRV9+Ras5otgPNlzoBxbKTTEGE X-Google-Smtp-Source: AGHT+IFYiKfj7n9oq2z10qTkYhOrFEAS3wfYsvDaOSNLv5Kzbj7Q9svtXXu5LyLgAFkx1mNPmsy7UCDxvQfO3Nq1L3E= X-Received: by 2002:a4a:e9b0:0:b0:5fc:f416:e315 with SMTP id 006d021491bc7-5fd3c5e739cmr169433eaf.0.1740276348473; Sat, 22 Feb 2025 18:05:48 -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: Jeff Xu Date: Sat, 22 Feb 2025 18:05:37 -0800 X-Gm-Features: AWEUYZnuOFzxTft1Ol1ezbgtkwfxRwvwDnRZCiBdBqQfVmfm8mLtznn6nJkF5y0 Message-ID: Subject: Re: [RFC PATCH v5 0/7] mseal system mappings To: Pedro Falcato Cc: Kees Cook , Lorenzo Stoakes , 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: A1CBF180007 X-Stat-Signature: dyyeic8fkepbemgfdkfg9youx5ms9it5 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740276349-662116 X-HE-Meta: U2FsdGVkX1/gKy5Yol+ZgvELmcLy30Bs7uJkYi/pXFRTF9rZG9SpPcIL9H++HWX/rEJh2nWqiTWkk2+c1x3uZCXrNtdWRyVVUurEY8+ldgVbBl6ziSTJuiAOmVozysxme9A8kqLPcm+O/rY/RU1LtQIqCpGI6C6CkatWtyB5qRCIeOPo6pPCVMgTpfPgiDBNUx75SRcM6HGa6Gd46uoPfUnCaiMzCuin0iC6hcwXhbLJNpYRVSz11Wl7SU0m7rCKbmwYp2ojXeHDbX58Jt2tW5h8YMUOfChXuQhSjcN+hrclJiSaaEHc4o8DNaUj5hq8IJDaUj+ArD3ovJAlwYlDE5iskUbSXOxGCJ5nZZVJETB1cTPgV2oxCM/YaJ9snQ0BoowGgMm9z1k8a1/ZOrQ5E0ho+GRv5KpsMxd8360FrsgMdNzSz2hwAz2hJGaP3G+qYRnp7XUvcPCiit19EvKo+/ywcKe+s4sycso8ZMnLj4Yygcnkjraq9iR7Jj27reDNjjQNCfkSMzAkH8wgEpzLot1cKeiRw1PW3uW0tzpw3I4AeGExZk5dorU+/Y3bBgXqAFozVSk4GSnVCG+j8GHDqNdccqCi7i8eJktfhJr2x9vDukMBiSibuYzLnti9RgK3fPCsnv0iQ4iRTAtPVJCRhMTFbLEl8uxbahD9hLC7Vhuq/CnTHAWtqmIvlbYWfpqOYjWqYBpDlexpnDaZvHnV5QPfaAZ95dA7kV54PfEo8nZdc3Pz0sMFB88R0QuZJBNuKvF+MtXDQkDB00gmayuXOFi2ImjtX1RQ+kTXcMsFfPHf2nDdxccuKypWs99/+1x75HwKRLUNAd2I2n/2kE8/o3992x47mfPfMXcElVx3ezZmTagxsU4epQaCd7FQaK5dwLkp8BwSJuXwRV7Y3AreFzKxVFsIp3HXN6JCZO3UqpA2iEn0qnGVkrnxD6/Pqy47F4W/92TNW8GmHtfDniV +aw6OZTN qyT+vXo14Jgi9wpG3Mir9I4ALGPv8+ILi/QULD4nFPTZcnT4pBHCTTIqJPo3w0g47kXc/dtzyRkI5qJF6Wngl/qGEP5a+TUjjGwGICaXbKY9d1sjHaAmMu+BINSckrWDdLObGWCMTFvzh8OjV2E34qEenyYLfiQ4Mlwbdwzv6+LJL3OExMqxhQrO/xneCSsXEKIQ3QmINcyPksIDX/vRzFrFyd07GFqrojow41k4x5TceEEUFO56x+z/CdVFsCRkxPu+JkY5PP2OhVbJQ6M7Al1Raog+2T4WTBYRwW5MhuQbkgto= X-Bogosity: Ham, tests=bogofilter, spamicity=0.346357, 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 3:18=E2=80=AFPM Pedro Falcato wrote: > 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. > SECBIT (such as AT_EXECVE_CHECK) can be locked, which provides a strong security guarantee. > 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? > I'm hesitant to rely on HAS_SYSTEM_MAPPINGS_MSEAL in the kernel for special mappings. Think this way: some apps don't want vdso, but the kernel creates it anyway, those apps were forced to unmap or remap them. If the kernel should take a new dependency on the elf header, a better approach is adding a bit in the elf header to indicate "not-creating vdso". This would solve problems for those apps that want to unmap vdso. CRIU would need more than this new bit, i.e. an ability to create vdso on demand. Currently, during restore workflow, CRIU remaps the vdso created by the current kernel (can't use vdso from the back-up, because vdso is tied to the kernel version), and the remapping address must be the same address as the backed-up process, to avoid symbol-relocation. Kernel can provide a new functionality to create this vdso mapping as desired by CRIU. Then the vdso can be sealed from creation in all cases, this is the most secure approach. And the kernel also doesn't need that code to remap/unmap vdso - that is also cleaner IMO. Thanks. -Jeff > > [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