linux-kernel - Re: [RFC 1/2] fs,eventpoll: Add ability to install target file by its number

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] [day] [month] [year] [list]

Message-ID: <20170217194502.GC23766@uranus>
Date:   Fri, 17 Feb 2017 22:45:02 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     Jason Baron <jbaron@...mai.com>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Andrew Vagin <avagin@...tuozzo.com>,
        Pavel Emelyanov <xemul@...tuozzo.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Kirill Kolyshkin <kir@...nvz.org>,
        Andrey Vagin <avagin@...nvz.org>
Subject: Re: [RFC 1/2] fs,eventpoll: Add ability to install target file by
 its number

On Fri, Feb 17, 2017 at 01:34:04PM -0500, Jason Baron wrote:
> > 
> > kcmp over target set seems to be preferred since it gonna be a way
> > faster. But I think about fd-ref idea too. Thanks a huge!
> > 
> 
> I sort of like kcmp() for this as well maybe the epoll fd argument can be a
> pointer to something like:
> 
> struct epoll_slot {
> 	int epfd;
> 	int slot;
> };
> 
> Where 'epfd' is the epoll fd, and slot is just an index into the target fds
> associated with the epoll fd. That is, you would start from 0 and go up to
> n. When you reach the last one you get in -EBADSLT or something.

Yes, I think we can even extend the slot and pass it as a pointer to
target fd set which are to be tested.

> Regarding Andy's point of of not having a reference by some other means, I
> think you have to have it basically otherwise it would be removed from the
> epfd. I guess it could be being passed via a unix socket? But there must be
> a way to get at those anyways, in order to restore them.

Yes. But the file may be obtained from unix sock, then dup'ed and installed
and then this dup'ed file get closed but unix instance is still alive. And
then we need to figure out that it's unix socket from where original target
file came from.

> Also, in the initial patch this function can not restore all target epoll
> files:
> 
> 'ep_find_tfd(struct eventpoll *ep, int tfd)'
> 
> Because the 'target' file for an epfd is the pair: {fd, file}. Thus, you
> could have say two different 'target' files with the same fd number.

Yes, but if we would have _DUP'ed them (ie installed into caller context)
we can find out their order and restore properly I think.

Thanks for comments, I'll think about all them at the weekend or early
next week.

	Cyrill