From patchwork Mon Feb 24 22:52:39 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Xu X-Patchwork-Id: 13989021 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 6DB23C021A4 for ; Mon, 24 Feb 2025 22:52:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6808280002; Mon, 24 Feb 2025 17:52:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A1853280001; Mon, 24 Feb 2025 17:52:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B8AA280002; Mon, 24 Feb 2025 17:52:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6EAC8280001 for ; Mon, 24 Feb 2025 17:52:51 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D809F4A840 for ; Mon, 24 Feb 2025 22:52:50 +0000 (UTC) X-FDA: 83156339700.15.81B8305 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf29.hostedemail.com (Postfix) with ESMTP id EE0CC120005 for ; Mon, 24 Feb 2025 22:52:48 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=WYZAuKI8; spf=pass (imf29.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.214.169 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=1740437569; 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:references:dkim-signature; bh=mXpe5H0HYKIhNOHQN5JiS3xHvAhirtYzR6Noo4in+5s=; b=Erd5cdADlKfbBeHqMJr988xbFywTeO8/NIKdpAepwJMWAs9+vLvV3HJLDPgEi+M1qR9oIZ DsNkHDY7TRN7z880X30iJt1VD5JH/PbVEVSkgVRz5Rk3B/Qhqe58/4e4TmaY6nMw42is3q uT3Tt2FzAy60iB4sBu1TvKn99VQDZh0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=WYZAuKI8; spf=pass (imf29.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.214.169 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=1740437569; a=rsa-sha256; cv=none; b=aavmXxgMWdF477UsqlGElMjTdwodGJizI2Q3F4wW2Z5Ycg/yqvOkzA85fww16YS+cp0EhO Qksr4VRh6c/9YY/BEqrEuI0IffWGt1S5wIYvdAkWQNC4AgRY+ZGr7p92b1ZOQXxH7wMA2J 2ZmSflTtHfNQwr1xtirvQKvNu3MIqXc= Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2217ea6d8daso12818245ad.3 for ; Mon, 24 Feb 2025 14:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740437568; x=1741042368; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=mXpe5H0HYKIhNOHQN5JiS3xHvAhirtYzR6Noo4in+5s=; b=WYZAuKI8FOAkJWh4qsSG1AmKm2oXYcA144HLkCpWYySqOIziuGAy0pL1d81IW/94d3 p5DTpOveyvkj1IAM4ry7FBaG9dG86/fL6FiuLP728s61lk1YVxHe3zoK2VZFHkW8VvZZ eUKpBpHsbEIXnVcpylJwOIuFoN1qscxWXxOdY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740437568; x=1741042368; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mXpe5H0HYKIhNOHQN5JiS3xHvAhirtYzR6Noo4in+5s=; b=m/vHnVccIrGsId/1g+6Pm5BnNDkRSUxDQLZhr+qhSzxHIz0wpC8AXs4hkyYU4O3djw NQjHis/LiU29qdkvETUKHwswoJS9+eEtH5/etNQy/npm+bNIwEEDIGXBqKQoYkcLNe8h 3Q/U+ApplCBj7BzCEkROgggsRM4QCDzIspKWonWb72Sz7X3dtu3zb0KQm1+0r213lXOK GgJZEy2Mk3lzZxe5vcSz9H1okdV8MttqFn1OoYalfX4K/SqiB3TOAwWxC+U/0O1gDONA VOOI621lLpdi4kGYaYzbc3kGmRNFbvTDKsQP1Bc97vKQf9eKtH7RG5JmI+pt3kMbPzuY OVsQ== X-Forwarded-Encrypted: i=1; AJvYcCU0muH+6k3zdRprUXUuX6VcQa6nEKhb7cECqL+Im6HEXglBWXfAW9X3Q5/1EwgmAJNfLevy8mOEDQ==@kvack.org X-Gm-Message-State: AOJu0YxdsUb2rLeXVKBLNRtpigdy3Ko17MvmHpWiNAJ7dI/FoE0l6dc4 NlX6SohYPKn2J+35A5IewW8+ZnxrecvuR6ngSpmnRcRn4fXFQeu5MnK0EF9H8Q== X-Gm-Gg: ASbGncua1MlHE/QBxR1k9Zo67K6nEztk+h8B6FApIfi5B2kIJxFElbymUxdz1NJSRzs OnXcUubjYKVvAIsyIuainwpDd2X/EZqZl5+MvEBY8l+unw0aeASmqMNuOfaksQUj4Gr7ptA1gIJ iVtMYmbKVaCFRp6T0V2hevEKh7ormj4V9U79zYr3rfIeIl5yI9cSMJtBsxffPhL1Yb59e0ej2tZ l+Akl4mCnZlMNakDCcUZeoqsa2DQnB1luKTVzd8ggI35i69AhUcRyeSOcR3QyL45pcCRb5PfOBD SPrrg0UO3ECgB+sGerarKFQGoiAVf+NAX1OyvfFoEnH3ctRE8IEZGBvbl9Zi X-Google-Smtp-Source: AGHT+IEHa9T2X9sLxY9oVUNah712hKbuLVNF6n68F2r7XX8GrvVHGwGDQiEDAKEWHbny+TNT2twy6Q== X-Received: by 2002:a17:903:40c9:b0:215:b8b6:d2c4 with SMTP id d9443c01a7336-2219ff4f24fmr94100455ad.4.1740437567432; Mon, 24 Feb 2025 14:52:47 -0800 (PST) Received: from localhost (201.59.83.34.bc.googleusercontent.com. [34.83.59.201]) by smtp.gmail.com with UTF8SMTPSA id d9443c01a7336-2230a00a9e3sm1392335ad.60.2025.02.24.14.52.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Feb 2025 14:52:46 -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 v7 0/7] mseal system mappings Date: Mon, 24 Feb 2025 22:52:39 +0000 Message-ID: <20250224225246.3712295-1-jeffxu@google.com> X-Mailer: git-send-email 2.48.1.658.g4767266eb4-goog MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: EE0CC120005 X-Stat-Signature: izsrd8pd5trgfn6ixh44soc1dfhcxfri X-HE-Tag: 1740437568-436258 X-HE-Meta: U2FsdGVkX1+K9rJ/Fw/u8MzsOu4aQcC4lFYFfYGQY8b2CegA67cWBG/Gd3jG+h1Zl6EAUyMqxoGBrcvEL3hSckC5+ZlT0tw/apNRD7/fq2Jw3qiLcq4IPVvRPqLCet+/JwCzvN3xDeZddEzkr/Pu/gu1YX1eF/gOYvgHj2UHwkqzWwr+vubE/36XukU3Yw+c/LfBT2K3QmPQXmdtkwcQmWefVBHcXMT1By8LAZDOx6j7xSCrUNEx91xBFjxN8znfmthA/BNWZ++LKGGTBBNAZZsVKXoBgI00c95hpPuTp9IC6arx61QvGExGBuRhyCbU3umCAFL6mH+SCgwkKyA723w2ZP4/0puVv78NwhKViWzGozTC7fWxYxmkz90EIUdcfaYTCqiRWmCLFXMiD8+CrQN09DZcC7zU6y+KJy20CP2Q6Sa6J9O1E4t4EG57XufdWVsW4+szPARSdJ2xIT+L0BFuqROsxSxY79DJs6jwQRDhwtVfqg9QWOw1TtzQhtzXvmyUmdwdQU9MXkMAugi+JOzknA9UbJXlb1x01GjPMRkFM05bnUzJ7z0hGAUq5SmpqbctcVMfNPoOthWv4YmmaR4TOXyxPN6D1FoHaNGJyvM7Ri6ujGRO1rfSLYC55Vfv6wOmvxKc2IiTrPsDcTcp4jcaVISM5aZHhInMfxidKlsAWRBGjbuXdQyvAOUEglPq8lLtmVL3/NHd1E6cI5aVpZ7RdfXIR8gCUFsWXocRvu08GzgVJ8t6IhftIbzPAhsg1rW8IkJKjfi+ijJD+689ianQ4XMm31fuFuMIzvuV3L6WfY3PWOFlwklbXFO28kSWCeLGiR3cH7i05F+CmP/gUFnfbVauGnZG5OIJCJqzIaNhwXN7gcoWulGefLozh8OZvyDYjOk2+FJJsWStyf0HflGmGt6SMwYskoJ0yH9NnPch1UMAulxsGYuLx0fNpirrRLVhi0nD1leGR1mXyWD oSyu8PBH fzT/N4HYMHaNI6sHirSwVb9SfjtapOGI8JS0kOG3So2b43epyUiBEIxSC/8LXBGRVBAJX1VmT4mRhCQDXNHoWmxUs/qeXDTcUppmnfvdxE/GE6SVJhxcwwSwNZ4BtreYIY77z2U3AqmormZ29BT67nLMgZtEwVzIYmPJPJNTcM92HpHbV0XVKBG1MGfPD46Cy+1CSIKgYNrlc3O3HxrvfSaed0bPK3RSGmgUUOijz6QbdA95wpSP/97j2VdR8be/IWWOYXu9MyAl0w/gVzO1PJCFv5ixqjObaaIdtZrqJWq0y4vkXczjsnzDS4TtVFoI5ZgOSu4MINJs99Vgxfasao18BKNtmwr94yJKJQfGistFNwP29Uw5T+vxXyye4m+z2VK7RuouvjTpj5JFaQ1UFWrQ5Hg== 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 This is V7 version, addressing comments from V6, without code logic change. -------------------------------------------------- History: V7: - Remove cover letter from the first patch (Liam R. Howlett) - Change macro name to VM_SEALED_SYSMAP (Liam R. Howlett) - logging and fclose() in selftest (Liam R. Howlett) V6: https://lore.kernel.org/all/20250224174513.3600914-1-jeffxu@google.com/ V5 https://lore.kernel.org/all/20250212032155.1276806-1-jeffxu@google.com/ V4: https://lore.kernel.org/all/20241125202021.3684919-1-jeffxu@google.com/ V3: https://lore.kernel.org/all/20241113191602.3541870-1-jeffxu@google.com/ V2: https://lore.kernel.org/all/20241014215022.68530-1-jeffxu@google.com/ V1: https://lore.kernel.org/all/20241004163155.3493183-1-jeffxu@google.com/ -------------------------------------------------- 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] Jeff Xu (7): mseal, system mappings: kernel config and header change selftests: x86: test_mremap_vdso: skip if vdso is msealed mseal, system mappings: enable x86-64 mseal, system mappings: enable arm64 mseal, system mappings: enable uml architecture mseal, system mappings: uprobe mapping mseal, system mappings: update mseal.rst Documentation/userspace-api/mseal.rst | 7 +++ arch/arm64/Kconfig | 1 + arch/arm64/kernel/vdso.c | 22 +++++++--- arch/um/Kconfig | 1 + arch/x86/Kconfig | 1 + arch/x86/entry/vdso/vma.c | 16 ++++--- arch/x86/um/vdso/vma.c | 6 ++- include/linux/mm.h | 10 +++++ init/Kconfig | 18 ++++++++ kernel/events/uprobes.c | 5 ++- security/Kconfig | 18 ++++++++ .../testing/selftests/x86/test_mremap_vdso.c | 43 +++++++++++++++++++ 12 files changed, 132 insertions(+), 16 deletions(-)