Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2033315imu; Sat, 12 Jan 2019 13:35:59 -0800 (PST) X-Google-Smtp-Source: ALg8bN5zDrWvYDs+F2aJ9DY2moVGPB9Vfy0INw70mkjeY0VnmNf0IrPpIl2aqd03xd1QMQhPQPtu X-Received: by 2002:a17:902:50e3:: with SMTP id c32mr20019911plj.318.1547328959834; Sat, 12 Jan 2019 13:35:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547328959; cv=none; d=google.com; s=arc-20160816; b=z0g7xSpFdV9AFbZF/EC+UkhInjIQvx3N1z/njbCAA3MTlWpem1WNMLxPfTalt7HhTi FMjIVOfMJcUrjCWYqBzwhyINODv7LqqvaL8Y71PmHq91E43A8epc3DjpPgeXdt1Wx7em RhW4yoFbvPqkueSxAbRag2hHc1Q/YhnWgOIdN7CcPr2bKARh7L3pGTHgaLFUsmoG4U3G 5gMAwiMScOVyByRl3aYpN3SARCpD5s6DpEwjb0xY4HbNcb8lqeVhge669JFAVFY5cbzq BDEKi6ygQsOs5cnz7VHLePs8djS6fcfzNKliWwZ477VLK1LI9DUS/XbMjtzaSpNBPYMg FVgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=X59k2XX1UnzlfYoU2KHwT+sySFqpz7PmWxdvLhBDFIE=; b=ligAyg9PUBy2kWa9375pVV34rucl+JyK3zJW/zSmpt4zY8+eL/VHJKXj1IdOkVbNK+ Vf7AIauQ9KucVhDr83TFWGdfbIVxVgR6ObhDzRkZR8KJnXQuLNyNI8LktMEs1jOz6eAo 7RzB+yxSgJ2suU99oZOoo6aiSQs7G2v7eURPFJp9R3GDVT6GoYFrt4r6Fh3DCUMWUI7I PCLV4TgMX7OOs9I39KlgueH0kDOCbp8hLJvn6LLVdgwEuVNsuT5BN23FvxfJH86/8XnE IhHoiJC4KJLHb0QJJRNlawbSeZ1JVMXG7+N98iiVwyL0o5xffNQfuyA/E/GW1xp4LOmN gcwA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="ruN/Yr6i"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d8si54079404pgl.386.2019.01.12.13.35.42; Sat, 12 Jan 2019 13:35:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="ruN/Yr6i"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726631AbfALUig (ORCPT + 99 others); Sat, 12 Jan 2019 15:38:36 -0500 Received: from mail-qk1-f195.google.com ([209.85.222.195]:34754 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726608AbfALUif (ORCPT ); Sat, 12 Jan 2019 15:38:35 -0500 Received: by mail-qk1-f195.google.com with SMTP id q8so8552679qke.1 for ; Sat, 12 Jan 2019 12:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=X59k2XX1UnzlfYoU2KHwT+sySFqpz7PmWxdvLhBDFIE=; b=ruN/Yr6iLpU/LNFmr4FNMG9riPkTRrZHcofPj6AkffmGHzLg9yGAMCyuqktfSalvjd VRygPhSJxT9EpoW1T2JkFtTddrI0H/nzgec4VrfLTtcwjUT/b4L3Tgzypq6BnZc+WxT6 hiXZQDCyvYvpxPkkkgCk02n19Nd0s1Ozqbqw8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=X59k2XX1UnzlfYoU2KHwT+sySFqpz7PmWxdvLhBDFIE=; b=Kp5wsJcj5gaetYakhVV3Lm6DTZccWWH/XqYlsoiMSrxpAdpHXnKo0Qoql/GuwJdPrL XcCmioutFh+e+wN1Am0/+im5zaHUu+Y7iQBXwrWN1wkUThcTMAShbXtyyw/jFhH0iLUp f+KEMG4jKfMjLyypKQx6KwuFfOMKF5AtMQJ/VjVROVv8jnQ5/0ybBn8D7rWczsKqf5tf eSI6vMbgtv2cYwho9qRtVTEfE1wdENhGn1tilwNcOV46JTLuFx9+vQuZz4dcn5OCruqU aXoZ6NYTPIJh9bUPiFSiAfh4ksILVQDG3dEruuwGDrHzy2ewxlmQ6ywAqU2b0ZNv/k8U NFLg== X-Gm-Message-State: AJcUukemyLnsEyTq2hMHzhDA8BvbeNNVO4nJZThQhmcBlA+YYf80XC++ u+Nl7odb1+rpG98EfrbEWd9Uz56mdfE= X-Received: by 2002:a37:9906:: with SMTP id b6mr17565376qke.208.1547325513368; Sat, 12 Jan 2019 12:38:33 -0800 (PST) Received: from joelaf.cam.corp.google.com ([2620:0:1004:1100:cfd0:d2ee:d54d:ab6d]) by smtp.gmail.com with ESMTPSA id c12sm55883402qka.42.2019.01.12.12.38.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Jan 2019 12:38:32 -0800 (PST) From: Joel Fernandes To: linux-kernel@vger.kernel.org Cc: "Joel Fernandes (Google)" , Andy Lutomirski , Al Viro , Andrew Morton , dancol@google.com, Hugh Dickins , Jann Horn , "J. Bruce Fields" , Jeff Layton , John Stultz , linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , Matthew Wilcox , Mike Kravetz , minchan@kernel.org, Shuah Khan Subject: [PATCH v4 1/2] mm/memfd: Add an F_SEAL_FUTURE_WRITE seal to memfd Date: Sat, 12 Jan 2019 15:38:15 -0500 Message-Id: <20190112203816.85534-2-joel@joelfernandes.org> X-Mailer: git-send-email 2.20.1.97.g81188d93c3-goog In-Reply-To: <20190112203816.85534-1-joel@joelfernandes.org> References: <20190112203816.85534-1-joel@joelfernandes.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Joel Fernandes (Google)" Android uses ashmem for sharing memory regions. We are looking forward to migrating all usecases of ashmem to memfd so that we can possibly remove the ashmem driver in the future from staging while also benefiting from using memfd and contributing to it. Note staging drivers are also not ABI and generally can be removed at anytime. One of the main usecases Android has is the ability to create a region and mmap it as writeable, then add protection against making any "future" writes while keeping the existing already mmap'ed writeable-region active. This allows us to implement a usecase where receivers of the shared memory buffer can get a read-only view, while the sender continues to write to the buffer. See CursorWindow documentation in Android for more details: https://developer.android.com/reference/android/database/CursorWindow This usecase cannot be implemented with the existing F_SEAL_WRITE seal. To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal which prevents any future mmap and write syscalls from succeeding while keeping the existing mmap active. A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week where we don't need to modify core VFS structures to get the same behavior of the seal. This solves several side-effects pointed by Andy. self-tests are provided in later patch to verify the expected semantics. [1] https://lore.kernel.org/lkml/20181111173650.GA256781@google.com/ [Thanks a lot to Andy for suggestions to improve code] Cc: Andy Lutomirski Signed-off-by: Joel Fernandes (Google) --- fs/hugetlbfs/inode.c | 2 +- include/uapi/linux/fcntl.h | 1 + mm/memfd.c | 3 ++- mm/shmem.c | 25 ++++++++++++++++++++++--- 4 files changed, 26 insertions(+), 5 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 53ea3cef526e..3daf471bbd92 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -557,7 +557,7 @@ static long hugetlbfs_punch_hole(struct inode *inode, loff_t offset, loff_t len) inode_lock(inode); /* protected by i_mutex */ - if (info->seals & F_SEAL_WRITE) { + if (info->seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE)) { inode_unlock(inode); return -EPERM; } diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h index 6448cdd9a350..a2f8658f1c55 100644 --- a/include/uapi/linux/fcntl.h +++ b/include/uapi/linux/fcntl.h @@ -41,6 +41,7 @@ #define F_SEAL_SHRINK 0x0002 /* prevent file from shrinking */ #define F_SEAL_GROW 0x0004 /* prevent file from growing */ #define F_SEAL_WRITE 0x0008 /* prevent writes */ +#define F_SEAL_FUTURE_WRITE 0x0010 /* prevent future writes while mapped */ /* (1U << 31) is reserved for signed error codes */ /* diff --git a/mm/memfd.c b/mm/memfd.c index 97264c79d2cd..650e65a46b9c 100644 --- a/mm/memfd.c +++ b/mm/memfd.c @@ -131,7 +131,8 @@ static unsigned int *memfd_file_seals_ptr(struct file *file) #define F_ALL_SEALS (F_SEAL_SEAL | \ F_SEAL_SHRINK | \ F_SEAL_GROW | \ - F_SEAL_WRITE) + F_SEAL_WRITE | \ + F_SEAL_FUTURE_WRITE) static int memfd_add_seals(struct file *file, unsigned int seals) { diff --git a/mm/shmem.c b/mm/shmem.c index 6ece1e2fe76e..3c98cc9655b4 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2125,6 +2125,24 @@ int shmem_lock(struct file *file, int lock, struct user_struct *user) static int shmem_mmap(struct file *file, struct vm_area_struct *vma) { + struct shmem_inode_info *info = SHMEM_I(file_inode(file)); + + if (info->seals & F_SEAL_FUTURE_WRITE) { + /* + * New PROT_WRITE and MAP_SHARED mmaps are not allowed when + * "future write" seal active. + */ + if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) + return -EPERM; + + /* + * Since the F_SEAL_FUTURE_WRITE seals allow for a MAP_SHARED + * read-only mapping, take care to not allow mprotect to revert + * protections. + */ + vma->vm_flags &= ~(VM_MAYWRITE); + } + file_accessed(file); vma->vm_ops = &shmem_vm_ops; if (IS_ENABLED(CONFIG_TRANSPARENT_HUGE_PAGECACHE) && @@ -2375,8 +2393,9 @@ shmem_write_begin(struct file *file, struct address_space *mapping, pgoff_t index = pos >> PAGE_SHIFT; /* i_mutex is held by caller */ - if (unlikely(info->seals & (F_SEAL_WRITE | F_SEAL_GROW))) { - if (info->seals & F_SEAL_WRITE) + if (unlikely(info->seals & (F_SEAL_GROW | + F_SEAL_WRITE | F_SEAL_FUTURE_WRITE))) { + if (info->seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE)) return -EPERM; if ((info->seals & F_SEAL_GROW) && pos + len > inode->i_size) return -EPERM; @@ -2639,7 +2658,7 @@ static long shmem_fallocate(struct file *file, int mode, loff_t offset, DECLARE_WAIT_QUEUE_HEAD_ONSTACK(shmem_falloc_waitq); /* protected by i_mutex */ - if (info->seals & F_SEAL_WRITE) { + if (info->seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE)) { error = -EPERM; goto out; } -- 2.20.1.97.g81188d93c3-goog