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 402ABC021A4 for ; Thu, 13 Feb 2025 17:16:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 951BA6B0082; Thu, 13 Feb 2025 12:16:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B3506B0083; Thu, 13 Feb 2025 12:16:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 72C846B0088; Thu, 13 Feb 2025 12:16:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5219F6B0082 for ; Thu, 13 Feb 2025 12:16:57 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B2251C11E8 for ; Thu, 13 Feb 2025 17:16:56 +0000 (UTC) X-FDA: 83115576432.12.BB5EEB0 Received: from mail-oa1-f54.google.com (mail-oa1-f54.google.com [209.85.160.54]) by imf27.hostedemail.com (Postfix) with ESMTP id 8317E40004 for ; Thu, 13 Feb 2025 17:16:54 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=aIAv1bCG; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.54 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=1739467014; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=tBy9giu2XuH33LZCPuALTlrK7I4fNXTlE0NtPV35u4I=; b=XlR2W7at/EG21Zt1booyV35dR/QXekGEaHiHzLZ9KzxXSdnVvXqZSabiyi/2//tH3Itrye n1peotTZIzX/hsEP6cf7MrelMLw5+eNFdq8f/4tZWFSXh/MuAe0I+UnuqRwClivXzDm6XD Zz34cAXNj9S0O/TJx50PqksJyPJ6OCM= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=aIAv1bCG; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.54 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=1739467014; a=rsa-sha256; cv=none; b=afUfotG2XtXH6qkz7ychWO9zgGfSmfO9B9CnCCZ2WxK0iPkl/mOtUtML2viEH+we2OgPrf EpDrjrWErLVe5B2Iq+lMD7QFcwOWF+aYvB4LAqcwhdWNIpE8R7vlw9ZML0oMfMFybS56OE gTlicy+fTAnCoYbhHiPTu4jppUaXMkI= Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-2b1f2b286f5so48646fac.3 for ; Thu, 13 Feb 2025 09:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1739467013; x=1740071813; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tBy9giu2XuH33LZCPuALTlrK7I4fNXTlE0NtPV35u4I=; b=aIAv1bCG16ENoB+Fw+f39K1+gZLMgMQCsiyFERMNVqQrNucwbG/FSYSWuaQS+CxfRW YtqweQ7O0Ec9PPub4tAuf/C7z1MBs/9e6VvlAVCtkgbzAxgIYtBaKIb7T8sloFWORjDq DA7AJzNhFBUj7utXLFpnQ9rfNqya0yh2hICuI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739467013; x=1740071813; h=content-transfer-encoding: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=tBy9giu2XuH33LZCPuALTlrK7I4fNXTlE0NtPV35u4I=; b=mLLvdiPJJLuPPvJ5nqA4RFMDu69++joe1v+/msk/b/lxgpC0cH1WDVXYptRnI4iYNS DFDRqxn92IiYciZHGTKnvuJDewGvevnCxRU8vqhz+sxgu9o73lpuVlL4snzuWJOTkMsT GLpnD0v/cZ3GeY09fMD+QaW/DsS114V14LcYsqaa0ihVUMLo1njIWCtvCBJ496MWce/7 w9rZvam3G09PaFUJwmqrPOX24pEDahCiI0VZoCVATV4ilXLnegSFuGmBX6Azmuvognzb Gra0beUjUPBDk4X5s+H2E/279b4/+r4YUnezqtYGuEHoHx7vNABnG5AceFqXbPlQjLmV M1fw== X-Forwarded-Encrypted: i=1; AJvYcCWdnU8JuMXcU+55tT6hjcXFODG4N6AxMz3N3hXRa2c9JjmmlKbsZaLYpU7FVpLDc/yGYHBlNiF48w==@kvack.org X-Gm-Message-State: AOJu0Yx0Zr0bMmrgTj0EFOxSzroTQahZbYoU7U7oBpVD4vwS121s4dyC WVtPezh7AqKQEgNCzEya9LwxrXKJRRtzsx4ttzX6oAAv/1vtrdQcXqYunS2qAL4eJXt4cYv5Zno HXZ0apSXH0hwezLWPmlcJ4/eEsJk9Dbph6o49 X-Gm-Gg: ASbGnctYE8iPkvVE6YQhQu04sRF0W8ppYytaiDZLRU8jQvANSJrXKXJ4wvGmZivMdor eKjAqdR6c+tsbCRZrNrmodIM8DG1/FumFsBqvFIeCceclPLgI3e6lYhbBs2mEE1WFi2jFP/txHD cnGpDoK7uPLdSUDxjYAuRV4oxln5gcjg== X-Google-Smtp-Source: AGHT+IFgl+AN2r8X6K1wzkDWdEWSCbY3TrGWVYP851EsxR7f08xemuxZwcDGWA0t2Tv/VeZB1tHKMo1KROF0nlz+v0E= X-Received: by 2002:a05:6870:648b:b0:2b7:f564:a35b with SMTP id 586e51a60fabf-2b8d67f0b49mr1726124fac.8.1739467013249; Thu, 13 Feb 2025 09:16:53 -0800 (PST) MIME-Version: 1.0 References: <20250212032155.1276806-1-jeffxu@google.com> <20250212032155.1276806-2-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Thu, 13 Feb 2025 09:15:00 -0800 X-Gm-Features: AWEUYZk-H7IZgTRLevdACXtvIkKevRsUdXrms45ENhCkHRV0gRY9quOaw4ihuIE Message-ID: Subject: Re: [RFC PATCH v5 1/7] mseal, system mappings: kernel config and header change To: "Liam R. Howlett" , jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, vbabka@suse.cz, lorenzo.stoakes@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, pedro.falcato@gmail.com, 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-Rspam-User: X-Rspamd-Queue-Id: 8317E40004 X-Stat-Signature: inygqcwohnf39jrdgmkhzsq7uykubaoh X-Rspamd-Server: rspam03 X-HE-Tag: 1739467014-964590 X-HE-Meta: U2FsdGVkX18HmLPmIvXUqbNpURtOqUhI7jYY0DpSVUQ7/W8pVmJQiAIbL2G8n24/LfxP3aFKGvh98uj0hOoH1jAzOUDbgXz73LsWNXdeRLHjgQ4KgEdnItxeIwL9ezt3jXp9OGl1fgl345a2Zd+TvC5l7OecBN3ApQcXPhSRyxxduM0UZ4+MIdgNaEwdRXmeWqxGDIVnDdDXiGM7fROfZT7ODPO9JNJAfCkV2kFkyEQ2cJVDrjr6UYeRKSkjRI1UFtJksNXoZP86YsIKTjoeq/EmTI9ILWp3H/20Cc7BYGkGwKPHk1lQ4UAFYbrDMP0zwwol/DanVoo5yG8Qn3uxzduhmDYKQ04M9kE85WuyA0qib56ODO6HorTT+cBFzBwV6HUePQgRJMV/0ezswgIMT5+uUeg3BWnWLbWM6jP5ZSUJZfaJKS2duc6YrNH4lDe9Fz2w29oRN+MSy1hjpvRFcOelGcnygKqrjrBz71BurMrDjoGgqYyg9QUvJD9CkNCIbViknFHh9DkE0OMBA3krY4CiMHJvGuQ7gEHkoNSHzlo+AqislMWkdPT/Jgxg1z83AWX+3+HEpG5KJgzZThkrwxGj7QfVzpujIXCjS99cVk7gp5T7atsSvdCdCGvgSOotQz/wv4OAPQp33vskhywXuQFI5gNdVQbDD9iO8MnJKfMjRzp6IFxX8njz9eBJHFEsR7jX1dLoknpytgzjATP1i+Tl0yrUoPI0EJSUKcMRs0Df9jYlk45vq2dv/cjhoRtGi1822JZgwdImJaZy3JPHQk+AcAYVEa6J4a+0JwMr/AkJ5pJC0VUXfZg8azC1jSovHxTCoGYINSMMBic93+EIl7TWKhLtT3DSldX4YwJwGJ/Qsm8YSodS3Z4RVhFTuy0gjalH1lgMevFELROvum8RvBaiuGhIebSSWE2RcQ6Pkj8w6fuVPiWAr0n3MLb4kCjjJfOS8afjTdtob0meXqy yOBUmfht RUOavVq8fQ1D/ykAD2sPovdpa+9CUhBPyVbuM8RBju9o6IojtoCK4jDLZ04JfL+4+BeVuRo4bWQJA2YvL/Bx78mn9JK/kp+QjLLJxmvOMfX3OPoYWUCuIVMCVuMBaMbIKsobqpuV/gRPK4jL4Ti091pkuNWyBPXHYHkRW52xSalYoKWn44fxDsIELio9HDDJIHcEEd4jtvf0Bt5RQHiA6UJSswGpzt9J4OhAoOPlrtMzlBCBrlHMyDeetuSuG9jnDDPSZcOvw/ZoZYhb6Dctcw0G8/gP2GFmNpykIySyWf75xu6o= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 7:05=E2=80=AFAM Liam R. Howlett wrote: > ... > > > > In this version, we've improved the handling of system mapping sealing = from > > previous versions, instead of modifying the _install_special_mapping > > function itself, which would affect all architectures, we now call > > _install_special_mapping with a sealing flag only within the specific > > architecture that requires it. This targeted approach offers two key > > advantages: 1) It limits the code change's impact to the necessary > > architectures, and 2) It aligns with the software architecture by keepi= ng > > the core memory management within the mm layer, while delegating the > > decision of sealing system mappings to the individual architecture, whi= ch > > is particularly relevant since 32-bit architectures never require seali= ng. > > > > Additionally, this patch introduces a new header, > > include/linux/usrprocess.h, which contains the mseal_system_mappings() > > function. This function helps the architecture determine if system > > mapping is enabled within the current kernel configuration. It can be > > extended in the future to handle opt-in/out prctl for enabling system > > mapping sealing at the process level or a kernel cmdline feature. > > > > A new header file was introduced because it was difficult to find the > > best location for this function. Although include/linux/mm.h was > > considered, this feature is more closely related to user processes > > than core memory management. Additionally, future prctl or kernel > > cmd-line implementations for this feature would not fit within the > > scope of core memory management or mseal.c. This is relevant because > > if we add unit-tests for mseal.c in the future, we would want to limit > > mseal.c's dependencies to core memory management. > > ... > > > > diff --git a/include/linux/userprocess.h b/include/linux/userprocess.h > > new file mode 100644 > > index 000000000000..bd11e2e972c5 > > --- /dev/null > > +++ b/include/linux/userprocess.h > > @@ -0,0 +1,18 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#ifndef _LINUX_USER_PROCESS_H > > +#define _LINUX_USER_PROCESS_H > > +#include > > Why is this in a new file and not mm.h directly? Anyone who needs to > use this will pull in mm.h anyways, and probably already has mm.h > included. > The commit message includes the reason. I've snipped and left the relevant portion for easy reference, please see the beginning of this email. > > + > > +/* > > + * mseal of userspace process's system mappings. > > + */ > > +static inline unsigned long mseal_system_mappings(void) > > +{ > > +#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS > > + return VM_SEALED; > > +#else > > + return 0; > > +#endif > > +} > > + > > +#endif > > Looking in mm.h, there are examples of config checks which either set > the bit or set it to 0. This means you wouldn't need the function at > all and the precompiler would do all the work (although with a static > inline, I'm not sure it would make a big difference in instructions). > > For instance, you could do: > #ifdef CONFIG_64BIT > /* VM is sealed, in vm_flags */ > #define VM_SEALED _BITUL(63) > > #ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS > #define VM_SYSTEM_SEAL VM_SEALED > else > #define VM_SYSTEM_SEAL VM_NONE > #endif > > #else /* CONFIG_64BIT */ > #define VM_SYSTEM_SEAL VM_NONE > #endif > > Then you can use VM_SYSTEM_SEAL in the system mappings function in the > list of flags instead of having a variable + calling the static > function. > > I didn't look close enough to see if the 32bit version is necessary. > I'm aware of the other pattern. VM_SEALED isn't defined in 32-bit systems, and mseal.c isn't part of the build. This is intentional. Any 32-bit code trying to use the sealing function or the VM_SEALED flag will immediately fail compilation. This makes it easier to identify incorrect usage. > > diff --git a/init/Kconfig b/init/Kconfig > > index d0d021b3fa3b..892d2bcdf397 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -1882,6 +1882,24 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS > > config ARCH_HAS_MEMBARRIER_SYNC_CORE > > bool > > > > +config ARCH_HAS_MSEAL_SYSTEM_MAPPINGS > > ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS is more clear. HAS may mean it's > supported or it could mean it's enabled. SUPPORTS is more clear that > this is set if an arch supports the feature. After all, I think HAS > here means it "has support for" mseal system mappings. > > I see that both are used (HAS and SUPPORTS), but I'm still not sure what > HAS means in other contexts without digging. > The existing pattern is to indicate arch support with CONFIG_ARCH_HAS_N and security/KConfig to have CONFIG_N as the main switch. For example, CONFIG_ARCH_HAS_FORTIFY_SOURCE and CONFIG_FORTIFY_SOURCE. Since the MSEAL_SYSTEM_MAPPINGS is placed in security/Kconfig, hence I'm following the existing pattern in security/Kconfig. > > diff --git a/security/Kconfig b/security/Kconfig > > index f10dbf15c294..bfb35fc7a3c6 100644 > > --- a/security/Kconfig > > +++ b/security/Kconfig > > @@ -51,6 +51,24 @@ config PROC_MEM_NO_FORCE > > > > endchoice > > > > +config MSEAL_SYSTEM_MAPPINGS > > + bool "mseal system mappings" > > + depends on 64BIT > > + depends on ARCH_HAS_MSEAL_SYSTEM_MAPPINGS > > + depends on !CHECKPOINT_RESTORE > > + help > > + Seal system mappings such as vdso, vvar, sigpage, uprobes, etc. > > + > > + A 64-bit kernel is required for the memory sealing feature. > > + No specific hardware features from the CPU are needed. > > + > > + Note: CHECKPOINT_RESTORE, UML, gVisor are known to relocate or > > + unmap system mapping, therefore this config can't be enabled > > + universally. > > I guess add rr to the list, since that's also reported to have issues as > well. > sure. Thanks for reviewing. -Jeff