From mboxrd@z Thu Jan 1 00:00:00 1970 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 CEDB9D2F7C6 for ; Wed, 16 Oct 2024 21:26:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 412CE6B007B; Wed, 16 Oct 2024 17:26:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C2D66B0082; Wed, 16 Oct 2024 17:26:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 289386B0083; Wed, 16 Oct 2024 17:26:20 -0400 (EDT) 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 0AD306B007B for ; Wed, 16 Oct 2024 17:26:20 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6FDFF40A57 for ; Wed, 16 Oct 2024 21:26:13 +0000 (UTC) X-FDA: 82680748584.25.539DE3C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 992AF40013 for ; Wed, 16 Oct 2024 21:26:13 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E4ZVdQXA; spf=pass (imf12.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729113834; 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:in-reply-to:references:references:dkim-signature; bh=h2PTrBoqOI1etAsx/wQ9i4bf0VpjOqrV9yRt5CjB5I0=; b=ZwQ1gvl/GnnAkgrLOdc1d4KXwY1A7Ac9tRcn5G/YwKtA8Q7RSPpd7ieaaMdKpLd/wnIvWs kiiY9CkaeTXMLUYkNfj0O0aXGvNWIL5oKreAWlzOT+KqrdZonm4BV1lmjpS7n3LUTsWvt1 dbmxRrCSB2/H00m0p8ie7dX18CvZyW8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729113834; a=rsa-sha256; cv=none; b=PZx+DJckO/21xXUE5QVjIhl1BqgiqI4OyoakrPrtSis71zp0k3ci3WvM660IzwXiG/H0TZ YCI0iHL9W/ggb6qlpRbSXNt4+lNHEq+nJ1zDkpYGrl9jN/cDb4O59XNIGM0eyl8M5DUfGZ wL8J1z3dSf9u5s3/DzPCC3YI/zwazpw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E4ZVdQXA; spf=pass (imf12.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 565225C5B94; Wed, 16 Oct 2024 21:26:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E26BC4CEC5; Wed, 16 Oct 2024 21:26:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729113976; bh=w2AniAgKUA3iOAqj3cDVFxrqdHgqKwGWULpMr0zhr9s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E4ZVdQXAM5yf8VYAXJnchAT4o0+WSx0YVDSNkWnhXo25iJ56AiSQFc2RzAHjStxBR 0+Mi9nWaMS0673bDbT9wAx4lBTKdyKBinZ9LTRw6gNG4LHtmHhCJ1y4GPtznvX9A7s pF0gmcOdle3eA9YC249VOGVVlvZ0rJ/XQNtzgUgPQhSlN+Zww4J5Esi30H3y3qMKU0 QO6pL0a3abUM/5rJqiTCppVvS9kKtiQr/swm9IiImXhd0PsSeARBzXtQOyk0+XB0nV r6W+gxsmelg1cP8MBc8A3z2/D7bhkQzGbUtGz74L7fjR5+yw88oREwl7Qg5Cz/pPYE jFNzIpLJ4iL3A== Date: Wed, 16 Oct 2024 14:26:13 -0700 From: Kees Cook To: jeffxu@chromium.org Cc: akpm@linux-foundation.org, jannh@google.com, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, oleg@redhat.com, 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 Subject: Re: [RFC PATCH v2 1/1] exec: seal system mappings Message-ID: <202410161424.FA6DBA7D91@keescook> References: <20241014215022.68530-1-jeffxu@google.com> <20241014215022.68530-2-jeffxu@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241014215022.68530-2-jeffxu@google.com> X-Rspamd-Queue-Id: 992AF40013 X-Stat-Signature: innrysjzh8gxc6ywpkb98gqb1qi9j7ab X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729113973-420243 X-HE-Meta: U2FsdGVkX18fPxqAkk0JJ3GvhI5qidIW7I09xvao+tciXNc49V4lCpXEGshvrawnvxB9NL6SBdnYgXwIs8z0+z3atcdSQLw71bnOkKLrikWFHSe8XCcA4jHzsjo9lp0IJAbXtWXwfSR9AW55MNmXZ1O4YUqTIvJiOmWE5ysQyCV/HicGIb6aBWihZ4uDUQQG5Mpks/rcj/oq1QEE+gWPfuWEuRZeoZ9doKH5WdW62v+iTIYWUu+vtYUT8aBlGNRScwsbxM0Qn1CI/SvoNTKvaxBJjT+XN7udM9x/a+skQYi0WVm0z2c1gi1hnAqdtgF19K62FGM+VyBYMV3bLIguZTlFHcPg71TPFDlFG5yeAfXMExSh2brPOlXupz0aIPNAPTgedDk9ZGMfQW9X3Dbj58KmCx0B8sUlv8nqywcaP18EUyI76x2g8MGz0xQfEKLQwtGh8NqhL1hTZ6eJkFXlyh2Yz6VVVDfJ+ZH2NtagdKKHBddbSspgFnhLykifpMzDMowIPqMudTZWXmXpOCgyEFNNeFMJap+NMkGRCbpj2xGBulm5ig515CKHQU/ONQkqURsuya8A2kBBGMTygSMz2rSDcix/lD8h0EBKjuQllo+4cI3dx2+g7mC2+U4kQYxLJAJTRn0eRi2k4cTf8L8nmXqiFiUQvdKVCLOk4E4jcFopa25FcSwTTAfz5q7r2qT7DmMvVCnZzF4qpw8ZDwRCv2jk+T6BxY3FcTv1/MsCwJ6hRqsge/Elcdvqe4OEKLbMFpfBXxgzPDXR/eiYycAjS96XUmoLnxGwP5vgTAoApQO8wIrqEjYkPgk5RIigjBFI8YZmGLRz9xQq13pkmRP8oDgGIKZTeZI0QNmn1EsJdQsoSee38A4+WEpYC52JSZfGmVKPL7EElpIPAipjyeVHFoOpfYpMNPxlIJ7jx/wWUgfNXOnN06t3uPJjmlBZeNnJ4k9b+v2tKWEvKTI6LBK 1klGFvVe chC5+52WzG69For1UL3IejbT6KfPLhXDlSIlqtSpNJknv0bWLu30WSq1rv3NK6es6P5Y7oQQqmSROrIxTj1+YoNDzuQ5XP9pJMid19VdljQTvnw3QI8iUQvEfwzWZlmduhHYDsQLcei2HCMNI7D9v/tPIVdRrHfd3NgqGd+ZNhTWNcoqobdaO6wk4j8PFTDRqrKIzqEZXXq9/HZQOebgw9366vWWwvVcgM5ouedU41Zcv+VN8oqt2xxPg8CZQGw8jfPt6+1BXa19Fpp2HRw9PidmISfaB+3N+kMIR0iweGFp94X6j3sybNLreiOBLRPCB2e7rs5HfGx2QX+T+s+UtaHgOjNPy3aAUTcHNDQkC/jLBGOQixLSc1x/XT4LyGwGPAKlnhts7wdRhq2U= 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: (I don't think this needs "RFC" any more) On Mon, Oct 14, 2024 at 09:50:20PM +0000, jeffxu@chromium.org wrote: > 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. > > [1] Documentation/userspace-api/mseal.rst > [2] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@mail.gmail.com/ > > Signed-off-by: Jeff Xu > --- > .../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(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index e7bfe1bde49e..02e5eb23d76f 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -1538,6 +1538,16 @@ > Permit 'security.evm' to be updated regardless of > current integrity status. > > + exec.seal_system_mappings = [KNL] > + Format: { never | always } > + Seal system mappings: vdso, vvar, sigpage, uprobes, > + vsyscall. > + This overwrites KCONFIG CONFIG_SEAL_SYSTEM_MAPPINGS_* > + - 'never': never seal system mappings. > + - 'always': always seal system mappings. > + If not specified or invalid, default is the KCONFIG value. > + This option has no effect if CONFIG_64BIT=n > + Any reason for "always"/"never" instead of the more traditional y/n enabled/disabled, etc? Otherwise, this all makes sense to me. -- Kees Cook