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:	Mon, 13 May 2013 20:18:07 +0200
From:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To:	Sören Brinkmann <soren.brinkmann@...inx.com>
CC:	Mark Brown <broonie@...nel.org>,
	Mike Turquette <mturquette@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC] clk: Introduce userspace clock driver

On 05/13/13 19:58, Sören Brinkmann wrote:
> On Mon, May 13, 2013 at 07:37:23PM +0200, Sebastian Hesselbarth wrote:
>> It is, as it will only expose clocks on Zynq and that's what Mark and
>> Mike are worried about. Expose clocks to user space and you will have
>> people mess with it for sure.
> Well, even if you contain it in that driver you can still mess with
> other clocks. Just give it the "wrong" input clock references in DT and
> you are free to control them. As I said before, there is no protection
> against such misuse.

Put the wrong clock in DT is not "misuse" but "bug" ;) More important,
it is quite static as you cannot change it easily by echo'ing into some
sysfs file. And to inject a DT you need access on boot loader level,
not kernel user space (yet).

>> About the shape of it, I didn't expect that to change at all. Just
>> wondering, if it still requires you to manually end it's endianess
>> mess with the bitfiles. If you go at it, consider reading the magic
>> hidden in the bitfile and swap it when it is required. But that will
>> go OT here.
> It still takes byteswapped, binary images as input, unfortunately.

Please, if you ever mainline any kernel driver for it, make it
auto-swap.

>> If you don't want to merge both drivers, have a Zynq-only clock
>> fabric driver instead?
> That was my original intention. But due to the nature of it, it will
> always be possible to use it with other clocks too. Hence my generic
> approach.

I already tried a generic "expose clocks to user space" and failed for
the very same reasons Mike and Mark are repeating over and over again -
and I agree with them.

> I actually like the idea of making it part of the device config driver.
> The downside of it is, that this driver seems a bit far from mainline.

Have a skeleton driver that exposes Zynq clocks first and implement
device config later? IIRC, device config isn't that complicated to
implement. Unfortunately, interpreting Xilinx datasheets or source code
is.

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