linux-kernel - Re: Enabling regulators form userspace

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]

Message-ID: <20150423175000.GX22845@sirena.org.uk>
Date:	Thu, 23 Apr 2015 18:50:00 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Enabling regulators form userspace

On Thu, Apr 23, 2015 at 09:52:40AM -0700, Doug Anderson wrote:

> Personally, I have been annoyed several times by the lack of an easy
> way to control regulators from userspace.  While doing development of
> regulator code it is very handy to be able to change the voltages from
> userspace so I can probe them with a scope.  I have a terribly hacky /
> wrong CL <https://chromium-review.googlesource.com/#/c/214475/> that I
> actually wrote for this.  Note that userspace consumers were a bit
> cumbersome for this purpose.

There's a test consumer in mainline for precisely this purpose, I used
to use it a lot when I was doing bringup of regulator drivers on
evaluation boards - look at virtual.c (which is separate to the
userspace consumer in that it throws usability to the wind, though some
trivial shell scripts fix that).

> I wonder whether we could achieve "safety" and "don't abuse" problems
> by doing something like:

> 1. Put the interface in "debugfs", not sysfs.  Hopefully folks know
> that userspace isn't supposed to rely on debugfs.  ...though perhaps
> userspace in the factory (test tools) are OK to use it as long as they
> understand that it is fragile (API may change) and dangerous (could
> shoot yourself in the foot).

I'm not optimistic about this achieving the desired results, we export
too much stuff through debugfs that's useful in production so all it
really does is give us a bit more ability to say "I told you so".

> 2. Require a config option to enable it with suitable warnings in the
> KConfig option.

> 3. Force the user to write a "y" into a file named
> "i_know_this_is_unsafe", or something of the sort.  Writing this could
> write a suitable warning to the kernel log saying "If you let the
> magic smoke out, don't blame me".

I don't think either of those accomplishes anything meaningful, it's not
like we've got a good track record on getting people to pay attention to
warnings or do transitions.  With echoing into a file I'd just expect to
see patches turning off the warning because of course everyone thinks
that their own use case is totally sensible, reasonable and well thought
through (and some of them actually are).

Like I say I think if we're delegating this to userspace we should
actively choose to do so, not just throw everything over the wall.

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