From patchwork Mon Aug 14 08:40:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aleksa Sarai X-Patchwork-Id: 13352562 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 3AE65EB64DD for ; Mon, 14 Aug 2023 08:41:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B987C8E0002; Mon, 14 Aug 2023 04:41:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B225B8E0001; Mon, 14 Aug 2023 04:41:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E9518E0002; Mon, 14 Aug 2023 04:41:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 88C468E0001 for ; Mon, 14 Aug 2023 04:41:33 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 487CC1C9296 for ; Mon, 14 Aug 2023 08:41:33 +0000 (UTC) X-FDA: 81122066466.30.6A05A1C Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by imf13.hostedemail.com (Postfix) with ESMTP id 319B020014 for ; Mon, 14 Aug 2023 08:41:30 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=cyphar.com header.s=MBO0001 header.b=eX0Te5I6; spf=pass (imf13.hostedemail.com: domain of cyphar@cyphar.com designates 80.241.56.161 as permitted sender) smtp.mailfrom=cyphar@cyphar.com; dmarc=pass (policy=reject) header.from=cyphar.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692002491; 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=NUboT/tyGwRN+QiGFmvbhFhtxEwoPw7Up8T9SpZltac=; b=xiUrUldrQG1sI1YDE7M4lvGkwDxAdE/vtAL2HcS/00xKFGbmYRpUz4xlumx/Drlh+oGYRT AIOTqkV740HA4BwZUDJein8bG6UrxzrluO3/lHDtjRh6sukP5IYKTWjcGnCRxBZRlfGvqP l6ZB9oTb5wYlUxYNmAsAJrT3+ktcGLY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692002491; a=rsa-sha256; cv=none; b=FEL+u5Iq+7aMydrT5ei6vl4QV69DZyYr8RhKIcIXD/UjpADwxNUccllWjvpACottVt5OwQ Z0MIQIH5OpYQMBz33TO+oTRP5Z6/disyew1Td5YlVgoxbiApuAIq0q4tlDGMKHUvLfaScr El3Q84zu6vdM+e9CCZS4M8CtDveoUHo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=cyphar.com header.s=MBO0001 header.b=eX0Te5I6; spf=pass (imf13.hostedemail.com: domain of cyphar@cyphar.com designates 80.241.56.161 as permitted sender) smtp.mailfrom=cyphar@cyphar.com; dmarc=pass (policy=reject) header.from=cyphar.com Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4RPSYL1pknz9sSk; Mon, 14 Aug 2023 10:41:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cyphar.com; s=MBO0001; t=1692002486; h=from:from: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; bh=NUboT/tyGwRN+QiGFmvbhFhtxEwoPw7Up8T9SpZltac=; b=eX0Te5I6hNL8L4CL7n0OvdpsIRx4kaXqNueehUKepAeG+Sd+Qq6MBXlO/GGJcDWfbD1lOC Lhw0bL0MfKg0xckibbKAez65geHBSd6Mtac8QgW1XaPyPzBmGXmZprz145Kxo3BwIO+9jW gOKc4k4SN2vFpEYYAWDcQYJT5KrrtqcFlOrZjJZ2lJaXaEhESt6MVnd7KmLzcKxmkqWD26 d0Y3gAkGH3kU1kTNNlZbs3oMc85pXONy+EVjrpylEl7dIW/Tzfz5hbSB6TCNqnlE1V98gp V6dYzAVf/NZqVl2RJR5ycyGZ9Lj0aOOjqtpbiRurgTcp/+QYLhVNis6HvTF3jQ== From: Aleksa Sarai Subject: [PATCH v2 0/5] memfd: cleanups for vm.memfd_noexec Date: Mon, 14 Aug 2023 18:40:56 +1000 Message-Id: <20230814-memfd-vm-noexec-uapi-fixes-v2-0-7ff9e3e10ba6@cyphar.com> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAJjo2WQC/42OOw6DMBBEr4JcZ5E/BKJU3COicMw6dmGM1gSBE HePIUXaVKOn0TzNxhKSx8TuxcYIZ598HDLIS8GM08MLwfeZmeRS8RtXEDDYHuYAQ8QFDbz16MH 6BRNog428mrp5csuyYCQ8i7x/dJktxQCTI9Q/ZSOUqFTF6/IICQLMOjpN7TdKE8Ohcj5Nkdbz5 iwO4f/zbt/3D0hF7PboAAAA To: Andrew Morton , Shuah Khan , Jeff Xu , Kees Cook , Daniel Verkamp Cc: Christian Brauner , Dominique Martinet , stable@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Aleksa Sarai X-Developer-Signature: v=1; a=openpgp-sha256; l=4851; i=cyphar@cyphar.com; h=from:subject:message-id; bh=dGi8A78yZ0SfEXLJu8jrgDZL5aiUP2hWwUC4ADrzENg=; b=owGbwMvMwCWmMf3Xpe0vXfIZT6slMaTcfLFsU0K62YabZfmtzopLqiwzPh5c/dZd3uq54Z1Xn THv7Q3yO0pZGMS4GGTFFFm2+XmGbpq/+Eryp5VsMHNYmUCGMHBxCsBEfngz/OFT3n66XilEuWbV v0+5m5bWnF12LCrPd3HIo8dCHS0L1r9l+J+iJJdq8UqKraznccSsZybhN99m7+KUYddfLz254YO 3JRsA X-Developer-Key: i=cyphar@cyphar.com; a=openpgp; fpr=C9C370B246B09F6DBCFC744C34401015D1D2D386 X-Rspamd-Queue-Id: 319B020014 X-Rspam-User: X-Stat-Signature: k8oou3xt45zthfxmdu1yop7e4q4uokro X-Rspamd-Server: rspam03 X-HE-Tag: 1692002490-350777 X-HE-Meta: U2FsdGVkX1+CL2O2ZK30M/sCf7cGoNWJ/kaKC8L4QMkrsg7cbMr74ytfzq6OTGRXrXlgTBXV5hLoN3sqwwp76U9/gDfnqpTsCLZMfXFhRmk3PmAj3gEYdv/2BnOAFJ70zAlu7Tm1vvfD33YXnrWtfOwI6u338AK7NJVuwKEuMZHLqHcvE0rtf1Ng93T68a+eT0XxoM4uIpf/irTYj3p30fvuIaAEI9CPFQfnLRHA3omViIZZks+UM5urdNL/kxl9O4VixdlqToAT/7cG4wmm0oGqb10+cFBwNxneAUITdERHDkQENH27VeSuSDy3iAP/UxyikAPf3sr0bxOIIZQM/7fBcGo5cdiHEbTCwwvgiWlY44pLnD2l4ZmU5DgDVA8QvR4blNQka9EOHuLMnM1ORPNUPLSZ7jKRBKB3iq7/NugOtkR1uWILpglPNp/SrBFzcWLIS9Upuxsy3qX1BQWbHzEmW8oghTYT4SQJrt6jUgKC7hFGsm2HZoDMvFbRy+IpYYoe899E/mDl9dsKX+ckbbV1LMzAab/1lHSPiWLym/bTOwYRYj8YRfdmDG7oU84eiuPrlL0az12YPHSdJvo45sLRYmIgcEQbnJKTs+hYueLoISlYYIETjcjvmNoJvRcIPFhHEw+MGdyuFqi3gu6X9AGxj5rbfS/YR5xVD0JQqb4QzRBEZYw+x4zDy4cuDW2xY9GLYGaQ8xLFHwqfC+wiBRgbCVWHtf0UqkKqXAcD0K6ERnNcLf8g1BH2rx1/cZetRcvVJNqvpaD2NgZjgFkrd+MTcx5kXRRGgIEWF7KyI63phLfzV6niKwlfpT7rN2K1UaeaKU83dg+E4AUDXl/rLlq6OTQGxeIfZ4eZHvjl3jvUrMys/wKcKms8yoL8/VQvPKVCFbCqhRNTFaO9jReZYZQ13UFJ0BNQnvyFjVzcBPn0py298TCs8BO0FMTeWxKYieqei3SktCqIYWh196M g40x4gH4 2GIG30Efqafw4iXimyH0jFXK1irw34dmkkTVvrFRwEzSq67QE4o3kYO2/+Zr0QiKUAM00CvLPA1Ky3hFwoaQjN/uToLxy3cCu3BVS3YCEK9Xya2bB7UV79J30Vu8ZiI5M4nupabQ94dQBAxWowXNAgQQF+ITfulkNxvY6njLoTbS1KZpVYZm2g0o8BST+yyD6qnUy5EvLrti8Dm/t5jp2QWQxYttWJ6keN/4wsf2oKPiInQX5eWS8HTo9OHju5dqcAatkE/BG69Jr2QhHOa7Q+hDh+WbFK+S5fNb+zILg6WIwHKNSDc2N/AZIwmi0stVzJ/wdKJu9+pNhwuW2hH6+knBZKcPMZ0cPHKIzC9vRrLqsAyQBgAtAcyxU0kT48ZyMU+UmwBxWMLSgvgzq0+rO2rSn/jAnZTqYuHfn5zmEu92BQ54qHykYTL7wLL33lkt2mpvCdICsw2ZqLQQ= 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: The most critical issue with vm.memfd_noexec=2 (the fact that passing MFD_EXEC would bypass it entirely[1]) has been fixed in Andrew's tree[2], but there are still some outstanding issues that need to be addressed: * vm.memfd_noexec=2 shouldn't reject old-style memfd_create(2) syscalls because it will make it far to difficult to ever migrate. Instead it should imply MFD_EXEC. * The dmesg warnings are pr_warn_once(), which on most systems means that they will be used up by systemd or some other boot process and userspace developers will never see it. - For the !(flags & (MFD_EXEC | MFD_NOEXEC_SEAL)) case, outputting a rate-limited message to the kernel log is necessary to tell userspace that they should add the new flags. Arguably the most ideal way to deal with the spam concern[3,4] while still prompting userspace to switch to the new flags would be to only log the warning once per task or something similar. However, adding something to task_struct for tracking this would be needless bloat for a single pr_warn_ratelimited(). So just switch to pr_info_ratelimited() to avoid spamming the log with something that isn't a real warning. There's lots of info-level stuff in dmesg, it seems really unlikely that this should be an actual problem. Most programs are already switching to the new flags anyway. - For the vm.memfd_noexec=2 case, we need to log a warning for every failure because otherwise userspace will have no idea why their previously working program started returning -EACCES (previously -EINVAL) from memfd_create(2). pr_warn_once() is simply wrong here. * The racheting mechanism for vm.memfd_noexec makes it incredibly unappealing for most users to enable the sysctl because enabling it on &init_pid_ns means you need a system reboot to unset it. Given the actual security threat being protected against, CAP_SYS_ADMIN users being restricted in this way makes little sense. The argument for this ratcheting by the original author was that it allows you to have a hierarchical setting that cannot be unset by child pidnses, but this is not accurate -- changing the parent pidns's vm.memfd_noexec setting to be more restrictive didn't affect children. Instead, switch the vm.memfd_noexec sysctl to be properly hierarchical and allow CAP_SYS_ADMIN users (in the pidns's owning userns) to lower the setting as long as it is not lower than the parent's effective setting. This change also makes it so that changing a parent pidns's vm.memfd_noexec will affect all descendants, providing a properly hierarchical setting. The performance impact of this is incredibly minimal since the maximum depth of pidns is 32 and it is only checked during memfd_create(2) and unshare(CLONE_NEWPID). * The memfd selftests would not exit with a non-zero error code when certain tests that ran in a forked process (specifically the ones related to MFD_EXEC and MFD_NOEXEC_SEAL) failed. [1]: https://lore.kernel.org/all/ZJwcsU0vI-nzgOB_@codewreck.org/ [2]: https://lore.kernel.org/all/20230705063315.3680666-1-jeffxu@google.com/ [3]: https://lore.kernel.org/Y5yS8wCnuYGLHMj4@x1n/ [4]: https://lore.kernel.org/f185bb42-b29c-977e-312e-3349eea15383@linuxfoundation.org/ Signed-off-by: Aleksa Sarai --- Changes in v2: - Make vm.memfd_noexec restrictions properly hierarchical. - Allow vm.memfd_noexec setting to be lowered by CAP_SYS_ADMIN as long as it is not lower than the parent's effective setting. - Fix the logging behaviour related to the new flags and vm.memfd_noexec=2. - Add more thorough tests for vm.memfd_noexec in selftests. - v1: --- Aleksa Sarai (5): selftests: memfd: error out test process when child test fails memfd: do not -EACCES old memfd_create() users with vm.memfd_noexec=2 memfd: improve userspace warnings for missing exec-related flags memfd: replace ratcheting feature from vm.memfd_noexec with hierarchy selftests: improve vm.memfd_noexec sysctl tests include/linux/pid_namespace.h | 39 ++-- kernel/pid.c | 3 + kernel/pid_namespace.c | 6 +- kernel/pid_sysctl.h | 28 ++- mm/memfd.c | 33 ++- tools/testing/selftests/memfd/memfd_test.c | 332 +++++++++++++++++++++++------ 6 files changed, 322 insertions(+), 119 deletions(-) --- base-commit: 3ff995246e801ea4de0a30860a1d8da4aeb538e7 change-id: 20230803-memfd-vm-noexec-uapi-fixes-ace725c67b0f Best regards,