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 70EFEE77173 for ; Fri, 6 Dec 2024 17:49:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2BE76B02B9; Fri, 6 Dec 2024 12:49:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDC8E6B02BA; Fri, 6 Dec 2024 12:49:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA40C6B02BB; Fri, 6 Dec 2024 12:49:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B64906B02B9 for ; Fri, 6 Dec 2024 12:49:50 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3C37CA1F22 for ; Fri, 6 Dec 2024 17:49:50 +0000 (UTC) X-FDA: 82865271090.09.D8096C9 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf25.hostedemail.com (Postfix) with ESMTP id 07588A000C for ; Fri, 6 Dec 2024 17:49:35 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WXNX6oq6; spf=pass (imf25.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=kaleshsingh@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=1733507370; 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:in-reply-to:references:references:dkim-signature; bh=xJX3AeNdAYoSbc5Ua6KEly/YydBSYF1iDHSbiQeKmAI=; b=CHO7N6eYUlVPBA9fIfSqoJo0v4tN5GCMu54Y0ucB80t/E9CcxMsVd5KLxgkXzpf/iO2pNK S9htiGobk1Vtx+oqhlGjxMnvFUJDedXqGShknn3w/VHqdIrnvxhyAWX0N2xbK/bDfMLBLk KlSl5jL6izoawr2a7+IRFLpLdiEgGVo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733507370; a=rsa-sha256; cv=none; b=hIc61yACYpiVSsgpEmAcGtVteXG69Bm0SHgaF9/aB1jnHzWalMN6GjNCnTdIlM180yKMal v+gsP9GZ4lrIgu+qDasihjkYDq16p3fxOuX/lLICCwM6i2wYEmx/rzf8AOIsq1F3Al30Sw Bk7E+mJhk+D148yWWCKfweckjRUVsXU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WXNX6oq6; spf=pass (imf25.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-21625b4f978so56565ad.0 for ; Fri, 06 Dec 2024 09:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733507387; x=1734112187; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xJX3AeNdAYoSbc5Ua6KEly/YydBSYF1iDHSbiQeKmAI=; b=WXNX6oq6S+1or34swIghKAX9e+IYUC/77QppluOtsKJTIAAczAP3bN8GytcEUH4dua QQwf4g7qo0HltP5fmfUof92aULmDGx3wYu17nTkCp8anutp6Ng0LucG8AVOI6T8S9s1j 29zpAlFsmlnZV+pbxASkRuyAOjIvjgpbxmcfjnqRa7lt7MYjGeAvDBFhsWrwhNdY+0rq ba1bEZLKvJls72ip/XMeWxI+6YAs2sr3yxYzQGMrHNIrzssnGP/eSWN03Ee2qFLMtns1 OD6Z3tWlQHI6AAO0K1VfurYRTrwJCt4fPbhz+IWV/JF+1ea4uv8v3AdgyNi019UUXHh8 7R2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733507387; x=1734112187; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xJX3AeNdAYoSbc5Ua6KEly/YydBSYF1iDHSbiQeKmAI=; b=c7zF1M2V1CQNJdwuPDaSnnrHrZ/ZsTGxNFhDaquJBbwjJqQG+7NScClbgXnhPbtTdC niU0LqBg24X6/x1yE4O/acRYGS/kVJ+p+Se6wEHfX0fo06RBFQl5u5xG6jKDLejSIVLu bU8hW8GUgGEJeW8JuVkhqq/G8vRYmwh+akArjENgmVJVcqqICEMlu7rO7wb20q2635PR b2qQFe7XZOP1pSqlKMgc5niYzMZYI8V4nnkWhp/6uJXPP8OTy4Vvmx38DzjQcRrO1P0T R8EOtEwZ4If1nVR49G1vK+AnNCcrOnNFK8p0BNluSo7Pcy/FZ9n+b0q4nmGW8ix2AJsn fJnw== X-Forwarded-Encrypted: i=1; AJvYcCXz6P6IWUfoOGYHYS50/SoHsews1Eu2DxekS3ZqOZn8MElsDEDxz9BTUMwTtgGzbqO/vp0gg0AvzA==@kvack.org X-Gm-Message-State: AOJu0YyBOoSu8PH0O1wc9Xx0yF9XYXR8Zz2iMyrm/KaaAo6wvKDrQ1Ll t+xGYw1xSzKziwRG2DvnLMpP9s3FPWd6yrPMSLSTBR2rKSzzLZiTJ2zuH7zxcjLg27nMc39Bhvd x8OYBWLsM0osdZOputgpqPHB+rNczil6FJGqU X-Gm-Gg: ASbGncs19Y2AhCq18rQ5mNAQ7x7saB6zV6i2qKmExB9nDDp+HvyFM0e8cNUESG7dcgR oF4l2NykzyxJuv8ekywZu+HGI8GiF/bplF7kuSwiRhIEFCUdm4SWyZeKNFy5ytryb X-Google-Smtp-Source: AGHT+IGfFI/XAFWRnvadh9nU2CwBaiNbo2MVGQ6VycR/E364RCB3UsSrcfvM50twmVKO1ZLiV5wWhjjpMpQg9cmBCTM= X-Received: by 2002:a17:902:ce10:b0:20b:81bb:4a81 with SMTP id d9443c01a7336-216172772f2mr2385875ad.7.1733507386833; Fri, 06 Dec 2024 09:49:46 -0800 (PST) MIME-Version: 1.0 References: <20241206010930.3871336-1-isaacmanjarres@google.com> <20241206010930.3871336-2-isaacmanjarres@google.com> In-Reply-To: <20241206010930.3871336-2-isaacmanjarres@google.com> From: Kalesh Singh Date: Fri, 6 Dec 2024 09:49:35 -0800 Message-ID: Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd To: "Isaac J. Manjarres" Cc: Andrew Morton , Jeff Layton , Chuck Lever , Alexander Aring , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Shuah Khan , kernel-team@android.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, Suren Baghdasaryan , John Stultz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 07588A000C X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: gxntmjhdwj556zry5jg93pe1pqwrgf9w X-HE-Tag: 1733507375-735875 X-HE-Meta: U2FsdGVkX186/LiNKEHxLdLF/nznmhB6BJ21gc7+1hb0swqq9aidte836/d5cz1CMUuxyvjj8v8Jr6PJ8ridP7mRqP/gnPxfJf31ey+PueX2YSHuZXvRWlWcSsa7yJ7CTGiQoN1m2FoAzQtnTeE96DSBywHg0FsfXAtarFcfQwIQtR8Nfns1dJLTv3Xp5DCCeMGTOaeWuEJJHW9OpL6aVCDulklWXRXPZhMWlllR+XeAMIxI3ULRaF/xBXmnLjaXDCOGrBo90gvpmgmoEYRHBzEL8mA0+lG4ZZIhGsNH1SF7U/CX41bHi3N7mHLjvS0pV/4+TNGOHsW0izxhfoHK9Te4wBrU01KGsnjz0CF5xfKQdyMnFbulXZn7eJiNxNiVVoXbP/zwSGEaKfAcdNlDr3bSg7eq+8WwsB/HttUBLKTk4UJT9HUHOzXw5eQobFlBEMZqX/Ll12g5iHzhjlRAQ0fZEeZLusEruS+dcgFG1GhxCNy4AX5om7KM/wWB2//X7hxvnaMqD8xEAVIeK01Kr9wke3zNJ/tpAw8hwnn7PrvhKL/416Fta4IosXRnE/VaC2mSxVHTV7Uu38fi79OuPvR5O2hP2BekuTxTPtGNa70+Yx5b2WkDG+B6bYMhN4uT6OAMrnOgNiPyTV38gZwNSxstxrZmd2YkjWrPHBjHEHHmollBbABlvzPXDraipOmm0mT49BQzxwpZF01QAXvXiSr8mx7Uwk6kOSs6y/o9TGb0DZiVJYctB53N1xs0x8nE7Q4T37Vm0s6ikz4VgTEtPRCSZiHQ8l3jd8nMyQjRnIA0E/EkleWA+BNYSx/NX4Nz9IgQ9pOP25ryMYfaRziu8gcIwhMe0LYAli2v9hZ9322sw1uYkdsZrwEVUH5EPY4Db+22QEB1iQKougyv4mhpsAKyqEERQIhmGdA25J/4FddbN63hZjdmUuHDZu8IghC+zleX3Ma5g1uUZS5TOJh NNBlCFmX nl252SxusoKVu6Yc7Q6bK0Irnnd3FwJ0NAHi0XawKsb8ISivj8xrtNU7EFLxYj5pxE6eFPdghyQK0CiG5ou11KvoAzS/EW5WKTtgF6rv0cvyHENkqD7S+T/5LPq6/z+mpSjNf7abmRRhrY2Wkfzw8OKFJTgQ4suCu68/CxoQPLlU6xisGzTvTPKqqapa7iMl7SUScmOdVCnbZp8Mqm0A/F85ed6KR7yo2Las0sMsSor3/p6BxEsandy5deiHNnhP27gCgEthbiT/WIhC/CrdFHyEkgMRDO/pjN3iNhzt6jco/S545PbH3mbieAtF2H/GOWCwupP/cCbPB2bwq6oLSbLZQLDHf8FIII+UDdG7AcnTVfGQ= 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: On Thu, Dec 5, 2024 at 5:09=E2=80=AFPM Isaac J. Manjarres wrote: > > Android currently uses the ashmem driver [1] for creating shared memory > regions between processes. Ashmem buffers can initially be mapped with > PROT_READ, PROT_WRITE, and PROT_EXEC. Processes can then use the > ASHMEM_SET_PROT_MASK ioctl command to restrict--never add--the > permissions that the buffer can be mapped with. > > Processes can remove the ability to map ashmem buffers as executable to > ensure that those buffers cannot be exploited to run unintended code. > We are currently trying to replace ashmem with memfd. However, memfd > does not have a provision to permanently remove the ability to map a > buffer as executable. Although, this should be something that can be > achieved via a new file seal. > > There are known usecases (e.g. CursorWindow [2]) where a process > maps a buffer with read/write permissions before restricting the buffer > to being mapped as read-only for future mappings. > > The resulting VMA from the writable mapping has VM_MAYEXEC set, meaning > that mprotect() can change the mapping to be executable. Therefore, > implementing the seal similar to F_SEAL_WRITE would not be appropriate, > since it would not work with the CursorWindow usecase. This is because > the CursorWindow process restricts the mapping permissions to read-only > after the writable mapping is created. So, adding a file seal for > executable mappings that operates like F_SEAL_WRITE would fail. > > Therefore, add support for F_SEAL_FUTURE_EXEC, which is handled > similarly to F_SEAL_FUTURE_WRITE. This ensures that CursorWindow can > continue to create a writable mapping initially, and then restrict the > permissions on the buffer to be mappable as read-only by using both > F_SEAL_FUTURE_WRITE and F_SEAL_FUTURE_EXEC. After the seal is > applied, any calls to mmap() with PROT_EXEC will fail. > > [1] https://cs.android.com/android/kernel/superproject/+/common-android-m= ainline:common/drivers/staging/android/ashmem.c > [2] https://developer.android.com/reference/android/database/CursorWindow > > Cc: Suren Baghdasaryan > Cc: Kalesh Singh > Cc: John Stultz > Signed-off-by: Isaac J. Manjarres > --- > include/linux/mm.h | 5 +++++ > include/uapi/linux/fcntl.h | 1 + > mm/memfd.c | 1 + > mm/mmap.c | 11 +++++++++++ > 4 files changed, 18 insertions(+) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 4eb8e62d5c67..40c03a491e45 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -4096,6 +4096,11 @@ static inline bool is_write_sealed(int seals) > return seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE); > } > > +static inline bool is_exec_sealed(int seals) > +{ > + return seals & F_SEAL_FUTURE_EXEC; > +} > + > /** > * is_readonly_sealed - Checks whether write-sealed but mapped read-only= , > * in which case writes should be disallowing movin= g > diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h > index 6e6907e63bfc..ef066e524777 100644 > --- a/include/uapi/linux/fcntl.h > +++ b/include/uapi/linux/fcntl.h > @@ -49,6 +49,7 @@ > #define F_SEAL_WRITE 0x0008 /* prevent writes */ > #define F_SEAL_FUTURE_WRITE 0x0010 /* prevent future writes while ma= pped */ > #define F_SEAL_EXEC 0x0020 /* prevent chmod modifying exec bits */ > +#define F_SEAL_FUTURE_EXEC 0x0040 /* prevent future executable mappi= ngs */ > /* (1U << 31) is reserved for signed error codes */ > > /* > diff --git a/mm/memfd.c b/mm/memfd.c > index 35a370d75c9a..77b49995a044 100644 > --- a/mm/memfd.c > +++ b/mm/memfd.c > @@ -184,6 +184,7 @@ unsigned int *memfd_file_seals_ptr(struct file *file) > } > > #define F_ALL_SEALS (F_SEAL_SEAL | \ > + F_SEAL_FUTURE_EXEC |\ > F_SEAL_EXEC | \ > F_SEAL_SHRINK | \ > F_SEAL_GROW | \ > diff --git a/mm/mmap.c b/mm/mmap.c > index b1b2a24ef82e..c7b96b057fda 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -375,6 +375,17 @@ unsigned long do_mmap(struct file *file, unsigned lo= ng addr, > if (!file_mmap_ok(file, inode, pgoff, len)) > return -EOVERFLOW; > > + if (is_exec_sealed(seals)) { > + /* No new executable mappings if the file is exec= sealed. */ > + if (prot & PROT_EXEC) > + return -EACCES; I think this should be -EPERM to be consistent with seal_check_write() and mmap(2) man page: " EPERM The operation was prevented by a file seal; see fcntl(2)." Thanks, Kalesh > + /* > + * Prevent an initially non-executable mapping fr= om > + * later becoming executable via mprotect(). > + */ > + vm_flags &=3D ~VM_MAYEXEC; > + } > + > flags_mask =3D LEGACY_MAP_MASK; > if (file->f_op->fop_flags & FOP_MMAP_SYNC) > flags_mask |=3D MAP_SYNC; > -- > 2.47.0.338.g60cca15819-goog >