From patchwork Mon Feb 24 17:45:07 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Xu X-Patchwork-Id: 13988617 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 AE099C021BB for ; Mon, 24 Feb 2025 17:45:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EBCD428000D; Mon, 24 Feb 2025 12:45:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E442828000A; Mon, 24 Feb 2025 12:45:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6FFD28000D; Mon, 24 Feb 2025 12:45:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9B20D28000A for ; Mon, 24 Feb 2025 12:45:19 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 51B041A19EB for ; Mon, 24 Feb 2025 17:45:19 +0000 (UTC) X-FDA: 83155564758.09.B5492CF Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf27.hostedemail.com (Postfix) with ESMTP id 56D2C40015 for ; Mon, 24 Feb 2025 17:45:17 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=KSa7HKXl; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.214.180 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=1740419117; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=12YXJXd/yEdP4F/xsuPjPUzHYkrMQ/m+SagD7sBuyCE=; b=ECoSnPzzsFaIyi2cBdR/1YalCsuXXKw6+u9F2kJOECtNHhNNKlIB06ZMSPBCx4ig4+sSXt c0jCLHE6+uG+ykm6g1QVpAPOIpcJ3yz14z8y7Wa3p7ofzVqD7dlY8fa1ksVTwDowLodMV2 Skmkc2lnXtPHEtSwK90j5GvNaZOVVXE= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=KSa7HKXl; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.214.180 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=1740419117; a=rsa-sha256; cv=none; b=2Szrn08ANlt1OrSWoAVs6+XZrDxybwtNXym85XJCdvSV2NH52nlKkFVcsWg5835VQFL6Fl VzKnxa47Fr4gMT3vkANRG5JsHXpqduxhIuKu+/HZoHTySjtaB9qdtIuR7RJx3oylCUzEHn J/OvbN/X2rOvUWD8n3G9Js6nBolJ8yQ= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-220d27d490dso11075845ad.2 for ; Mon, 24 Feb 2025 09:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740419116; x=1741023916; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=12YXJXd/yEdP4F/xsuPjPUzHYkrMQ/m+SagD7sBuyCE=; b=KSa7HKXlbYqKT2Rwyir3ZHBrzwhuJqCohpyEqKQ3Y8EMVzOJW11NIkVunNptMwh4YD n0qE1X8Z0kqnnU/yOFNcgToPVpJl1/BCGxBeLWJS3+6vPp+wWc1wq9aKz0n0nd3zqBy1 lmr6NB/c7ecSPBz1v7R3m645uhvwyQsKmniew= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740419116; x=1741023916; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=12YXJXd/yEdP4F/xsuPjPUzHYkrMQ/m+SagD7sBuyCE=; b=lvDou7qh0c3PtRJn+CAWihNfgfz74auBA1llLiQqG2iKPAEHWlBAI8Y5nDEBPtVza/ odofBqyJsXr0CCfUHOFVUDcHNO7qUybwtOr5MTvokXP/DC0SE7qpdieCBpRvU4eu+6rd w2EIIusNPTXRhCpGn4n0qWe3WwBysLFFoUDJQsRR9R5yNLjQcDZD3pn1mP6Hl0AjhFyl sHIvX2OK5CdiuCNbIBlkV5VchsGcHjs9WWj1hDekYeDqLxcblxojAJd5Rus3mPjj+ktu kNldRDkAqpVS4tYdELR74EbbdNk8ALE3y+Y8v8Rg8lSUyhYabxw9EKk4ybto0RrE6/I0 DHdg== X-Forwarded-Encrypted: i=1; AJvYcCUQwsBg1GPd/SK4FpS8EKZ1BAwhIAohPK/vwetrvMc7vtB7JVyj9WLHx/Y6m7Za2vqfkvUAJcdahQ==@kvack.org X-Gm-Message-State: AOJu0YzVM068ziS/Pr44hMCZ9BTrmTyB8Cj4xqVUol/xXtb3it5eKuR6 5alft7KRW2jTk1Wi1imgns91cZuo6qFcqOnrr6DCqrYi4+mJt2J/yDiOWd7S6Q== X-Gm-Gg: ASbGncuJQbbYxajS5NYDlsr2VeX2AFf5DPB/5jrWmMg5ZkK/XIF/+4pYFXpxLI/K70U dw/QFdMr+dDDlJjobRbeTZy8HPL4QMISqAhBwxiqAUBjwJjGGL6dFGTE9zckuVJsTr5hzCnt6k3 fUwjgyWzcoDeah//G7+/jInMTaw4vNiUe8iLEdLv26o73YusYOAYxi5G/ZNkWyFet0bi0yClu7x AUEzJ7u+4ti8zE4FWw8F80FZnS7VOg9od6WrE8cvxBQRbj0h3Bf9Nqe5pnZ9+0tBxbJku4ZJWp9 oIXk2Z5X7ADD0JfS7YdcXZpR3SSF+D4TSlI+OEnNKhl+YoR1VWTRYhj7bgW5 X-Google-Smtp-Source: AGHT+IEM10lFU8wtWJoD9BVg2aWh3maIXwfJyL7OUpA65d05St26KsRXtPBtPPG4VoNhMT8Aot7f1Q== X-Received: by 2002:a17:902:e881:b0:215:8721:30b7 with SMTP id d9443c01a7336-2219ffbdfcbmr92049895ad.11.1740419116004; Mon, 24 Feb 2025 09:45:16 -0800 (PST) Received: from localhost (201.59.83.34.bc.googleusercontent.com. [34.83.59.201]) by smtp.gmail.com with UTF8SMTPSA id d9443c01a7336-220d53491d4sm183028425ad.4.2025.02.24.09.45.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Feb 2025 09:45:15 -0800 (PST) From: jeffxu@chromium.org To: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, vbabka@suse.cz, lorenzo.stoakes@oracle.com, Liam.Howlett@Oracle.com, adhemerval.zanella@linaro.org, oleg@redhat.com, avagin@gmail.com, benjamin@sipsolutions.net Cc: 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, Jeff Xu Subject: [PATCH v6 1/7] mseal, system mappings: kernel config and header change Date: Mon, 24 Feb 2025 17:45:07 +0000 Message-ID: <20250224174513.3600914-2-jeffxu@google.com> X-Mailer: git-send-email 2.48.1.658.g4767266eb4-goog In-Reply-To: <20250224174513.3600914-1-jeffxu@google.com> References: <20250224174513.3600914-1-jeffxu@google.com> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 56D2C40015 X-Stat-Signature: r8bi6nkwk6ycoqhg9ueg5yxqusz1uikq X-HE-Tag: 1740419117-543296 X-HE-Meta: U2FsdGVkX18VvQGKNbNo6ZBS5Zwd7zUAobdA5T8l9bJu3EeP27y+RFXzoizXDnUeAc1NpRGqEPUI2b8ajpefMeHHB9E3Cr1BWkYpOi9usOpNp8L2/5hUcWF3Bj8yYdzXss8/5CIgu6Yfa5W7Ytfvr2UBnIaExSnA1JUT/mDHSNTsySRx1kEsgGuNv2Uq2UMMt87ukFiWdYMQ6QGT+UTHadwqboxhhgBLA8EAbZPN6Wy/1J7Wx8fb/apNWT6ld1nNviNe8tuA23+/yzmANSEWgbrCL8U2O+KLZPAokI/QMmVHpMUzeLtWvkRuu3Mph2WJv1ZSmUE3cZh57St2TTgxK7I4WLeBxG5ez5tGBRnWAUK0zipoYG4h9SxfZ3DP1XBZa9Nlt02CThkooqc/TqjV6OEFFkk96ifm7iFNgDMFRLfouJT4IvnTB5qGGjJITyEFKDd2/YYVVqwE3uF6yNvL/nEHncm/0mPmS2xK+D7GaFyHB0wBKG87GnuQK5acvXbpTHlmNP9s++wq+KS6wtO1+qHmfBlPUgS6k3vJx4549LzinIlAVLL7s6b0v0KsopcqSdPm/sAdxqH3fKaUJm1mGAIf6XbSo+HmfU94C43ZZDxZpOoeiUV254VipyO9IHfyWVyXzYndBO6oEEz2W5Vb2TJJUWvwltH+FKO+bctqS5aOFFyf0a8UI2f7elyKBJF19fN27ibgMmJRwBBmJ15DA60SNJa/SSgedcFXZ2ZzGlqHZV0MdNX016rRr+wFNWKCxEA99qjaHY/gNhtae4/tqgRtO3zf+4964gmDut3yCrJspU/u2gowXLQNiO5X25UBDAFGSqz5/OZbVTOJMER0k1TuqjbYodnc+hrv/25xKXEtyJ90WrJ3vXaJle4aELeCSU9j7rb79ykd6srLIShDvR+uwfLWjuf9uJIxuLnSytUUbQ6W7D8T0gliRRlxp2GJkhGbyTLf/ZnMKCtFm93 HP8zGpBA 3O7+h6i7pYr6FH0sZvnL94B+5o8KkWYsi/5rXV2ZbXTPJwev1QujFCNhB+tbY8InIxCnq5iag+EoWHN3QrNcUSH3p26MVypHAX9CilV+yxhbL192aZj3BQ10ZgE6CI3Msi0Of0p4qfmuaXN7Ja6lGt2jC6iAB9+n9FrRiy/cEDHT0SuAts7HNUBIVT07wodE1Y2dLGztDfgxRk6JzhiBysNhY1otTCwc9OD4GNp8amBQ3SBecjHpgcy1K8TE/IPNJq8HtgonS1ZOmlYoc60u8BavvRFLpFui1ZupSui6m87+pF5P1SB2z39FkuOPpQCQq8I7vyjijhuqgk8zqoVr8WjxkNlTGaWXX24cJr8UgUXa8zfDIwGJdLbOy5nUDCLthgW5DNthAdW+/iAeM05a++tVC2scCbOBDGP2L 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: From: Jeff Xu Provide infrastructure to mseal system mappings. Establish two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS, ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and MSEAL_SYSTEM_MAPPINGS_VM_FLAG macro for future patches. As discussed during mseal() upstream process [1], mseal() protects the VMAs of a given virtual memory range against modifications, such as the read/write (RW) and no-execute (NX) bits. For complete descriptions of memory sealing, please see mseal.rst [2]. The mseal() is useful to mitigate memory corruption issues where a corrupted pointer is passed to a memory management system. For example, such an attacker primitive can break control-flow integrity guarantees since read-only memory that is supposed to be trusted can become writable or .text pages can get remapped. The system mappings are readonly only, memory sealing can protect them from ever changing to writable or unmmap/remapped as different attributes. System mappings such as vdso, vvar, and sigpage (arm), vectors (arm) are created by the kernel during program initialization, and could be sealed after creation. Unlike the aforementioned mappings, the uprobe mapping is not established during program startup. However, its lifetime is the same as the process's lifetime [3]. It could be sealed from creation. The vsyscall on x86-64 uses a special address (0xffffffffff600000), which is outside the mm managed range. This means mprotect, munmap, and mremap won't work on the vsyscall. Since sealing doesn't enhance the vsyscall's security, it is skipped in this patch. If we ever seal the vsyscall, it is probably only for decorative purpose, i.e. showing the 'sl' flag in the /proc/pid/smaps. For this patch, it is ignored. It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may alter the system mappings during restore operations. UML(User Mode Linux) and gVisor, rr are also known to change the vdso/vvar mappings. Consequently, this feature cannot be universally enabled across all systems. As such, CONFIG_MSEAL_SYSTEM_MAPPINGS is disabled by default. To support mseal of system mappings, architectures must define CONFIG_ARCH_HAS_MSEAL_SYSTEM_MAPPINGS and update their special mappings calls to pass mseal flag. Additionally, architectures must confirm they do not unmap/remap system mappings during the process lifetime. 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 keeping the core memory management within the mm layer, while delegating the decision of sealing system mappings to the individual architecture, which is particularly relevant since 32-bit architectures never require sealing. Prior to this patch series, we explored sealing special mappings from userspace using glibc's dynamic linker. This approach revealed several issues: - The PT_LOAD header may report an incorrect length for vdso, (smaller than its actual size). The dynamic linker, which relies on PT_LOAD information to determine mapping size, would then split and partially seal the vdso mapping. Since each architecture has its own vdso/vvar code, fixing this in the kernel would require going through each archiecture. Our initial goal was to enable sealing readonly mappings, e.g. .text, across all architectures, sealing vdso from kernel since creation appears to be simpler than sealing vdso at glibc. - The [vvar] mapping header only contains address information, not length information. Similar issues might exist for other special mappings. - Mappings like uprobe are not covered by the dynamic linker, and there is no effective solution for them. This feature's security enhancements will benefit ChromeOS, Android, and other high security systems. Testing: This feature was tested on ChromeOS and Android for both x86-64 and ARM64. - Enable sealing and verify vdso/vvar, sigpage, vector are sealed properly, i.e. "sl" shown in the smaps for those mappings, and mremap is blocked. - Passing various automation tests (e.g. pre-checkin) on ChromeOS and Android to ensure the sealing doesn't affect the functionality of Chromebook and Android phone. I also tested the feature on Ubuntu on x86-64: - With config disabled, vdso/vvar is not sealed, - with config enabled, vdso/vvar is sealed, and booting up Ubuntu is OK, normal operations such as browsing the web, open/edit doc are OK. In addition, Benjamin Berg tested this on UML. Link: https://lore.kernel.org/all/20240415163527.626541-1-jeffxu@chromium.org/ [1] Link: Documentation/userspace-api/mseal.rst [2] Link: https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@mail.gmail.com/ [3] Signed-off-by: Jeff Xu --- include/linux/mm.h | 10 ++++++++++ init/Kconfig | 18 ++++++++++++++++++ security/Kconfig | 18 ++++++++++++++++++ 3 files changed, 46 insertions(+) diff --git a/include/linux/mm.h b/include/linux/mm.h index 7b1068ddcbb7..0e2a4a45d245 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -4155,4 +4155,14 @@ int arch_get_shadow_stack_status(struct task_struct *t, unsigned long __user *st int arch_set_shadow_stack_status(struct task_struct *t, unsigned long status); int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status); + +/* + * mseal of userspace process's system mappings. + */ +#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAG VM_SEALED +#else +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAG VM_NONE +#endif + #endif /* _LINUX_MM_H */ diff --git a/init/Kconfig b/init/Kconfig index d0d021b3fa3b..07435e33f965 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 + bool + help + Control MSEAL_SYSTEM_MAPPINGS access based on architecture. + + A 64-bit kernel is required for the memory sealing feature. + No specific hardware features from the CPU are needed. + + To enable this feature, the architecture needs to update their + special mappings calls to include the sealing flag and confirm + that it doesn't unmap/remap system mappings during the life + time of the process. After the architecture enables this, a + distribution can set CONFIG_MSEAL_SYSTEM_MAPPING to manage access + to the feature. + + For complete descriptions of memory sealing, please see + Documentation/userspace-api/mseal.rst + config HAVE_PERF_EVENTS bool help diff --git a/security/Kconfig b/security/Kconfig index f10dbf15c294..15a86a952910 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, rr are known to relocate or + unmap system mapping, therefore this config can't be enabled + universally. + + For complete descriptions of memory sealing, please see + Documentation/userspace-api/mseal.rst + config SECURITY bool "Enable different security models" depends on SYSFS