From patchwork Wed Mar 12 00:21:15 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Xu X-Patchwork-Id: 14012787 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 5644EC282EC for ; Wed, 12 Mar 2025 00:21:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A36C280005; Tue, 11 Mar 2025 20:21:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 65337280002; Tue, 11 Mar 2025 20:21:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 51BDE280005; Tue, 11 Mar 2025 20:21:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3279B280002 for ; Tue, 11 Mar 2025 20:21:25 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2432F54F31 for ; Wed, 12 Mar 2025 00:21:27 +0000 (UTC) X-FDA: 83210995014.01.3FF77DC Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf18.hostedemail.com (Postfix) with ESMTP id 34F4D1C0006 for ; Wed, 12 Mar 2025 00:21:24 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=VmXSTIUe; spf=pass (imf18.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.208.50 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=1741738885; 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=HxhTVWfKMvwlygUn42tfW0inla3um9pm5PRUxvke0sk=; b=L5BDEOVYEaAKdu0t+PygvGXWAzivs0WuRAQM39Kk+1aW5Nt+ViBPDm9yJH5VJ/33+8cBdt WmPKNRXCSzryuMzMAgnUwqRK8pEvgJ7qXLW8utBcfXgfiINZMateizvHvjIecrp9bIbzAt /K2V2tmZIbEdH7j7NHNRbQkKnIFSquE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741738885; a=rsa-sha256; cv=none; b=4WiRV4uzVIV7Hm1pvMDNk12E9YyLFJKMvYeDA0Hx24Im4vXPk9xUX14PvYfTOAsmmtsvAE SmWF0cNKlpyxZtPs5dxP/cU5armghl6tKg+NebCfygAxW9Tut4ggHO+aqgt5jshpXx8snr EEPoQx8J9aY0hcsVsL+6GqRUqMklTes= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=VmXSTIUe; spf=pass (imf18.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.208.50 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5e5b736b3fcso809521a12.1 for ; Tue, 11 Mar 2025 17:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1741738883; x=1742343683; 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=HxhTVWfKMvwlygUn42tfW0inla3um9pm5PRUxvke0sk=; b=VmXSTIUeYuqRcLEM4QjO4Kr9UYfkjF90/py7AI5jGbZYEdLc0LeZs8/HPJXEMYN74+ R0eKMJrFKOSAJjgrAkQ/+So0x7BShZnfrSFlyTq15Ov5wQjDlSBt4QX48zx0klrsEdST PvwkIg4t4tjnWMRX2BbkKLKGedQVQKJZZX1D8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741738883; x=1742343683; 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=HxhTVWfKMvwlygUn42tfW0inla3um9pm5PRUxvke0sk=; b=gvHR2jBXe/MUMCenQWGMC21lzvC/1yDiKvlLn8xJ81q4JMNBhJI+iwXGj890Xau035 fo6QEoc24CdCOnf0jq6J/h9eTZicRNVD4gv9VNCYZcCqgbidk3V6Zv/wa6QOtw6Oh3Fs mZncb6Pyov+ajrK0q1DB6AyNc/42RZmW9W8v3zffs5D2oTSmwdVlLnU2HtJPSYFhO7Pg n549c0t47kxe726oOCFzGtN7hNNeRjGk1p2yT05ahuYicBGtWepMNcSgfgwoHpkDQhYD 7QOaRz9B7lQo1p4TXUuRGl5tonl3DK/yDZW8GMBkm/YLp0mBFForKHP1wr9LI3U6LKK0 R8UQ== X-Forwarded-Encrypted: i=1; AJvYcCUd8d69FMXVN8Kn1PsVgQAyLC6D/UBoEoRoCczRKHGUNuf7GqZIvvnHlUB98v+e3vihYKhbILF5Ng==@kvack.org X-Gm-Message-State: AOJu0Yxlv/mJU8YnAN4FFJUavNzUb1ot5cou/NhUTexeSNimv/JB2Jtd E2rnZBJ/ADbDpEr1bCHhGYCbmB3+nfaBt8XF5+jNwzETJGp7U/GPYA6+p/gqEQ== X-Gm-Gg: ASbGncuEUmGVOPWuJEckj/MgGJ7CkHSt0yLQ6uzQY9UjTpKEwxsM3sDvCjZpk7sriLy jBKfqDMRE90QJYf5+DoN5YUTUAIdWUTV9h/l6ZoVGm0UFiAIr7xyk1eVS7kN5XwIdPfbYmxM077 AiBFNMZaCKh+mjWE4V6TYS69XgO6qA10ag8KdkHNBGhhoPtdsNwf/NQBFObKxBK6z4IZltY/16x BcthHut96VBeJlJZCZL4QRsOU6soVLJWhuo+vzUcxwUxcmm7YfiMToLphqBG2ecrDB61UdaIO2U 17xy2+2ZOywE+q2p/Mi+XPwzwB6vHllrNrVhKyFVZg6VKCSvTDARJitysk1XIwTwKPkOlVTO1/q bfFnjLaBhVPk= X-Google-Smtp-Source: AGHT+IFtgvPPWm2btr1Xtn33I57TNFhVpEuzGkQix5y9M7OehAhXbs7W3QjpSSzY3kDwK7gNa2Zc0g== X-Received: by 2002:a05:6402:270d:b0:5e0:8b75:5470 with SMTP id 4fb4d7f45d1cf-5e75f2b404emr3051425a12.5.1741738882887; Tue, 11 Mar 2025 17:21:22 -0700 (PDT) Received: from cfish.c.googlers.com.com (40.162.204.35.bc.googleusercontent.com. [35.204.162.40]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e5c7669fd0sm8846503a12.51.2025.03.11.17.21.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Mar 2025 17:21:21 -0700 (PDT) From: jeffxu@chromium.org To: akpm@linux-foundation.org, vbabka@suse.cz, lorenzo.stoakes@oracle.com, Liam.Howlett@Oracle.com, broonie@kernel.org, skhan@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, keescook@chromium.org, pedro.falcato@gmail.com, rdunlap@infradead.org, jannh@google.com, Jeff Xu Subject: [RFC PATCH v1 0/2] mseal: allow noop mprotect Date: Wed, 12 Mar 2025 00:21:15 +0000 Message-ID: <20250312002117.2556240-1-jeffxu@google.com> X-Mailer: git-send-email 2.49.0.rc0.332.g42c0ae87b1-goog MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 34F4D1C0006 X-Stat-Signature: buxkhjwwz7xgoknr7xinyrqgfka8azww X-HE-Tag: 1741738884-165799 X-HE-Meta: U2FsdGVkX18IsuMJ8++g7xDr4qjb8QK131lKD3GNca4Jinn/51kZ+X7z8ykrgtjPQjCPQvRzDYp19aFH0V8KmRIARdwhI2+4+noNU6L1HVSF1mxU2Xjyqvh0QfvhhnE4g8GKFLqajZ5S7BzD3gPLzcAEOUpzqVPJYaGFSvu/sRZc/JUXmdAJsr3cQfRh3LNzDhCQG2mkXRMw090V9tcsY5L8TjwY9GUqobrLF48XDQ32ZNA7OPuQ/F3Q1enQ02DxYbZIR5NBY1g8Srt2SiiUbuXJQy/K9sjBXO7v7t3RZi8VFJ840ESeohQ75Ksa05dhTRfQmnMFrq0kxBI5FpTwCnFOiUrjQiIa6fus5/G4xbpgXVjJtzOc4QLC53JmehWM6zyr9cJo7+AE8iO4xJLQk+T7cfX5BSr1ccK99vNq/rinuHsNnUile0oMRnoDuIVtgcsSSD7smwcl3x1OeiM7Zw0x9Ogq8FJJ58bpUBFX+D9W0IKSOdA/Fa9xiY5QY9RxYQHew5Bk6K6IVP2W9D7m1gQb7hWas4xfvD4WZxo1FlYLZ/kTRX2w9xAwuk7S1XXxRjLr82as3b7nCpxdiVGv8cJF+pYpTKbxafNk/IVu2CDRbcyv+8608NIU3MLTExs6pQI7D0UiZg6QuqtNd088d0lJSPUG0KVpprvEQ0ldLVJJlcZfViREPZlL0+CGTzYKlts/zr4aluoktOOQ7T7S7ibJKpyNsRJoYIRZYqrC5s4FEmf3jMK8p6czsnG/CHk/pW+RylWCKjnFBex03jDik/aFnxC9ScJ8Jf+PqRBDLWpUny6x6IMHSOWCjkAdr9T4GoZFN2n1Q7snx0U3fiWOsTZNYTPdmGdeHK2QZvGk3/tite8R5MzYn3LsOxkC65SHLvbQNyL/11n+LFzAFFO4gn9k2IEV8XjPErkY6JwhuDWqE/jcaNYh98XFwKi8ocROJN+4KugonDQE+gR4S/1 FL0/I7Nm TnWmeBk/+JlVtS9TqBlXQ2bSyuAGoaTHUUjZstVcdoIelFL6ZWHA/nH3dqPEjg4xj+MsJG51irh+NzyOaKVKL3D5SK0OlRzgvlLotqNMmmIq7pjFapTlkiuQy7xY7wp7RuK74Hsz1iX9TJ97EwOjxoFajhnSiZ4S+hYIuPSvMRHiehq8SJlmdR+Xlu1w3Nh57rvbxYpCVPt74pN0LCgori7ROqzNHMSC0hw1G+elKBku/vmITnzOFtmwnyAfXa1+6bSGpZrf22Zv8Y2FthufQQJKkbP/psKve3WisWvdX6nhCXfv9OpFY8gZecapbkVLfvPjgzgVRRrabh6dAuZ9hILH2UqWwSQQ6yYX3iw7gwoGFnxOuctWQMszMEAbBNoLYuvBmwE8BrE5DLVVzanX3Pa41k3IP66u7Nln3ijq1FRIh2RU7KMA9d+x6gQ== 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 Initially, when mseal was introduced in 6.10, semantically, when a VMA within the specified address range is sealed, the mprotect will be rejected, leaving all of VMA unmodified. However, adding an extra loop to check the mseal flag for every VMA slows things down a bit, therefore in 6.12, this issue was solved by removing can_modify_mm and checking each VMA’s mseal flag directly without an extra loop [1]. This is a semantic change, i.e. partial update is allowed, VMAs can be updated until a sealed VMA is found. The new semantic also means, we could allow mprotect on a sealed VMA if the new attribute of VMA remains the same as the old one. Relaxing this avoids unnecessary impacts for applications that want to seal a particular mapping. Doing this also has no security impact. The mseal_test is also modified by this patch to adapt to the new semantic. Please note, mseal_test is currently undergoing refactoring, and eventually will be replaced with a new memory sealing selftest. In this patch, I only make a minimum change to make it pass. I considered adding a new testcase in mseal_test to cover this new behavior, however, the existing mseal_test is using wrong patterns and won’t pass the review. Such a new test is better to be added in the new refactored memory sealing tests. The refactoring is currently pending review [2]. [1] https://lore.kernel.org/all/20240817-mseal-depessimize-v3-0-d8d2e037df30@gmail.com/ [2] https://lore.kernel.org/all/20241211053311.245636-1-jeffxu@google.com/ Jeff Xu (2): selftests/mm: mseal_test: avoid using no-op mprotect mseal: allow noop mprotect mm/mprotect.c | 6 +++--- tools/testing/selftests/mm/mseal_test.c | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-)