linux-kernel - Re: [RFC PATCH 0/4] file: export functions for binder module

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]

Date:   Thu, 2 Aug 2018 15:31:20 +0200
From:   Christian Brauner <christian.brauner@...onical.com>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     Christian Brauner <christian@...uner.io>,
        Matthew Wilcox <willy@...radead.org>,
        Christoph Hellwig <hch@...radead.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        arve@...roid.com, tkjos@...roid.com, maco@...roid.com,
        rlove@...gle.com, ben@...adent.org.uk
Subject: Re: [RFC PATCH 0/4] file: export functions for binder module

On Mon, Jul 30, 2018 at 10:41:09PM +0100, Al Viro wrote:
> On Mon, Jul 30, 2018 at 10:28:40PM +0200, Christian Brauner wrote:
> > On Mon, Jul 30, 2018 at 01:19:47PM -0700, Matthew Wilcox wrote:
> > > On Mon, Jul 30, 2018 at 10:12:24PM +0200, Christian Brauner wrote:
> > > > > I don't expect this patch to be mergeable but rather to kick-off a
> > > > > discussion if we can either simply export them as they are or how we can
> > > > > get supportable exports that allow access to struct files_struct.
> > > > 
> > > > Maybe that wasn't obvious from the first message. Is there any way we
> > > > can come up with a way to have versions of these functions that you
> > > > would be fine with exporting?
> > > > The point is that otherwise we would have to either duplicate the code
> > > > or come up with something way more complex. If you have any pointer that
> > > > would already help.
> > > 
> > > He said in the first reply this should probably be using an anonfd.
> > > If you do that, I think all four of these exports go away.
> > 
> > I try and see if that is possible.
> > 
> > > 
> > > And there was really no reason to post each of the four exports as
> > > separate patches.  That just makes review harder on everyone.
> > 
> > Sorry about that. It usually depends on the preferences of each
> > maintainer how fine-grained such minor changes should be.
> 
> The fundamental problem here (besides "who the hell thought that this Fine Piece
> Of Software belongs anywhere other than in /dev/null?") is that messing with
> other's descriptor table is Fucking Wrong(tm).  It's not going to become
> a general-purpose interface.  That kludge is just that - a kludge caused by
> atrocious API design.
> 
> Exports NAKed, and if brought again they'll get NAKed with extreme prejudice

That's fair. When this discussion of turning them into modules was
started it was expected that this would never fly as is. The question
was whether there's any way for binder to touch struct_files of another
process directly at all. Now we know, there isn't. What I was hoping for
is that this would cause a redesign that avoids touching these helpers.
There's an effort from the Android folks now, which is good!

Thanks!
Christian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)