linux-kernel - Re: [PATCH RFC] clk: Introduce userspace clock driver

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:	Fri, 10 May 2013 16:25:45 -0700
From:	Saravana Kannan <skannan@...eaurora.org>
To:	Sören Brinkmann <soren.brinkmann@...inx.com>
CC:	Mike Turquette <mturquette@...aro.org>,
	Emilio López <emilio@...pez.com.ar>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] clk: Introduce userspace clock driver

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

>>> 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.
> Well, the FPGA clocks are only used by stuff in the FPGA. They cannot
> mess up the Linux on the A9s. I my use-case is kinda special. And people
> request functionality to easily adjust the frequency for their FPGA
> design in SW from Linux.

How do you talk to the FPGA? What happens if the FPGA clock gets turned 
off when the Linux is communicating with it? At the least the I2C or 
whatever bus you used to talk to it could hang. You need to explain more 
about why it's "special" before people might turn around to give 
userspace ABI for clock control.

> Nevertheless, there is no real protection from taking the driver I'm
> proposing to control the FPGA clocks to control a clock vital to the
> system.

If we are talking about changing the kernel to control different clocks, 
that true for any driver.

If your idea of this driver was something that will take a clock name 
and rate and change that clock's rate, then that's not a good design. 
What Mike probably meant was a FPGA specific driver that will only 
clk_get() the clocks related to the FPGA, and expose options to 
userspace. Not the actual rate or enable/disable capability.

For example, opening the device could cause clk_prepare_enable() and 
closing it would cause clk_disable_unprepare(). You might have ioctls to 
let userspace pick one of different modes of operation with each 
corresponding to a different clock rate and other corresponding FPGA 
configuration changes, etc. That's just a rough sketch. If you write 
such a driver, userspace can't misuse it to mess with other clocks or 
leave the FPGA clock in a bad state.

-Saravana

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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/