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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Apr 2015 09:52:40 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Mark Brown <broonie@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Enabling regulators form userspace

Hi,

On Thu, Apr 23, 2015 at 9:08 AM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
>> It's not about the quality of an individual driver, it's about the
>> potential for misuse - making the kernel interfaces such that it's easy
>> to do the right thing and hard to do the wrong thing.  Having the
>> ability to just bang on this stuff from userspace seems like it's
>> encouraging problematic behaviour.
>
> What kind of misuse are you concerned with? I can see that we may not
> necessarily want to allow setting arbitrary voltage directly from
> userspace, but asking kernel nicely to enable regulator with
> regulator_enable() (we may refuse for regulators that are requested in
> exclusive use) and similarly disable it with regulator_disable() should
> not be any more dangerous than having a random kernel module do that.
>
> Sometimes shoving everything into the kernel is not the best idea; some
> tasks are better suited for userspace. We already allow raw userspace
> access to i2c, usb, spi, pci, PS/2 ports, parallel ports, and probably
> more. Why regulators should be special in this regard and accessible
> only through kernel? This causes programs that work fine on one
> architecture (x86) to fail when moved to another (arm) with no way of
> fixing it.

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.

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).

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".

-Doug
--
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/