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: <20150423160807.GA34808@dtor-ws>
Date:	Thu, 23 Apr 2015 09:08:07 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Doug Anderson <dianders@...omium.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Enabling regulators form userspace

On Thu, Apr 23, 2015 at 11:35:45AM +0100, Mark Brown wrote:
> On Wed, Apr 22, 2015 at 01:56:44PM -0700, Dmitry Torokhov wrote:
> > On Wed, Apr 22, 2015 at 09:11:12PM +0100, Mark Brown wrote:
> 
> > > There's already a userspace consumer driver you can bind for test
> > > purposes which could be used here.
> 
> > Thanks for the pointer, but I do not think this would work for this use
> > case, mainly because the controllers in question often impose timing
> > constraints on the supplies. I.e. while holding reset GPIO you turn on
> > vdd and then, after at least X msec, avdd, and then release reset GPIO.
> 
> This really sounds like you should be writing a device driver here, even
> if it's just a little module you write separately to the actual device
> driver used in real systems.

No, no way. If it is lives in kernel I have to review it and then either
upstream and maintain it in mainline or maintain it as out-of-tree
driver. If it is in userspace I do not even have to look at it.

> 
> > > I'm not keen on having something in there as a standard feature, it's
> > > just this massive "abuse me" flag - there's not really much of a
> > > production use case for it but lots of "let's just hack around our buggy
> > > drivers" use case.
> 
> > I would contend that the drivers are not necessarily buggy: we just do
> > not want to encumber the kernel driver with all the details about test
> > interface that is very much controller specific (i.e. we can't easily
> > generalize it for all permutations of Atmel/Cypress/Eantech/Stnaptics
> > etc controllers) and that is not going to be used during normal
> > operation.  However it is very much a production issue as these test
> > utilities are used during factory runs to ensure quality of produced
> > hardware.
> 
> 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.

Thanks.

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