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 5AF79EEB570 for ; Fri, 8 Sep 2023 21:56:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FB316B00F9; Fri, 8 Sep 2023 17:56:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9AA6A6B00FA; Fri, 8 Sep 2023 17:56:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 872BF6B00FB; Fri, 8 Sep 2023 17:56:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 78E356B00F9 for ; Fri, 8 Sep 2023 17:56:07 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4CDC6141134 for ; Fri, 8 Sep 2023 21:56:07 +0000 (UTC) X-FDA: 81214788774.05.E5841F5 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf26.hostedemail.com (Postfix) with ESMTP id 7B2A314000F for ; Fri, 8 Sep 2023 21:56:05 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=WZvlF+mw; spf=pass (imf26.hostedemail.com: domain of mclapinski@google.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=mclapinski@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694210165; 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=+t21swsOyH2YblKosQFufOxa9wXHdCF/HAys5VxqFSU=; b=Q5tuUf8JugPTV5sn8UE2j1AmCxylBWUFfT1umBn9Aaj1098OSivA7ZEnqBMUCBQ8bQ/kxv N92cl/b0BBU5xZjxMNWuL0Siv04ZvvDcoGUPDwEnueq1yuUNY3/QrwlvEMsAtt2GFVbCsD BvvA+2cgbx4szR7pDskBf8y0ty+ILjc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694210165; a=rsa-sha256; cv=none; b=4g1NpLTYlut2pix1gVq2yP8tMY8Wcppdhdsrp/b7khV4INcb8CrQUuVIRLZ54r6lrP5vFw UWryp0Sdd2nQ0KWRZkWVM5Ki2KkAIPmyv/BsKbFAvzZzGkAm51ljyjAGsdx63LkptWfJhl OrnWkGoV5fWPiv1JPNKeiGi7eja5oNM= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=WZvlF+mw; spf=pass (imf26.hostedemail.com: domain of mclapinski@google.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=mclapinski@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-44d5ac10c41so1041396137.0 for ; Fri, 08 Sep 2023 14:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1694210164; x=1694814964; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+t21swsOyH2YblKosQFufOxa9wXHdCF/HAys5VxqFSU=; b=WZvlF+mwjU3Oct2QzIBBE2+9y55Wr/EYYF2hxXIBWsy6yUBq2op+FlbmjY3/tdi8n8 Z71QSc4rDu0le8HboLW6MUV4CurwuX5auw4KvmhKH6p/QhzU1N3abZab/hmD2U3Ze32H i5EZnH25HTsAu/D/rGCH5jS3J8yZymyVeYAnSoy8uBP23bCGmDdscaT6GMOjDq0r2EJF lgqXrQjufBGUgZDo1TIo/kPLmZzBeSLyHYevsT7ZB5WubKqTVUw7DU9AFG4ghgLcrmk8 WEXEvZyr5Ky4Ff3Ig644CQUJJDBWLuoRcFBO6hedueE+lzhN4QN8v4UGmHP6XiRJLdJd qxeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694210164; x=1694814964; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+t21swsOyH2YblKosQFufOxa9wXHdCF/HAys5VxqFSU=; b=j8NPr1z4z9ttzEN1M4gt5Y0UlcPOOnl0oUgt7mQ3sjdBTy2UsAbPQPvO8y8o8IcgMV Pj11W2fHE82mn/zJ8e2B0jS3hajPSJsCLrGVrBtHp3cwo4STtvU5A2pbyJbEEzLv3Kta d04+O/FeRjHwIjkgKDedRajUwvsDbHqTLyb3uLRvrGjhugNYJRLYVLZsX5Nf4vg4PJEg UD1G/NDE6A7W152XiBrhIlxEiEvtPsq9BofDjvR52TkWkmCreRVk2hszuGt78vPUTapR OCyA461Eaaq7iwfI7tyMuBLL2bmdeJVDqvm8w/9tjFYfqGlLOsLfY/vkvC97gY75LpMH 2blg== X-Gm-Message-State: AOJu0Yx7DAUqxgfn/DWM3QHX60VEkwgLObnEDqk426Dxk3FF1pup7GJr irQShOjUoDwDj8hYoQ24tWObaobm2s6nTQsBSfiK8Q== X-Google-Smtp-Source: AGHT+IFkquQZzfJEqi3aegfL32v0MUP4COi0KsBHXJhNEJqPgvoL5VJcvuAC408MwYd6jYtnlMbhsJ/oBBfA1JrwqlA= X-Received: by 2002:a05:6102:3004:b0:44e:99a2:a51 with SMTP id s4-20020a056102300400b0044e99a20a51mr3887876vsa.30.1694210164298; Fri, 08 Sep 2023 14:56:04 -0700 (PDT) MIME-Version: 1.0 References: <20230908175738.41895-1-mclapinski@google.com> <87tts4z9nu.fsf@meer.lwn.net> In-Reply-To: <87tts4z9nu.fsf@meer.lwn.net> From: =?UTF-8?B?TWljaGHFgiBDxYJhcGnFhHNraQ==?= Date: Fri, 8 Sep 2023 23:55:52 +0200 Message-ID: Subject: Re: [PATCH v2 0/2] mm/memfd: add ioctl(MEMFD_CHECK_IF_ORIGINAL) To: Jonathan Corbet Cc: Mike Kravetz , Muchun Song , Andrew Morton , Hugh Dickins , Shuah Khan , Greg Kroah-Hartman , Arnd Bergmann , Yi Liu , Dominik Brodowski , Hans Verkuil , Steve French , Simon Ser , Jason Gunthorpe , Marc Dionne , Jiri Slaby , David Howells , Luca Vizzarro , Jeff Xu , Aleksa Sarai , Kees Cook , Daniel Verkamp , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7B2A314000F X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 3hkgappy1uy6tojue9m9hmmqhp75szt3 X-HE-Tag: 1694210165-590941 X-HE-Meta: U2FsdGVkX1+3R7WahZ5L045bhVwtYU5xJEafgyfNOi5pNrUwiDC+O/hH95g0fEMLyzRjr60gxhKK+bDMC8ClwHQw7HIIvG545J8VunYjctihdX+7IhtGqPbJnu9zkPzDr4dCMiSZr9vdE9/H+cHthq7LWVk9hPJGBzjnLQVWw/yKWQIHpWwvQCdsmJjhoD6GNcFF3vrtEeIlprYIDWj+dP2Lf0uavt7JnkeFIYugRg0CqX98YKRNqhGoQunqxgQBZQEi670xJeGjT4iCN2bbfVoAGOyZcNCtAoh9eiLZYKdSvn335euA7wMWW01ASDVmlL2myqdOjkDYAv9cjWQN0+UkCiqpWxpGlZWKykh3iGamMRKBvEkhzLN2uu5ZGITapPaOhvu36TYsCM9NPdorfGf+fWdNz/1mNcH3xX42GznyjqmGrh4boE33gFI2DNXmk0LNMOSJBoHYt65VaUQ46LoS4aIrGejo+HCENIqLwhL4or0HL5nZmd8Lteu1kWCRXxlaB3X8vyGxZnfwvBeUToiI84GTQLde5EyiXUi0e4onF5wesiDcaUXoyESBYDON9GwjyujzyNou+7lkqmZHXytFaaw56IiyXOTRBowtB2+IgUeijVkdcwSHZ+iG0mdfSi6HDcPqi9zEPFT/HX81M8bYGXM70X+1spuOP6/hsH7C0gJETxmmo7FYLS9onAtaVQxJWXKozqLhiQ+FxJo2Jzdi9gRzYWXyzv7cA+9F4qhi+RC3wYkqa+7h+vgmxny/iGlQgn1DqkQO8uJd+ukE/Q13MluUwoFdilmd7Rr/iEc3YlJhfjgeOzRX5ZuMHm52GIZ3V9gHUzOIizNQFWISM85vnsSLd6UPgpDS08G5NpcSLsy9asj9pXwCJkt7zQx+wmGrTDIHsQTr+chdlsA/UmqUL+UdDP0RoNhZ1omAT3cKBi/bsxtrR0pEDPd45H75xltxOd+w6MQw6p84f4S vUoq2AAH UTAUFKEq9cE6US1yUak42ekRwQ3/oHHtlnCDlrxLy5nyL7+uwepPqZZpGI5aqUOrpkUBvhj55WCW/EvI37pJ9Qcaclr+OMEjtvrGbRQ80iRM8zE3MKfUuXwA1E3aSA1lEkUaknJY/fWCpH+XeRjLCPuVWIchpi3kYhIfD/WrM3pHcopQOoZPNpdoLV6PmGYiBQ2UjsHVaMX/hKkIlc0Cf5u+Md4rpzdsooC1UxBAu/d22QEU1sWmqlS03B//pEzsosVPSP5UZ3ro5xki7kxN9HIJ8/3mft7fePmVFBvWl/zenkd0afwLevAdf+i1PRHQXF5b3mvtum5AlnKItP/hwUskBRCoSvhtti0BvZgLo6HpglQcRQCPH0I4wyfQn3tjm+ZAbZb2cUAM/WQSKC1Jny0wTukqCJBf/CbFkC6g0oVY0fc8= 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, Sep 8, 2023 at 10:34=E2=80=AFPM Jonathan Corbet wr= ote: > > Michal Clapinski writes: > > > This change introduces a way to check if an fd points to a memfd's > > original open fd (the one created by memfd_create). > > > > We encountered an issue with migrating memfds in CRIU (checkpoint > > restore in userspace - it migrates running processes between > > machines). Imagine a scenario: > > 1. Create a memfd. By default it's open with O_RDWR and yet one can > > exec() to it (unlike with regular files, where one would get ETXTBSY). > > 2. Reopen that memfd with O_RDWR via /proc/self/fd/. > > > > Now those 2 fds are indistinguishable from userspace. You can't exec() > > to either of them (since the reopen incremented inode->i_writecount) > > and their /proc/self/fdinfo/ are exactly the same. Unfortunately they > > are not the same. If you close the second one, the first one becomes > > exec()able again. If you close the first one, the other doesn't become > > exec()able. Therefore during migration it does matter which is recreate= d > > first and which is reopened but there is no way for CRIU to tell which > > was first. > > So please bear with me...I'll confess that I don't fully understand the > situation here, so this is probably a dumb question. > > It seems like you are adding this "original open" test as a way of > working around a quirk with the behavior of subsequent opens. I don't > *think* that this is part of the intended, documented behavior of > memfds, it's just something that happens. You're exposing an artifact > of the current implementation. I don't know if the exec()ability of the original memfd was intended, let alone the non-exec()ability of subsequent opens. But otherwise yes. > Given that the two file descriptors are otherwise indistinguishable, > might a better fix be to make them indistinguishable in this regard as > well? Is there a good reason why the second fd doesn't become > exec()able in this scenario and, if not, perhaps that behavior could be > changed instead? It probably could be changed, yes. But I'm worried that would be broadening the bug that is the exec()ability of memfds. AFAIK no other fd that is opened as writable can be exec()ed. If maintainers would prefer this, I could do this.