lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 08 Sep 2023 14:34:29 -0600
From:   Jonathan Corbet <corbet@....net>
To:     Michal Clapinski <mclapinski@...gle.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Muchun Song <muchun.song@...ux.dev>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>, Shuah Khan <shuah@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>, Yi Liu <yi.l.liu@...el.com>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Steve French <stfrench@...rosoft.com>,
        Simon Ser <contact@...rsion.fr>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Marc Dionne <marc.dionne@...istor.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        David Howells <dhowells@...hat.com>,
        Luca Vizzarro <Luca.Vizzarro@....com>,
        Jeff Xu <jeffxu@...gle.com>, Aleksa Sarai <cyphar@...har.com>,
        Kees Cook <keescook@...omium.org>,
        Daniel Verkamp <dverkamp@...omium.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-kselftest@...r.kernel.org
Cc:     Michal Clapinski <mclapinski@...gle.com>
Subject: Re: [PATCH v2 0/2] mm/memfd: add ioctl(MEMFD_CHECK_IF_ORIGINAL)

Michal Clapinski <mclapinski@...gle.com> 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/<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 recreated
> 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.

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?

Thanks,

jon

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ