linux-kernel - Re: [GIT PULL] hash addresses printed with %p

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, 1 Dec 2017 09:47:54 +0000
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Tobin C. Harding" <me@...in.cc>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>
Subject: Re: [GIT PULL] hash addresses printed with %p

On Thu, Nov 30, 2017 at 06:17:47PM -0500, Linus Torvalds wrote:
> On Thu, Nov 30, 2017 at 12:10 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> >
> > So changing it to use __ATTR() should fix this remaning leakage up.
> > That is if we even really need to export these values at all.  What does
> > userspace do with them?  Shouldn't they just be in debugfs instead?
> 
> So what I find distasteful here is how sysfs has these "helper" macros
> that are clearly designed to over-share.

That is by design :)

> The __ATTR macro is a lot  more complicated to use than the
> __ATTR_RO/WO/RW macros, but those macros end up giving everybody read
> access (ok, not the WO one)
> 
> So honestly, I think the "helper" functions should be deprecated
> simply because they basically encourage people to make everything
> world-readable.

Almost all information in sysfs is designed to be world-readable.  I
would argue that almost nothing there should be "root only", as sysfs is
not the place for trying to display "private" information at all.  It is
designed to show a representation of the kernel's internal state of
things (device structure, driver options, firmware objects, etc.)  All
of that information should be freely available to everyone (within the
namespace rules.)

To put root-only information in sysfs is not a good idea, which is why
those macros are there, to make it easy to do it right, and hard to
restrict information.  If you need restrictions, you shouldn't be using
sysfs, as it's almost always something for debugging, and that's what
debugfs is for.

thanks,

greg k-h