linux-kernel - Re: [PATCH v1 3/3] param: allow to selectively enable /sys/module/MOD/paramaters nodes

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: <87vcr6os1r.fsf@rustcorp.com.au>
Date:	Mon, 31 Oct 2011 12:12:23 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	David Decotigny <david.decotigny@...gle.com>,
	linux-kernel@...r.kernel.org
Cc:	Randy Dunlap <rdunlap@...otime.net>,
	Michal Schmidt <mschmidt@...hat.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	David Decotigny <david.decotigny@...gle.com>
Subject: Re: [PATCH v1 3/3] param: allow to selectively enable /sys/module/MOD/paramaters nodes

Hi David,

        I'm having real trouble parsing your descriptions.  I found it
easier to read the patches, and that'd not good.

On Wed, 26 Oct 2011 19:22:27 -0700, David Decotigny <david.decotigny@...gle.com> wrote:
> This change defines CONFIG_SYSFS_MODULE_PARAM to prevent kernel module
> parameters from being exposed to user. When unset, /sys/module/MOD is
> populated as usual, except for the "parameters" sub-directory, which
> is not created anymore.

That's backwards.  CONFIG_SYSFS_MODULE_PARAM *enables*
/sys/module/<modname>/parameters, this implies it disables it.  Sure, it
allows it to be disabled without disabling all of CONFIG_SYSFS.

> Context: by default, when the module_param() attribute perm == 0, the
> module attribute is not exposed to user in
> /sys/module/*/parameters. Many module implementations use this
> strategy, presumably to spare some memory.

No, they use it because that was the default when I transferred them all
from the older module parameter system.  It was the safe choice.

> However, it can be
> interesting to retrieve how kernel modules are configured at run-time
> (debug, audit, etc.): it would be nice to see more modules have perm
> != 0 in order to expose their configuration pararemers to
> user.

But this patch doesn't address any of that.

> Unfortunately, this doesn't play well with memory-constrained
> systems that need sysfs but don't need this level of
> introspection. This change allows to support both use cases.

Do you have any statistics to support your assertion that this has any
significant effect on memory usage?

Your patches seem fine, but your descriptions are not straightforward!

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/