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 1A9BAC6FD1F for ; Sat, 25 Mar 2023 14:51:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 080776B0071; Sat, 25 Mar 2023 10:51:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 030CC6B0074; Sat, 25 Mar 2023 10:51:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3AD76B0075; Sat, 25 Mar 2023 10:51:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D2F8E6B0071 for ; Sat, 25 Mar 2023 10:51:10 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A895E40174 for ; Sat, 25 Mar 2023 14:51:10 +0000 (UTC) X-FDA: 80607708300.27.8A8EFB6 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf10.hostedemail.com (Postfix) with ESMTP id CAD0FC001E for ; Sat, 25 Mar 2023 14:51:08 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YIxWnRvb; spf=pass (imf10.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.43 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=1679755868; a=rsa-sha256; cv=none; b=6e/8yxaoawj1tlaFg4bv+VBz9ijiL/2S0jYlv2BhdeEjUdGqlN39KWfXeoYFYaOqMC8mQv 6TiszplZx37PoBC9sgQeVyyOUaOt/SnypsArdlLlCd5JBBTbYotT822L84CRFOsNXgOIAB a1Oe5k6NFamFmOxbj8t8ciFBApSOWuo= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YIxWnRvb; spf=pass (imf10.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.43 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=1679755868; 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=ySh77WYndzjOR+CX47ERtnD0mcuGMBzVNo+cYOVc9lE=; b=Zv4yyk//bk/xezw5h80a/Zc6zp1ARXr9n/W1ACA80SWrpVeeZv1LkXAmX5KRfHCEdoNKi0 yuGdjVYdi2mh7kBzULt82GJKf3WJx1VP12rOJIK2D0eAXIK6qfKec1MIBXcNYisI010ySL qxpuW/pup68Ih8iH6U8UNhZB1CJGzJY= Received: by mail-wm1-f43.google.com with SMTP id u11-20020a05600c19cb00b003edcc414997so2581992wmq.3 for ; Sat, 25 Mar 2023 07:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679755867; 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=ySh77WYndzjOR+CX47ERtnD0mcuGMBzVNo+cYOVc9lE=; b=YIxWnRvbRuIrziHkPVy93bivYtLbUVDXqcbIVq9inB9t95U4qRBcygInJD1Sna/85I imdG37F5YqcfjPoNyPhJHkeFbkBlqCq91KGZHHIqiHEkwyzcJh9hdguoAfL/Kanjt0SA vgnixpZqLqEZtr2IPC+r5zDjnFCvWrE+/Qenn4sjAaG9MDZiv2+d5gXa53hGeV7ImpEb FWcWiw2v2irNcXXayqYCRnmOdz6gNFqC6yr+jY5FcZ+T9Lv+K+VutE9pXitt+4080ASH 2pGyxKobIsFEKmbjNN/7DcZojmL2J+WzL85Wpck7ZVLGU91QI8hAujbrurvG9anRC34E G4IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679755867; 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=ySh77WYndzjOR+CX47ERtnD0mcuGMBzVNo+cYOVc9lE=; b=uT92e4fSbmVr1zWINhA9YOZj+MiJhGsy5gF90uj0TSRzkdP8HyxM0Zy5ruHASFzm1t CzxnbOIC/kAdaIzi8rQNveV6lfcoKEr8q3pVr7kbOdwcrUT+tbz40vInvb/23tGnaQQx p4UsQux7+pQlBjjpKMp0QRFINn0uQuJzQghsClE95mumOawHnGJXOAHA7jnUjVv6TugD 0/U4K7AqEk07XNC15uWaMksYk/obRbn1VaxVfl4O2ln1Z/i1ka9E90iPrRYJN1wNQOLL fzt86SZzXB9jnOHlujRhCx9sC/O4mLsbyKZZ54mDxHzY67+dU3hJEy0JYGAmfUGyaWql Y2Ug== X-Gm-Message-State: AO0yUKV3JvGnuLM/uUhCqoGkPRaz4DEa/bJEsgtr09tB5+Fzz2pCSnKF E+1CkFVMhGTesvkPbxMZPXs= X-Google-Smtp-Source: AK7set8OMRQSnNnakHP/T1anC4nbEP0dOmnRWcBbj539nWSC++fI+bZx/GWFxqFlxg2Lfo651hcZ+Q== X-Received: by 2002:a05:600c:230c:b0:3ea:e4f8:be09 with SMTP id 12-20020a05600c230c00b003eae4f8be09mr4901667wmo.30.1679755867046; Sat, 25 Mar 2023 07:51:07 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id l32-20020a05600c1d2000b003ed29189777sm3064927wms.47.2023.03.25.07.51.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Mar 2023 07:51:06 -0700 (PDT) Date: Sat, 25 Mar 2023 14:51:05 +0000 From: Lorenzo Stoakes To: Andrew Morton Cc: linux-mm@kvack.org, David Herrmann , yshuiv7@gmail.com, bugzilla-daemon@kernel.org Subject: Re: [Bug 217238] New: Creating shared read-only map is denied after add write seal to a memfd Message-ID: <45e081de-47a9-49e1-8420-51979dad40f5@lucifer.local> References: <20230324133646.16101dfa666f253c4715d965@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230324133646.16101dfa666f253c4715d965@linux-foundation.org> X-Rspam-User: X-Rspamd-Queue-Id: CAD0FC001E X-Rspamd-Server: rspam01 X-Stat-Signature: cow4r6boqq4heqwcnob4gh8eizfgzj8x X-HE-Tag: 1679755868-459287 X-HE-Meta: U2FsdGVkX19ocoyWaVLJUK0/jK4svwWcmARIGwUGbXx0xpd6YccR8V7KlD8bRgJFlLPHhL6miWVJRd88ZqvqckoINFo/lStEqKrA+kpCFiyQoK5eVAq2l8BRbW9IX+USdf8WXdUbhaYN2W2YIRu9fayVlBUifpl45hG7UtyG5/KbUmuHrBXEIfIns8l6XfSsMbJSvfXVdq8wnst2liC2MG8Sjld2zQUqO/s2unV59cjJljGC0eyPm/MRJtX3PGIuO0w3MmXAnulU1fFnZP6wB4HIoN/hdQbVg7EgCyEqvNlV8oehkOjQ2ZCdEUiO6lIYp7dSDXoiFehf8bNPncP/04PAonLf0qeq+1BWJhLQSfv5bMySI1M/X0uvqT1+phrH+n4ZTG++fOYAy/QPxeWWxKdY0eB17ouX9FZTATQqp0DR4ZuulDAcGGBmIcZv/p60p1U3V9PW7y41RrOv4RhCTX7y6/HzjJQthIX22uxaoU3AC8MejYZKLe+o5On4JtGkKjiOAMHfgkcVg3ExjOGLCbramxGtWxkpBjl83R/k6XKPXNvVhMAHFoK1PvVQBZXYsSesgKv3lEEFIztSVorfhD12eXrYb7w0E6Qbfy1WdTJRKijLwNE06CkoIKTUAFLNbSI1Q1a5EVFVoW+vwrtSoPiQ5B8bCYG8Yx3o5/cQiSUq8vpm5RUHhTgYlOLQ06AKU+rqtd0jgLYj+fM+brxLD+PkS0pNTqG/9g7ZRvywzBmIHSrA3cwShJlummpT+IMY+1nI0duYY0l783hWzCI0DBvat7u6YaJli5AZ6agV3aIM/txuVuW7pH/dZe1rk4j7SvIHK/B+ko1TK6hDzbLYxlfR4vrn4I0b0cxS2+MmZkNfL3Ek3b//T6qKnzzVQ18kHbk+CZ4wRVJghezoa7MiW9repZhw+HB12OPNtr8QuZfwwsaU8ZA3iUvgVvGebKueyAcKkzWRhq/CKTSZeL9 TcjEtJ/N qTFAKua/idx3LbqkIi4frkFrBvyM9ueFp1hllze89AyXd6VKJwGXBoILK3/CZ2gKkkGuSthid/bnxjP1io3NMQIMDxP/5595CRa+sdjsLsyTcs2cQweMShKRCdyoj3OkdHhsNzJsfNkhEzGBgYCKmP9ZZKeEWu2vJEgKe3PeXXSlsqrzT2fuHYCCtTJMtTtWIZq6iCqeRtjOkYFqU3HJq+oxuz3EjRiSNVbUhlQJ+xV4h03yN2uftZ2wK7Rkk4JOM6Ftzk2z6T+5idv9zC4RX6jOM6i1mmX5MgTVX2JFM6xyfttSf+VIwIIIKMrthx5XXaPgdJBmU2J4tfgi85yRI0XSWfTH1R8F544rWZLFO2/cRMi0l24NEuxpTX4GaDn7PDKoD8vKNTKyW5PvN9kE60FtsI5oDCbfPmst22Xtq1WjJiKqdWCf+HDLh0/kxxepHhScWWhMzjHPiU3ZBZHLqP9VIbMuJX3lwYcZoGmdp+0AyNpIVbqFhfwYIxgK2oZ16iYiSdvt3xbmoa5ksp0nivvyDTrpsD+8pbN8BfRR7Bz3k0KLn3eHK+lhLW6SZaIJrHw2cRCwZKHdIxuPN7FBZ59YYRxk29CxW1AZ9S/gUq0FBJ/6/q5v5xADy+Q== 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 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.