From patchwork Fri Dec 6 01:09:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Isaac J. Manjarres" X-Patchwork-Id: 13896198 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 3E725E77170 for ; Fri, 6 Dec 2024 01:09:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 937B86B013E; Thu, 5 Dec 2024 20:09:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E82A6B0140; Thu, 5 Dec 2024 20:09:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 788396B0141; Thu, 5 Dec 2024 20:09:36 -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 577956B013E for ; Thu, 5 Dec 2024 20:09:36 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F2492817F9 for ; Fri, 6 Dec 2024 01:09:35 +0000 (UTC) X-FDA: 82862751006.21.A93DADF Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) by imf06.hostedemail.com (Postfix) with ESMTP id C74E2180018 for ; Fri, 6 Dec 2024 01:09:22 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qSUQ4Uuq; spf=pass (imf06.hostedemail.com: domain of 3zU5SZw4KCPQeoWWYiWjfWnnaockkcha.Ykihejqt-iigrWYg.knc@flex--isaacmanjarres.bounces.google.com designates 209.85.215.201 as permitted sender) smtp.mailfrom=3zU5SZw4KCPQeoWWYiWjfWnnaockkcha.Ykihejqt-iigrWYg.knc@flex--isaacmanjarres.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733447366; 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:in-reply-to: references:dkim-signature; bh=mGLqKj5S2m2Rj61UvNDmOdNoAA7bI8ePX/RHfZ0+49A=; b=R4xxMiRTInNQAmB7Ca0ec6etBLrr9VxUpy8zypTWFEGHjEfgn0789jBLGYHQ9qYClMViOn qu9LJKHKtJgrbQTncRpM2RHdwb2/KBMSszJup8srLPbmE7eNkMqgceplMsLZ+Yh4ve4l7K flEB/7s3V6of73DRoXLfSORHJRTSFvE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733447366; a=rsa-sha256; cv=none; b=ZjNAxLj0im2hqPhfnAurB2ZcTpfL5azVgjzS7w3bj9nGZls3FzSKhmRiGhsNLb+hbRZd95 ZtJDyTlbNx+JqVDg/GuQ1F8MlPIF9680uCWrYM/NlHU7OE200JdLv5DR2ZPamanepv5Lxv RNCmkS8XivJH28rhKfGGuUUvGxZl9kA= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qSUQ4Uuq; spf=pass (imf06.hostedemail.com: domain of 3zU5SZw4KCPQeoWWYiWjfWnnaockkcha.Ykihejqt-iigrWYg.knc@flex--isaacmanjarres.bounces.google.com designates 209.85.215.201 as permitted sender) smtp.mailfrom=3zU5SZw4KCPQeoWWYiWjfWnnaockkcha.Ykihejqt-iigrWYg.knc@flex--isaacmanjarres.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-7eaa7b24162so1670280a12.1 for ; Thu, 05 Dec 2024 17:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733447373; x=1734052173; darn=kvack.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=mGLqKj5S2m2Rj61UvNDmOdNoAA7bI8ePX/RHfZ0+49A=; b=qSUQ4UuqFd/GJe9yOedSfyitLumzI3Zqr+hFTzz7nvGM/EAobBMr7gngvCpxfOsxb1 gOc7kVQXkPMz1Wwt4tpyPtXCUdLyPgDWo2S7h9EnfoVFe+bD7NJtQLgpQeoGxgsoGQpX 8kZQRT9vIktlCMzohnQQm7GRZLzYNOULxZ5r/xJIIiRefzS6Yt8Ni35J7jdj0TTuM0Ak wR88saJzUUrtRKdGiQxHUVuDoXimWh0kF5EbLa5pQzYjE/EWfPEZV7khWzsgHnsbC9fx XAs8iW7KwVRgy4D/YOcDFgQu/24gD+aIy9KnJvf0Z1cIWNFngPxJmRINYL9sJHcfqASy tUTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733447373; x=1734052173; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=mGLqKj5S2m2Rj61UvNDmOdNoAA7bI8ePX/RHfZ0+49A=; b=Euo3FEo3giY73XO6/U5AbvffHedXEsW69QI+6cKsKFiPGqrZhzqUgqnJXqyvuHiG/a rfd294UIUa1fvxmQmXDRMUXmC5Kv8YjQxU81KYy1UsiYCirJWZRLs+TRbfWB4+hZB4jI xr8YYq12V5bKyG1zf+TGqGwwIH0yWq+XYZMSDW2otbIai8w1D8FI3MzY65ZVU87c4kaX 0YR9J2KwiJMHXsZ9SXG1mhqEkX0p/Ns5sa9H4fdTmQhLMCPOA9uP3mSPSOXZFMBcQTVV hValfgm8lMdLSU8d3eGdkrCuDyvcZB99P5oPhaAXtm5eloEXlKh/BHTAB1PiO9sXek/l iGDA== X-Forwarded-Encrypted: i=1; AJvYcCXX4bVKQU45RCFMuXtGlraNbDfYboefINjZ2sqGtISX5yBvVYavNYERan5gYeY8mZjSoBliwTdYTQ==@kvack.org X-Gm-Message-State: AOJu0YwJWb/T4mEGCV43ae1F2F2Gd7WS/FOX635hvnvOdZGgfQBB4LLG Vo7ODoUErl7AgCkSJFVKkEuycy6m5lf4J/Gld+h+HlwSm8LhkZ5t8EDSI1xbS7QLIJi8lZ7TAwf cTUE7VgjdP+fBTFh6HZgL3jGcrU3TL/J2Zg== X-Google-Smtp-Source: AGHT+IFPnDgD07jtAFpU33ooDGy+t+dpNNTC6OaKUlNxnqoWnzm0WCjKmNAOIG5jiM0RQhNLAN/4r5MmaJJzsy+7bV7Z4g== X-Received: from pgbdt13.prod.google.com ([2002:a05:6a02:438d:b0:7fd:28c7:fdc3]) (user=isaacmanjarres job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:9986:b0:1e0:ca1c:857e with SMTP id adf61e73a8af0-1e1870c964fmr1724998637.20.1733447373037; Thu, 05 Dec 2024 17:09:33 -0800 (PST) Date: Thu, 5 Dec 2024 17:09:21 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.47.0.338.g60cca15819-goog Message-ID: <20241206010930.3871336-1-isaacmanjarres@google.com> Subject: [RFC PATCH v1 0/2] Add file seal to prevent future exec mappings From: "Isaac J. Manjarres" To: Andrew Morton , Jeff Layton , Chuck Lever , Alexander Aring , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Shuah Khan Cc: "Isaac J. Manjarres" , kernel-team@android.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C74E2180018 X-Stat-Signature: 8pqtigbeuq8wyo5f8rg5pbt3xpniwgm6 X-Rspam-User: X-HE-Tag: 1733447362-450560 X-HE-Meta: U2FsdGVkX18ewFoXrY/h3K4+mvRufi4n3aG39zfLARtgT4YY6skKQWTLqR7FA4l9mfndZgS2G1rxvykh6GvT0IXS71HnRrRifPGfB7k7mM3gFrUsi6PY54f8NPZdDLNmLYeQaLVcveQTARa+Walue0QqlRJnhNUGXift2UDQwbWwr9kGUXCsX8mW4l85oBSd5vHyB8XPyHL8WqcnUdswphLdavsPoWEzWYC7cRew3gTtQS7FUT99/r3ZUB2kJMAYr82CptG8xkcw5+KLzwYPptUUuzQtzu8fJRF+qO4jEa/HqCjNdxapz0oVkn3lQhE4fjt5trU024X1f8K3tw/RF9ON9A46LbUzh7SqVdEYax3Kbhj9QiRKG/cnko8Svi5nuNJtodPB4DrZgmsj9XCgTrg3jaBhflglbT/Veq7sWEK1LC0lokyJ50IpULC+6fEDQe1Z+6PVxbRMwU5Lc/KhMXKpr/7Rl32yx9h7JiTgH99vBrCrIeUff+ikJc6dKcI+Jiy70nAdX1hGt0eUp8SCrSNr/Gv+SGory+DcG1szRXYb7NTegOPGEDK977D4uOObqiL4UGJdFLGNgg/Mxqr9cw023voupRHMt5GOgPN9s2TebAWaIeKzleC456B4tqHwV47G7t2md9Dntwlt27M6MF+2r/CRQj1E/i0IpVxGY8uWWaSi4gvsMqtDzJ38ctR94O6cBnKUkgYmw/lfaT8EBzR3Y5r6w4cLzMyIabrtCXF4+3+iG8RctaSyH1szia3pzELnjXd0r/+j224RdSJWdQcTCiJpYunySKpo/79B09oq1pIVj0tfG/FS3cJOqLDh33CubFuA+F7/2RwQoWz+5Y5DPL2Ruk+6GOc1q6BdjrUlQ1MzRWjozPn1cxNc/BHosmQoTxUQIRbtcllS0FWB2JjVnNkJx39ZSJTY3QD6rVY3feawUGSNP40l0l7jJfgkhknUmZ94jLu21la6Voo 9ooGupW1 qKbKQax6o+VWz0381fY30lk7oX1mrRn3rxm9q2kag8QH2GRzFyb/e0z88VTfcd1G1IS7ve7eMOnWX/zaz1WBLQB+ZSX8slmSpwlGJE7ahc7Ebc2/hkncqzOKPS2KxgG3TtZw8sOrXGwFDN6ZcnBQVYEf8XmypfRhOqt47FLrbdR5iYG9WtM1JU77vPOr7X7pk+9JqA1HIVUK6EHh6QnUkhTbLPngRyUDvdd+IjQd/FUCsRaEYO19b2EhjyqdAXJP5vNEfqXfoc+fvAYTk7wECzhb3fMQksq84XUs3T+gYYLHL4QmLBob86NTJk4AaK/fYhw4HNYcOBpg5RTurP7Tw3OLLjU35NbueSwJFmESUkBkv339YKIQQKq91WTaowZbnJ6KxKl85rvit/NGSkSfhQ3PYVWGdIuubHZDQZBjznqsn+nYJN2z9H2myrHKO0bl3Z4oPErEUkgNhgQ6UCWVR/2DBNWetMLILsfFDFBULp2+ZGgUDQ/9Li4/kagny66AEMy4blv0LKnikrU8/yHJQIOSyuKcWD/YY2yeAdGsFIhDZsR/coBZpZl1ZJfXXuV62Kcqv9m+douq6QNBlsNyxaPabY/A6fd/35sh7uw3mtiBa1rBzr5l4+aoCyHdepYaMOh+W9eRxY5yDAcSHA++MQBxlE7eA1CMc2Vw+j9lCad6rEBXS6X8F5TZww2uJrMrsnCBiKVXTX2e4Am4FdUWHmbD58fDnDec/K5yXBVDzMHWwbeCR5DpnGPDQmftr9mxZdMX3 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: Android uses the ashmem driver [1] for creating shared memory regions between processes. The ashmem driver exposes an ioctl command for processes to restrict the permissions an ashmem buffer can be mapped with. Buffers are created with the ability to be mapped as readable, writable, and executable. Processes remove the ability to map some ashmem buffers as executable to ensure that those buffers cannot be exploited to run unintended code. Other buffers retain their ability to be mapped as executable, as these buffers can be used for just-in-time (JIT) compilation. So there is a need to be able to remove the ability to map a buffer as executable on a per-buffer basis. Android is currently trying to migrate towards replacing its ashmem driver usage with memfd. Part of the transition involved introducing a library that serves to abstract away how shared memory regions are allocated (i.e. ashmem vs memfd). This allows clients to use a single interface for restricting how a buffer can be mapped without having to worry about how it is handled for ashmem (through the ioctl command mentioned earlier) or memfd (through file seals). While memfd has support for preventing buffers from being mapped as writable beyond a certain point in time (thanks to F_SEAL_FUTURE_WRITE), it does not have a similar interface to prevent buffers from being mapped as executable beyond a certain point. However, that could be implemented as a file seal (F_SEAL_FUTURE_EXEC) which works similarly to F_SEAL_FUTURE_WRITE. F_SEAL_FUTURE_WRITE was chosen as a template for how this new seal should behave, instead of F_SEAL_WRITE, for the following reasons: 1. Having the new seal behave like F_SEAL_FUTURE_WRITE matches the behavior that was present with ashmem. This aids in seamlessly transitioning clients away from ashmem to memfd. 2. Making the new seal behave like F_SEAL_WRITE would mean that no mappings that could become executable in the future (i.e. via mprotect()) can exist when the seal is applied. However, there are known cases (e.g. CursorWindow [2]) where restrictions are applied on how a buffer can be mapped after a mapping has already been made. That mapping may have VM_MAYEXEC set, which would not allow the seal to be applied successfully. Therefore, the F_SEAL_FUTURE_EXEC seal was designed to have the same semantics as F_SEAL_FUTURE_WRITE. Note: this series depends on Lorenzo's work [3] which allows for a memfd's file seals to be read in do_mmap(). [1] https://cs.android.com/android/kernel/superproject/+/common-android-mainline:common/drivers/staging/android/ashmem.c [2] https://developer.android.com/reference/android/database/CursorWindow [3] https://lore.kernel.org/all/cover.1732804776.git.lorenzo.stoakes@oracle.com/ Isaac J. Manjarres (2): mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd selftests/memfd: Add tests for F_SEAL_FUTURE_EXEC include/linux/mm.h | 5 ++ include/uapi/linux/fcntl.h | 1 + mm/memfd.c | 1 + mm/mmap.c | 11 +++ tools/testing/selftests/memfd/memfd_test.c | 79 ++++++++++++++++++++++ 5 files changed, 97 insertions(+)