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 E6EC2C7619A for ; Thu, 30 Mar 2023 21:46:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B4BA6B0071; Thu, 30 Mar 2023 17:46:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13B8B6B0072; Thu, 30 Mar 2023 17:46:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF7CE6B0074; Thu, 30 Mar 2023 17:46:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DAB4F6B0071 for ; Thu, 30 Mar 2023 17:46:23 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 943E7801CE for ; Thu, 30 Mar 2023 21:46:23 +0000 (UTC) X-FDA: 80626898646.28.6CD4184 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf18.hostedemail.com (Postfix) with ESMTP id BCD6F1C0016 for ; Thu, 30 Mar 2023 21:46:20 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BmQLZwf6; spf=pass (imf18.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680212780; 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=R1Jk475IjMY0JL30bXA6f3iBvRwQ5t0sLRQAyTvVik8=; b=E8MP+83WAWoxtyL6hDU2J7hber7kpCeFCXhN4fxgppfUNecY7UGs5Az/wJwjvglaSGjFEg qjI5Kr/kTPrz44oRSece/ATAI7xxH94dODHX5PhDmLDpKi+h2OFAVlTwF/92kNIAI/ORhf Zn1TzyQBShc2bnp1NKFKZn7A3zs0lIs= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BmQLZwf6; spf=pass (imf18.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680212780; a=rsa-sha256; cv=none; b=RzBwYkG3d4fS78SdtLsZ8aCXSf5Ij5Vq96ZweLq1JFR8jpBunR6cRBb0C7laRAG6nP58DY AX72+sw/lsAFzEsXi0UASVnzf5FGK0/A96oTMV6CWidkETdbMgSrzP82FA1vQfhihAGDYV 4/OVYzLTxs6/NNcqTtQ+r0LNczhw5js= Received: by mail-wr1-f53.google.com with SMTP id l12so20466758wrm.10 for ; Thu, 30 Mar 2023 14:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680212779; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=R1Jk475IjMY0JL30bXA6f3iBvRwQ5t0sLRQAyTvVik8=; b=BmQLZwf6IbC1biHjC82BGqLpvFBu6wO4D1/4gwwS3PqfG8DJGtLQTB82jCAD5LpZun 8qRcUl2b4EvCll8Bbnnz6YPC+jLdeyfDGMY0rIdYI/nMptecjZ4aBMEc/kMaYFvSBS5Y f/qHgSRW0Ent6n32UKctzOKK91yNJv7xmPnxgxLv1qRTrCnKM1EhEo+6V1LRpfCJxoYz g4fghyd3qN3Ium5tq3iYGnqeyEsjvg6RWipQu+TxqYGQtLllGmH38S3pfduuTnX/VK2z WYhlv5IeWE3Xzags7Xqr4vrpUvuknPYXP5TsTaC/YQana2op6ECXkI+pUBRBdCxszTkV mEsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680212779; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=R1Jk475IjMY0JL30bXA6f3iBvRwQ5t0sLRQAyTvVik8=; b=IJ4W2mwmDkc9vax3RPn9tTE0E0GQmAnahSlPB5NRTA7tMKRbVkSSKCVthc4SYsatgy MgS/HJNkPWcSJqc02KNt+yBGcZaKfo/WqxatwP9ey7A6hKBNc87Bn1lQ8onlHKiePJFU BGZbAdTKhindykuqc8gzaaV6JwBk9OSi5Pk8NAhUa9rOVyoyicRuddlqYtHdBOEDnl10 vB4Pl7veL1rbsyo0rUIel5ve/91vHBTPE/CingERy+LMBNdRO3q5xw3WfM7vyIxIL3dV iqNQjo/PrkSPOM7PZweaSPEEhuAQ4eCo4K9VsoIay7ElhTD2EeJBqFnwEdj+v3qhlaQv n7vQ== X-Gm-Message-State: AAQBX9cdn8aeNCfxb9MM/B116ZkNmICyHN77zIPAKamEekukTfN2flVR 19Mgvn7KBuH4IGivo+orupM= X-Google-Smtp-Source: AKy350YaRFFB3xxobFlglKBbgiRZZuknlk/LsyEySw9oyQtlo2TmQXta8yEb+TxeI9sURd5551b/kw== X-Received: by 2002:a5d:4406:0:b0:2e5:26eb:bd1b with SMTP id z6-20020a5d4406000000b002e526ebbd1bmr1849193wrq.58.1680212778974; Thu, 30 Mar 2023 14:46:18 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:fdcf:52c5:7af:c812]) by smtp.gmail.com with ESMTPSA id y13-20020adff14d000000b002c55306f6edsm414676wro.54.2023.03.30.14.46.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 14:46:17 -0700 (PDT) Date: Thu, 30 Mar 2023 22:46:17 +0100 From: Lorenzo Stoakes To: Andy Lutomirski Cc: Andrew Morton , linux-mm@kvack.org, David Herrmann , yshuiv7@gmail.com, bugzilla-daemon@kernel.org, linux-api@vger.kernel.org, linux-man@vger.kernel.org, Michael Kerrisk , Andy Lutomirski Subject: Re: [Bug 217238] New: Creating shared read-only map is denied after add write seal to a memfd Message-ID: References: <6793EAB9-CF91-425A-B278-8A5D4415AD72@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6793EAB9-CF91-425A-B278-8A5D4415AD72@amacapital.net> X-Stat-Signature: 8oiiey9g97tsjo3mxeby65ez5oi6ztxs X-Rspam-User: X-Rspamd-Queue-Id: BCD6F1C0016 X-Rspamd-Server: rspam06 X-HE-Tag: 1680212780-619889 X-HE-Meta: U2FsdGVkX19W1vCDWqGQsQ3DvpKKYT3BcVOhtxrNphN2GtDlgg/T7XPzaNWF8VeFextVkFhX5zhlDBWTWz9+14oF5ZWMQg0D5ERdr4Gv5ykNu7CroKIYIPOvHl4KD1RYVJpKRcxxkKNw1ofxptDLu8kUvKQxonfzFc5z1fHyG016JLkLIo+le/RPBYFeLZ0opqJG40wFCUcpshhH5kMBtJH72+2Yr+y6GRa3I11lPIPwnNphEE50iEc3sdaPE1CRzp37Lmf/KS7eoB1FUaP3eiuvk3u6gFpsrgMpaOs98DOMenLXt5kzjRRvdAKc6J2yXL3yfmCsOZx4mJPg9vJeD36Jf/XJ6ABeGTJn7iLbnwnvN30Yis57SyPKDZIQjXZJnJlhzhlA60j8g1FjbfM/LguFubt1NlzivaRN/FxkG/RnshggqPWX3IOEYyEMyP9HuTK6qyIOE7IpCoYrAxBptkbpRGIImSitCPE37j77L4g+3acPqAAgcFW+Ddy/aGSG/u4dv97UrQ2rNUfMOETHBsDHGnsbkgAWNb4cnBxdSJxtq3OtIiszpQ6vgJR1q+jC8IqpxCutoDE76Bcnw8/ALVQP081T4kTdkq/xcZYbKYhi442tlb64i3t84JXawGEjZ5PFT5NmJu9lNea8P1xUP0bsZG24kAzQGP15/vHJCXgPf7Vkn9dYc8xD6thxuI6H3aSDMZWUWdq0gZxzKoEbzKY6l3qX8GgNrjwSxuFZnID8d57cIZwB/WxhDB6Krc5n866a3gxGBFC4BR6ceZwXKBNbMdDDrIkCewmrCGM/u5le3paC/J4VtwpDENbLe35nPZkfniCHYlaxob37KgVMBwnY07W6nwMkmtcKVI/x7x1IOZQ4Jmk+Y5S2JUoT1fU8Gt6axcpyLsCPjVC4f8zhDU4wN6t3f4fMwXNKx8Hv3pbgPh1ReBeuW9SveaBkKFwndAQBpmd8KXcW6CeVjf5 +BJAuLi8 Npf+x+k2dz0EOBQUnBU01tSoxxjNXfePP1IRdj016Snm1fsfs8vQd+H6TcpVBrJL/twSsKcPE/FrUdHSOM2FLS2rkYVXdXRUjzKZBXZQzx5JvPX0LGbc3kx1awZtCSpEW//ddeFY1L2925SpjnTINkhRogaGYLRxlccz8dBjvbKY4G9aDg77NyAfuMz1MYIGvteiZsRzh/1SbQS/5YXRm4lEaDjiKtzif3NwBIRGF38I4tAxPoCSmorMKejhf5eT+w/27HWT4PtqZSQR6n6CZnMMJSedSn94cdoHKNA6LOvwKewCVEERyc0Mr7OPJ+SJw0tse3DTlO4k33o8iqKB1E9NgEj05ABOYxMZwVEYxp8RSVsI/3HAgbRuGpdNC4IPjgo5AE+VcBgBQW26YkMZYJGmuQNj2K3sGUh6xAMYVAisl9d9jvqLj7ADgt+lsXMqsgvAXjz/o3U0Qjjtppxrr7qrmudmim/leUHmexRBayvWf02Ttdy6WUr3bq3pwniZ2kV4ii9vENOoaVuAp5JJhLWHOrbiCT3iHg294RLbrbIFytMj5oO15ZvPIqzxRXr0p3JmaqsWZzWnD84zkWwSo+sLKIHbpXmYKJ6DIpJdLe9C1z60ZUM0cxAR3ePpcQzrn1cErzx6fSFcRm0efMKXkqKliElTj1ONGM8rF 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: On Thu, Mar 30, 2023 at 01:47:48PM -0700, Andy Lutomirski wrote: > > > > On Mar 30, 2023, at 12:25 PM, Lorenzo Stoakes wrote: > > > > On Sat, Mar 25, 2023 at 02:51:05PM +0000, Lorenzo Stoakes wrote: > >>> On Fri, Mar 24, 2023 at 01:36:46PM -0700, Andrew Morton wrote: > >>> (switched to email. Please respond via emailed reply-to-all, not via the > >>> bugzilla web interface). > >>> > >>>> On Fri, 24 Mar 2023 03:34:23 +0000 bugzilla-daemon@kernel.org wrote: > >>> > >>>> https://bugzilla.kernel.org/show_bug.cgi?id=217238 > >>>> > >>>> Bug ID: 217238 > >>>> Summary: Creating shared read-only map is denied after add > >>>> write seal to a memfd > >>>> Product: Memory Management > >>>> Version: 2.5 > >>>> Kernel Version: 6.2.8 > >>>> Hardware: All > >>>> OS: Linux > >>>> Tree: Mainline > >>>> Status: NEW > >>>> Severity: normal > >>>> Priority: P1 > >>>> Component: Other > >>>> Assignee: akpm@linux-foundation.org > >>>> Reporter: yshuiv7@gmail.com > >>>> Regression: No > >>>> > >>>> Test case: > >>>> > >>>> int main() { > >>>> int fd = memfd_create("test", MFD_ALLOW_SEALING); > >>>> write(fd, "test", 4); > >>>> fcntl(fd, F_ADD_SEALS, F_SEAL_WRITE); > >>>> > >>>> void *ret = mmap(NULL, 4, PROT_READ, MAP_SHARED, fd, 0); > >>>> } > >>>> > >>>> This fails with EPERM. This is in contradiction with what's described in the > >>>> documentation of F_SEAL_WRITE. > >>>> > >>>> -- > >>>> You may reply to this email to add a comment. > >>>> > >>>> You are receiving this mail because: > >>>> You are the assignee for the bug. > >>> > >> > >> This issue seems to be the result of the use of the memfd's shmem region's > >> page cache object (struct address_space)'s i_mmap_writable field to denote > >> whether it is write-sealed. > >> > >> The kernel assumes that a VM_SHARED mapping might become writable at any > >> time via mprotect(), therefore treats VM_SHARED mappings as if they were > >> writable as far as i_mmap_writable is concerned (this field's primary use > >> is to determine whether, for architectures that require it, flushing must > >> occur if this is set to avoid aliasing, see filemap_read() for example). > >> > >> In theory we could convert all such checks to VM_SHARED | VM_WRITE > >> (importantly including on fork) and then update mprotect() to check > >> mapping_map_writable() if a user tries to make unwritable memory > >> writable. > >> > > Unless I’m missing something, we have VM_MAYWRITE for almost exactly this purpose. Can’t we just make a shared mapping with both of these bits clear? > That's a good point, and there's definitely quite a few places where VM_SHARED is simply taken to imply writable which is a little irksome, however sprinkling some VM_MAYWRITE checks in these places would resolve that. Let me take a look into this and perhaps spin up a RFC to iron out the details if this is indeed viable. > >> I suspect however there are reasons relating to locking that make it > >> unreasonable to try to do this, but I may be mistaken (others might have > >> some insight on this). I also see some complexity around this in the > >> security checks on marking shared writable mappings executable (e.g. in > >> mmap_violation_check()). > >> > >> In any case, it doesn't really make much sense to have a write-sealed > >> shared mapping, since you're essentially saying 'nothing _at all_ can write > >> to this' so it may as well be private. The semantics are unfortunate here, > >> the memory will still be shared read-only by MAP_PRIVATE mappings. > >> > >> A better choice here might be F_SEAL_FUTURE_WRITE (available from kernel > >>> =5.1) which does permit shared read-only mappings as this is explicitly > >> checked for in seal_check_future_write() invoked from shmem_mmap(). > >> > >> Regardless, I think the conclusion is that this is not a bug, but rather > >> that the documentation needs to be updated. > >> > > > > Adding docs people to cc list (sorry didn't think to do this in first > > reply).