netdev - Re: [PATCH] net: delete /proc THIS

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: <20180115230130.GO13338@ZenIV.linux.org.uk>
Date:   Mon, 15 Jan 2018 23:01:30 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     David Miller <davem@...emloft.net>
Cc:     adobriyan@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH] net: delete /proc THIS_MODULE references

On Mon, Jan 15, 2018 at 02:50:12PM -0500, David Miller wrote:
> From: Alexey Dobriyan <adobriyan@...il.com>
> Date: Sat, 13 Jan 2018 20:11:52 +0300
> 
> > /proc has been ignoring struct file_operations::owner field for ages.
> > 
> > Signed-off-by: Alexey Dobriyan <adobriyan@...il.com>
> 
> What, then, makes sure that the procfs files are unregistered before the
> referencing module is unloaded?

Procfs interposes a bunch of wrappers for file_operations methods.
Attempt to remove proc_dir_entry marks it as going down and waits for
use count to reach 0.  Wrappers check if it's marked and bump the
use count for the duration of actual method call otherwise.  IOW,
removal prevents any subsequent method calls and waits for all
calls currently in progress to finish...

> Please explain the situation, and add a reference to the commit that
> made procfs stop using the fops owner field.  That commit and it's
> commit message may help explain why all of this is fine.

Umm...  It got started in
commit 786d7e1612f0b0adb6046f19b906609e4fe8b1ba
Author: Alexey Dobriyan <adobriyan@...ru>
Date:   Sun Jul 15 23:39:00 2007 -0700

    Fix rmmod/read/write races in /proc entries

Bugger if I remember how long did it take for the dust to settle - there
had been bugs in the original, and it took some time to fix.  I think
the last straggler had been
commit 7e0e953bb0cf649f93277ac8fb67ecbb7f7b04a9
Author: Al Viro <viro@...iv.linux.org.uk>
Date:   Sat Feb 21 22:16:11 2015 -0500

    procfs: fix race between symlink removals and traversals

and it had been a while between that and the previous one.  Of course,
we still might have bugs there, but that's not different from anywhere
else in the kernel...

Procfs file_operations had not been supposed to need ->owner for at least
a decade...