From patchwork Sat Jan 12 20:38:15 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Fernandes X-Patchwork-Id: 10761083 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1ED301390 for ; Sat, 12 Jan 2019 20:38:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0E25028FD4 for ; Sat, 12 Jan 2019 20:38:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F0F432902F; Sat, 12 Jan 2019 20:38:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4F04729038 for ; Sat, 12 Jan 2019 20:38:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A92B8E0004; Sat, 12 Jan 2019 15:38:35 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 335F68E0002; Sat, 12 Jan 2019 15:38:35 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FBD78E0004; Sat, 12 Jan 2019 15:38:35 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by kanga.kvack.org (Postfix) with ESMTP id E6C618E0002 for ; Sat, 12 Jan 2019 15:38:34 -0500 (EST) Received: by mail-qt1-f198.google.com with SMTP id f2so20533857qtg.14 for ; Sat, 12 Jan 2019 12:38:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:from:to:cc:subject:date :message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=X59k2XX1UnzlfYoU2KHwT+sySFqpz7PmWxdvLhBDFIE=; b=seuAV9QB5FAO3OHQ80hzuoQMCOyFKfGAf+jDFOfno98ti6M+T9vadjK5spul4QLc9I jhAnjnX4Lmhx1wDvwgpoRI999xXyHC/zM4NuA5OWP9uHvrwKvexOElHZKiBkuTfOugcN Tx79CpgecVZZy+XpDKokmqsvUi44sv/vdIjgXBenW1g3QWKJVbYkbfVxOrWI3qoHedJA XBepo0/cEPYWHq0grGPVyDwYpjZgm/4uM3yrk32x+1gWWQDtMy1iHlgIbxcAZg3Rz/Sa Xcu1ELu304QAHHAdGKx8VhqRx6qrAmK0VC/E1K9m92VeQbbZNOmUt3P0wvVA6sSXFHBL R4+A== X-Gm-Message-State: AJcUukfQpj9jxsYBpNT3VraKHgWxHVizFZh3OBe5dwi1Y6xRgRHWsHup qbit5f9TEK1v70HcykgPdTQLBM06euD3f6fSZk0NrYwWHWEO4gPiXYevyppGWKDyYFtqecE5iWP dnqb8Ax9i6hHgr6qBi3SMhfkXdZcN/ax1PQXjzqpmzrB7ApkGZD840jNhaChRhY1dxi+Lus7hVf K3LeKKGY1tjRa58gXPA5/VCJOUOnTGYkP3/+/oFzxNXlR4ifgXTUePk9Q1FxLAfwywKMRUGSu1/ U6XGQ0xOLMt8jQLGUn6TMh1RQ/ko+JYNOvCk926/Pk5RrjITysStDMF1nsz22NyzllpBUKso9g/ MuQehs59TNw9y8GDcJOdID/7nLvl1Chdab0Ea21fpC0fSdmcJTqQRgTvbdbpXVegxVHCLCj/zOx y X-Received: by 2002:a37:4eca:: with SMTP id c193mr17502429qkb.37.1547325514614; Sat, 12 Jan 2019 12:38:34 -0800 (PST) X-Received: by 2002:a37:4eca:: with SMTP id c193mr17502408qkb.37.1547325513774; Sat, 12 Jan 2019 12:38:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547325513; cv=none; d=google.com; s=arc-20160816; b=fOVs3KlZ6uvIS7ozok6xqz0cNUtK1hk8ZtX9WzMS7s3OVHibj16umvzjw4XpVII8Sp MFmy6e1eO/20pNcvKOx3P59Uq0ruYhUmtA+nyOnuPO1en8cNDUVQn1HR1LMU2ZTEf/UJ yG8umo9z8myTuPsjEmUcvcOZBIa01KCxhZ2/bLoKopiNJ6OSHx2TKb0EZI6SZ4mnNdNj yAnnr2squWoa6lnYJ63S+r6qUl2Lq1h8YT1Zeff78zXtGkWeVvTyRudou2AnqPKcEUzj 6lVg1YY82kJ+7LusnrEoxJIICOCRgJMz/obuas3/bpiENguIzXpFrdIcpLqmuy9e1uF/ XDGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature; bh=X59k2XX1UnzlfYoU2KHwT+sySFqpz7PmWxdvLhBDFIE=; b=FjNtvdpB1kRP1VG9Mxbch30Hb1S01vlaRUvuSwIKVZ+1ZUzyj/jE38CT59hjG11/nU rMW9BDsTHwH3clqGwQ8f7E7tgz1V5gL/28NzKCLRoe5XE0sJs0r61o6eJrGNm8jc3485 1OnqZYpCZbtFfMAnn4ETm3nN7ZAmuolRP/0PBaOmTShdUI0M+75syNeWqVqXeCPD9yqm GbqngGgC+DmKPtct2ZLhx+Y09hAIpr3xazyHQZTHPWWfDku83cUf/mmWQkxxAdPKK9A5 YMjfurd8wTDr8B74ixicbmICMSNeTN0+wh48m0+xY9m8pRQh7Ehna6VuiS91Kr86v2ZF JzlA== 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: domain of joel@joelfernandes.org designates 209.85.220.65 as permitted sender) smtp.mailfrom=joel@joelfernandes.org Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id j137sor26181973qke.70.2019.01.12.12.38.33 for (Google Transport Security); Sat, 12 Jan 2019 12:38:33 -0800 (PST) Received-SPF: pass (google.com: domain of joel@joelfernandes.org designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="ruN/Yr6i"; spf=pass (google.com: domain of joel@joelfernandes.org designates 209.85.220.65 as permitted sender) smtp.mailfrom=joel@joelfernandes.org 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-Smtp-Source: ALg8bN4jPXax4laIu1WzosZcAcZeXZ4Wm0QM14TQ9ICZoH3TjNgWJlkhwwFbm54ECOfxBEXe5f2MBw== 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_Lureau?= , 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 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: X-Virus-Scanned: ClamAV using ClamSMTP 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) Acked-by: John Stultz --- 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; }