From patchwork Mon Oct 14 21:50:19 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Xu X-Patchwork-Id: 13835519 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 ECB99D18151 for ; Mon, 14 Oct 2024 21:50:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65CE36B0082; Mon, 14 Oct 2024 17:50:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60C196B0083; Mon, 14 Oct 2024 17:50:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AD0C6B0085; Mon, 14 Oct 2024 17:50:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2C2B46B0082 for ; Mon, 14 Oct 2024 17:50:32 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 151E0C12AA for ; Mon, 14 Oct 2024 21:50:23 +0000 (UTC) X-FDA: 82673552136.04.FA1B56F Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf28.hostedemail.com (Postfix) with ESMTP id 78CBAC0009 for ; Mon, 14 Oct 2024 21:50:23 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FKD7CiOi; spf=pass (imf28.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.178 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=1728942583; 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: references:dkim-signature; bh=iHgAeWx2Z6u/Rr4guiu2M1wSVbBmkz71ggb4GDq4zfk=; b=7UzSEB9ZqfYBNl81/8F4f4IV9QrPwbHzI6znSP6+0AjgPMvNsIjZITZqvflzhB7hr8nMsW D1IVA5B0sR/KwMyNrNDK+BL1Ge9dPpAwzw32sg9CgV1IvgaaHgmuzfihKDv1JJ6MrdL7uB AjW5Jl13CukX61Xaus1FSE7bveWlbZg= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=FKD7CiOi; spf=pass (imf28.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.178 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=1728942583; a=rsa-sha256; cv=none; b=mF3jAeXL2HnkFz/jhvnsIrKdlE1NNyz+0emv6rFIDXL1Iy4fMk/gWulff38bYnSbCbUdRe lRZTpobBwb8Cte5B85KpQs+p34awmcfZTwFKLtIRqfO3KZqiQDMAuns8SZ2qXTxDcxkn2q IbQz0P70uMV6/zlrmeb/aHZGw366PdI= Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-71e74f35acaso38371b3a.2 for ; Mon, 14 Oct 2024 14:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1728942628; x=1729547428; 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=iHgAeWx2Z6u/Rr4guiu2M1wSVbBmkz71ggb4GDq4zfk=; b=FKD7CiOiHCUJ/cyZN4a9+NQf4dCfZ6jEi0LsvV+2juaDhyg7vfLIyKKOkN42royrwI +gevTIGDnTlC2yfU8/PagmaUlwknrnBYRcjlrjv/STssQFqKcyKUgzCha1gwx0ysBlkQ LQZde2beygaw8Mpc1dHz2wNjg6hWnSvCKLePQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728942628; x=1729547428; 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=iHgAeWx2Z6u/Rr4guiu2M1wSVbBmkz71ggb4GDq4zfk=; b=Szxj/FTkQuhy9SklT3Iamn3mKGGtVRTBDINTz8G5MVIFycBfWQINiv8mo5uo0C9aRj EDeyH9ZsC/2/dak7ASVoG2k8U2LI4UGIqQMPpxLm+8z7iMO+1O4pQcXK2YemDDN7SGdM AwqPDS6/etDvRzu02k8lP/+p0codYoGgr7MZ5gBzC+0o8HCZQyxb6/FyctOr8fLVwSbA GW5AAtcU1EbPVJMcIcufEB9wUi9z6/FO2flGygnZfWOZgjRCgQHr6UFCBXT6PdJgcOs8 dCPaja6MmkDjF3DWsN5KCnF3g9kcQLiFqOtmJWd9w1DbEQwZ1cFV7N+q4uFAL6MUBNzT X1uA== X-Forwarded-Encrypted: i=1; AJvYcCUc+XMb2RqsCr+Nla6QhnvV2aGDHyFhxq+uDVz6B4Dobhfloy/exfnkrZFkNC1qa/roeGG5uAUoAQ==@kvack.org X-Gm-Message-State: AOJu0YyN4ySEvGG2XQgkB/8zbE5jDCO7i8F3+UaACb4m1dsLmbhByWek db7+iO70XxEgdfz+tTg5PYCaKxpl4V5ojkKxh9l2Ddk0sRyC1UlVCihXPCnOLg== X-Google-Smtp-Source: AGHT+IGthjCd3HKvWtjJZwDzbVAakFkQKTTiDKfjfpQUEZRgXxs1pRU5IC3CwN8YbItLINHiJkWh6Q== X-Received: by 2002:a05:6a21:999f:b0:1cf:46ff:973d with SMTP id adf61e73a8af0-1d8bcfa83edmr9185549637.9.1728942628504; Mon, 14 Oct 2024 14:50:28 -0700 (PDT) Received: from localhost (56.4.82.34.bc.googleusercontent.com. [34.82.4.56]) by smtp.gmail.com with UTF8SMTPSA id d2e1a72fcca58-71e625b63a2sm3035501b3a.159.2024.10.14.14.50.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Oct 2024 14:50:28 -0700 (PDT) From: jeffxu@chromium.org To: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, oleg@redhat.com Cc: linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org, adobriyan@gmail.com, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, hch@lst.de, peterx@redhat.com, hca@linux.ibm.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, Liam.Howlett@Oracle.com, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, lorenzo.stoakes@oracle.com, Jeff Xu Subject: [RFC PATCH v2 0/1] seal system mappings Date: Mon, 14 Oct 2024 21:50:19 +0000 Message-ID: <20241014215022.68530-1-jeffxu@google.com> X-Mailer: git-send-email 2.47.0.rc1.288.g06298d1525-goog MIME-Version: 1.0 X-Rspam-User: X-Stat-Signature: dszzyz46quuhny99ckejq8tbasu34dq7 X-Rspamd-Queue-Id: 78CBAC0009 X-Rspamd-Server: rspam11 X-HE-Tag: 1728942623-789346 X-HE-Meta: U2FsdGVkX1+xsH6M991uM9qS3gcHGvHdF5F39sA3ZK4RX4fZV72bn7wOCZb5DJMg4hdFwP3Kik5pGG2KltXk9plVEPysde7LAI7q7jRBSI8oFG56H80pwXTe8q4tCPZLQvre38/6H+SZ5b/py4+TkGOXmLAJbG5ECT7slDjRQIGQMOdkX6+LW4WmEoE7HmaPKHsJvi5uIsyq8A7T5pbnz9io7hHyf/vtqTSgBBKao2Snc8tkpP8WRyhPD/9hk8a4PCcqVoHnGEDvHEkLiRNxKK0X+1eLMWLBDGO3NNEF97wEUNleg9f7qoB4tuIGp+g1mVok6Mgbzp28K4JqGRJtyugnQLMEdQ6xvYq3ErkY27MnwSml0dZueat3iPVX0Vd0ZUQ0CcJRcQX+WBBOO1tkidostkTKfnToXkUMhdZelUZRd3cYGeaSMIUhNAyp7KBnYLwuQ/lUtCfnG/f8IlrmDH+SqVMZUjXece4Fdce0LMZcApFDtzKFyjhGNCcC/fxngcxBElFGyCUFJcXce++OZyPxZ5JTE6AADuBzZm08tJ7Y/ehSk1btCVjUAGcVbj6INKusaWopJVdnwDOUNXruNegTDXheguZsTGCl7Wklldv1FGAYq3FOvcE4p7drG82yyBjvB4vQS5WXHj8RuZBjNQDpgd4w6xYZa+4eItKO+e2B/3zHc0/CD1vqdQHh2Ghl+AC+JnIAUrJI6QqMGZDrvfQ6auw9hAVq4E4j6I4l6rqsup0GVHfvNSleGeC+KDnJfQGHudCVOclG64HXqVzQPYHl24Srr6npobM/2/Dh+H3e5MpS8OwqwXO1VXExJv4IP9bFAKIHJ8KjUO4VQyep1oS3NjTbL3ZoaIaMtRqU2NyQW8s3X+tZ433H2L/3tY1KLujy7PsEMh/vest1cbqOGrnCvziOVUWFIKa+y3KVrJxTi8Rgk0skAQsUt3Ap2FR/xzwfwz0N2CxR+IZnKNZ riPJ3RHj jwXQU2oIhPI7o6dyURJsATN5B1GEcFyITbvenV8O2QUSeRmOanAei1776h31aAFBP33sc023mhBDx9YvKneqsFWqMZJxKTad+kmJ8th5Pd4RvqHEYyTObUtvmlv++e+tUwfbQnQxUl6DM6ELozyOtwqK46AIS6VzQ24jLYHjcC/snjGKd9inN3Aa9pZxmAT2M1ilShPcRy5JM2m8EbOu8g0qvXmyDDCkolFLjY2kMuy/MyGj9kmry5Jf3BkYwX2cuxNeLoAJlKlFvIyo3LrgoW8QwHWkDqdO+elOlf2dLJBqgaBpqVWzZOCC3ALL2N1ZZEHHhZLhVqpRL8kmBFxUXqdOQEN2xMAgfCZQjfhEJAiGUaePqCdTUcUZt2U1PgofKMa1BQWbS9xkaRv4= 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 Seal vdso, vvar, sigpage, uprobes and vsyscall. Those mappings are readonly or executable only, sealing can protect them from ever changing during the life time of the process. For complete descriptions of memory sealing, please see mseal.rst [1]. System mappings such as vdso, vvar, and sigpage (for arm) are generated by the kernel during program initialization. These mappings are designated as non-writable, and sealing them will prevent them from ever becoming writeable. Unlike the aforementioned mappings, the uprobe mapping is not established during program startup. However, its lifetime is the same as the process's lifetime [2], thus sealable. The vdso, vvar, sigpage, and uprobe mappings all invoke the _install_special_mapping() function. As no other mappings utilize this function, it is logical to incorporate sealing logic within _install_special_mapping(). This approach avoids the necessity of modifying code across various architecture-specific implementations. The vsyscall mapping, which has its own initialization function, is sealed in the XONLY case, it seems to be the most common and secure case of using vsyscall. It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may alter the mapping of vdso, vvar, and sigpage during restore operations. Consequently, this feature cannot be universally enabled across all systems. To address this, a kernel configuration option has been introduced to enable or disable this functionality. Note, uprobe is always sealed and not controlled by this kernel configuration. I tested CONFIG_SEAL_SYSTEM_MAPPINGS_ALWAYS with ChromeOS, which doesn’t use CHECKPOINT_RESTORE. [1] Documentation/userspace-api/mseal.rst [2] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@mail.gmail.com/ History: V2: Seal uprobe always (Oleg Nesterov) Update comments and description (Randy Dunlap, Liam R.Howlett, Oleg Nesterov) Rebase to linux_main V1: https://lore.kernel.org/all/20241004163155.3493183-1-jeffxu@google.com/ Jeff Xu (1): exec: seal system mappings .../admin-guide/kernel-parameters.txt | 10 ++++ arch/x86/entry/vsyscall/vsyscall_64.c | 9 +++- fs/exec.c | 53 +++++++++++++++++++ include/linux/fs.h | 1 + kernel/events/uprobes.c | 2 +- mm/mmap.c | 1 + security/Kconfig | 26 +++++++++ 7 files changed, 99 insertions(+), 3 deletions(-)