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 79670C761A6 for ; Thu, 30 Mar 2023 19:24:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 137436B0072; Thu, 30 Mar 2023 15:24:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E8646B0074; Thu, 30 Mar 2023 15:24:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECA5D6B0078; Thu, 30 Mar 2023 15:24:43 -0400 (EDT) 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 E0B916B0072 for ; Thu, 30 Mar 2023 15:24:43 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A580DC102D for ; Thu, 30 Mar 2023 19:24:43 +0000 (UTC) X-FDA: 80626541646.26.AB53AB5 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by imf22.hostedemail.com (Postfix) with ESMTP id D64EFC000F for ; Thu, 30 Mar 2023 19:24:40 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=LJbVReQD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680204280; 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=/1WlejRA6jsZvIXqlLPw6YewfrLV5VAAUmFxpGwdQNk=; b=1++1jCA+0Qju09eB9xLGidZzfoZPNS87LqWE3pYwmQwlZK1yrqhGJUYcybcP2wpAMpxCwt yGk4SS7lgZK+iO5/nzA8b2SUJQhCB2Kb1g7i0jaxHxJWKy7i60Bs8wP/J5MQEJEZjEhkYe 4ev9jp7LFMWpJLRX1M7IVhn/TWWvQOk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=LJbVReQD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680204280; a=rsa-sha256; cv=none; b=ilusC3ZNU/CkqqDiCWi8MgDwCpmEzRYl7737LU06t9e5N5qLX/WSo/j9DIcYdRG5OUIS8r dS9tqba7j/v1sAH+cxuO+P3+ZK9XnvzVSHgIabmdrQ2HteDwxIJzrEjSFhNclZK89T6fN8 WJ8muCXGXBn7Pdmz7jtpDAvRKqV7/jI= Received: by mail-wm1-f46.google.com with SMTP id o24-20020a05600c511800b003ef59905f26so12471780wms.2 for ; Thu, 30 Mar 2023 12:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680204279; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/1WlejRA6jsZvIXqlLPw6YewfrLV5VAAUmFxpGwdQNk=; b=LJbVReQD8HGM3QrEFQQ5VCz/AkFqTXkKWgL8agFSV/iJZgYBGMH1FKuksBvi39PXVB mh9i9S4bpgjKbQvTVpI2WDYr/0RFCe0QoLwCrPJ7Bba8EoPceQjt0vD7AbTH8jN1PWPJ iAzorEsCIGhMxJVV2zKGtpevRbkQAhKcIc9Ti6lSDPy0LDgqBlWmyMpBwmUcq1ggVA9i +5qAKDnpCCR71S06LNiMVfjWJcT+6WiVkY2SJYNwQ4hlEfYLw+VdqwLtxJuYrohRPaCq k2Z0O79g/diES7IbSbs9Wjl5dKqXG3SRl20NZQsEUkJQxrMJQMw3bdcYO+qU3YkNpfdN 2bEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680204279; h=in-reply-to: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=/1WlejRA6jsZvIXqlLPw6YewfrLV5VAAUmFxpGwdQNk=; b=UWoSStnoWNr9apKN6NFUBfyN2e/6zzykULJ7KViHeXmnkS8ENzBxWzUQiyN97W7omd anw553ocveNORLWHy0OxO1qmDwZziTTBtfMNVMmsbDVAeArBHlwiLSmOrcGMUjyxFiYW 9CyNmDWCVcHPcrvmy3fIGSnT2JWLrk0JZ4016ZuLVN3yMfwevjwAh8jl23UzxqNTwuk5 RSeiwg9v0lvxCCg21X0CIaUZHsbPoVEPkWpmGjrdHXOUrf5F3mcu3sFqC/IN88UHCx// 6ju0QXGhzQCDxg6Tq2vjK8naJ2b2cRkWQvWpDPfhYskMEST7G8UOYLQVY2b47niFEWTl vhMg== X-Gm-Message-State: AAQBX9cBxJEHSjWpOQGfbEGd3TzuzHMtRb/FQ8o89kjUZiFH4yMiGzbD xh/0f9BVLC6g2pVxrIM27Kc= X-Google-Smtp-Source: AKy350ag6yicidw5Yqy4p4poF1fhXqv2CT8CIaqa/0L+jQkTuHCIVxVRgX+pNkS6Ca+T0miznHIc6A== X-Received: by 2002:a7b:c7cb:0:b0:3ed:5d41:f998 with SMTP id z11-20020a7bc7cb000000b003ed5d41f998mr5624923wmk.15.1680204279109; Thu, 30 Mar 2023 12:24:39 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id i22-20020a05600c355600b003ede6540190sm7495043wmq.0.2023.03.30.12.24.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 12:24:38 -0700 (PDT) Date: Thu, 30 Mar 2023 20:24:37 +0100 From: Lorenzo Stoakes To: Andrew Morton Cc: 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 Subject: Re: [Bug 217238] New: Creating shared read-only map is denied after add write seal to a memfd Message-ID: References: <20230324133646.16101dfa666f253c4715d965@linux-foundation.org> <45e081de-47a9-49e1-8420-51979dad40f5@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45e081de-47a9-49e1-8420-51979dad40f5@lucifer.local> X-Rspamd-Queue-Id: D64EFC000F X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: bpqru1td6g55c9trninsoumday8ks7py X-HE-Tag: 1680204280-967374 X-HE-Meta: U2FsdGVkX18gaacfMiI+GJQaWJ6SkrCo1Dl593wDv6SxrqoDKW7SY2JYaST+tjvv1fLxS2plN1/w4Tdj8ufzi2jtBI+9fif/4Ytdb01MkEDMn34bsi2d2mCX5leF8UJc8uNXd9YArmlSLxAnM/Vzi5TkKqEZTUE2Qe0SOpE1wCJn2oYW4EgxpQBlr9Y1KzlwWpDuCOzUgmAqezcf51E6lTTeB2pGIyIO55sgUOFPHPbo34EDrn8L7fYot2QtbuzLhgFYAC8MyLVsuLjihb9JaMTHe7W8uUyGk5lxehR6fM+3TdJEy4imWJi+Y//InXhoJid7k865Y0lNtWcxXMD9gq4zryf7klcwP2J79pyRWH7kh5zIXJqQCbSWu07lNZfI1nbizFcZASf+qveKcdBkPmPwSCuGBqBC4c584Iicagv27sQt+i6biQ4xyD1mclBSyps3LtytF7J2ndYONYta5oA04q4rZfL259ei+KpZONgjmT3SWixonMHLmf7KxuLAZK46cY8tGGPyW0wa274WkEBvxpXS2Vw3M/bwER+1YSMRsgFhG4Xx7+Zij340wmTTjby6RlWMoxNq0jbkhyK1bXEzIyJYAo73QNhIP+QCRY4snCtzd1uqQ1m1rrXk5cW5RxvW/1lZHA5DVuaJ4nscjGrkNg/DIpD8Gevfdazw2sAPhKL0tcAjllcTM3aDDPTW2x30lw2ozS6msMkdTcDE0moVEXDeWlUMsh7osK7V5uKYhkKGrfzaOhzmkHZqr+xVdChzxTyYwkFFWgx2xwgkXda6t3gJGvYMEBOSr+EqDmkSgx0LTXW7EvJjf6fPYX0acaFrmd06vdjAT9amH0dBleQWr3oyMNJ3bAXUDrEDAIIiJJPxnloxWNHBsNWtu5BH+lCam3zeJ8rC6tA7oj9J6UFgcIPPC5C0oZaNXW6s0vO/C3KdqQlWFXonGovTwTk6ihakvwYCr0XCFD8oZtm Lw1ZjXJV KWJlO6wvKLJ4+TWs0CAKj6a+gojCrOnfbZMNE4vP+wjzYk1PgF/vUr2Ar7A0e6FFLK2tc7354+bdt5h+L7jIBogofM1qh6YwhMCNZUPNx+VrZ4juH5nyuTHVGAKXPb1tj2FJxtE+i80TVuivPWDowpQnEeSWrYyiR/m/qmIWOKdyfAboPx2Z5OaO/kWTPtqUFvFkmtIsDutAnlCJmqkwONMmwrkCc6Ry4HDyDgYbQoRoWfJkctEKIW/qnsmR3h1XE+VAzHU2XorcQeAvnkzAdvB2MXWVGZHFPsorrehZ0x7kNhuAmF7BXO3XClsBzIBDdBGwdSl1pCWNycxuMuLzTEQpZhqZYvbJ8GhgsuTBnvtAgO4jY3d4QgNCKz5ZNlA6jdECeOVUUy2/Mygj++ImdnTtzt1QU5XwsSmg+OiYlW1T1fwZArd0KGyqJ6RHvHUD0YaxzNf3GoYAHTB1EOgHtr7ANs65MarQbV0rGv9s9VdIaq2QeJOc9ETXW2ZqozLo/112407hYZi4NS/RI+Joo4YP9kS5woUazxf/+phPOIaqnOpe6o6scuUx192xJkoPmmF3Y7xIS3koy9s3If7YFVugqYdLOECp86C2/7FbFxTg02Q9j10FSE8VpHg== 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 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. > > 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).