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:	Sat, 11 May 2013 18:21:32 +0400
From:	Mark Brown <broonie@...nel.org>
To:	Saravana Kannan <skannan@...eaurora.org>
Cc:	Mike Turquette <mturquette@...aro.org>,
	Emilio López <emilio@...pez.com.ar>,
	Sören Brinkmann <soren.brinkmann@...inx.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH RFC] clk: Introduce userspace clock driver

On Fri, May 10, 2013 at 04:01:25PM -0700, Saravana Kannan wrote:
> On 05/10/2013 03:18 PM, Mike Turquette wrote:

Guys please delete irrelevant context from replies...

> >One way to do it is to introduce a new config option,
> >CONFIG_COMMON_CLK_DEBUG_CONTROL that would expose the controls for
> >every clock in the existing debugfs infrastructure.  The downside to
> >this approach is that it would get abused and ship in millions of
> >Android products using horrible userspace hacks to control clocks.
> >Maybe that's not our problem to solve, maybe it is.

> We already have this for MSM. But I seem to have managed to keep our
> userspace guys away from abusing it. YMMV.

It's much harder when it's in the standard kernel and there's no contact
with some of the users.  I've pushed back pretty strongly on some of
your equivalent stuff for regulators for this reason.

> >I think that Soren wants something with a stable interface that he can
> >use for his Zynq use case.  Regarding that, why not write an actual
> >device driver to do what you want to do from userspace?

> Exposing clock control to userspace production use is a terrible
> idea. A misbehaving userspace can easily kill the system. This is
> not so try for GPIO. So, exposing GPIOs to userspace is relatively
> less of a concern.

Pick the wrong GPIO and you face the same issue.

Note that we do have a UIO framework in place so there is some concept
of doing this sort of thing; that is all about picking specific things
and exposing them (in a somewhat similar fashion to this) rather than a
default available thing though.

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

Powered by blists - more mailing lists