linux-kernel - Re: [PATCH 07/39] vfs: export vfs

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:   Sun, 10 Jun 2018 05:57:04 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Miklos Szeredi <mszeredi@...hat.com>,
        linux-unionfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/39] vfs: export vfs_ioctl() to modules

On Mon, Jun 04, 2018 at 01:49:04AM -0700, Christoph Hellwig wrote:
> On Tue, May 29, 2018 at 04:43:07PM +0200, Miklos Szeredi wrote:
> > This is needed by the stacked ioctl implementation in overlayfs.
> 
> EXPORT_SYMBOL_GPL for exporting random internals, please.  Same
> for any following patches.

*blink*

Christoph, get real and RTFS - vfs_ioctl() simply calls ->unlocked_ioctl();
all there is to it.

This isn't even a case of "using that function establishes that the
caller is a derived work" - *anyone* who can see definition of
file_operations can bloody well open-code it.  There isn't anything
establishing derivation here.

Hell, it could've been a static inline in include/linux/fs.h and it would
neither differ from many other inlines in there nor need an export at all.

This is really getting close to lxo-worthy levels of bogosity...

More interesting question is why do we want to pass those ioctls to layers
in the first place, especially if it's something with different availability
(or, worse yet, argument layouts) before and after copyup.