linux-kernel - Re: [PATCH] Posix CLOCK_RTC interface proof of concept

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: <20100917075207.GA12438@riccoc20.at.omicron.at>
Date:	Fri, 17 Sep 2010 09:52:07 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	David Brownell <david-b@...bell.net>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] Posix CLOCK_RTC interface proof of concept

On Thu, Sep 16, 2010 at 12:41:32PM -0700, John Stultz wrote:
> Exposing multiple RTCs via the posix clock interface has some tradeoffs.
> 
> a) Some application programmers may really want to see the underlying
> hardware and be sophisticated enough to deal with the multiple,
> possibly unsynchronized, time domains.
> 
> b) Some application programmers may not care about the hardware, and
> just want a interface that works like CLOCK_REALTIME, but fires
> wakeup alarms if the system is suspended.

I like the idea of offering the high-level posix clock API for various
hardware clocks. Also, keeping low-level access for specialists makes
sense, as long as there is a way to enforce correct access control. If
we make the posix clocks truly dynamic (with removal, too), then one
could offer a low level funtion to grab the clock before use.

> Exposing all the RTC devices in a somewhat raw manner is probably
> the most straight forward. Some extra infrastructure, like
> the dynamic posix-clockid allocation Richard Cochran has
> started to look into will be needed. More concerning is that
> this will probably cause some grief if someone creates a cron-like
> tool that uses the RTC where the RTC isn't exactly synced with
> system time. When the user specified a job for 6am, do they mean
> 6am system time, or RTC?
> 
> And note: on many PCs, the RTC is synchronized, but kept in local
> time, not UTC. So the unsynched RTC case is likely to be common.

We could also advertise the clocks properties (eg timescale) via sysfs
(or clockfs, as Greg K.H. put it).

> 3) Adding the posix time interface makes it easier to have finer
> grained capability management to decide what applications can
> set a alarm timer. While this is great for creating applications
> that can wake servers up from suspend mode, and simplifying the
> wakeup infrastructure on cell phones, some systems may not
> want applications being able to set wakeup timers. I can
> imagine the "laptop in well insulated carry-on luggage" case
> that comes up occasional being one of them. So some additional
> thought and policy may be needed to decide when non-user-triggered
> wake events should be masked or not in suspend.

Again, implementing dynamic clocks would allow the sysdadmin to just
remove the clock whenever it might cause trouble.

Overall:

I only took a quick look at the patch, but I like the general idea.

You introduce posix timers that are *not* based on the hrtimer code,
but rather on a second implementation. I wonder whether one could
abstract the timer management code to work with different clocks.

I have been thinking about that for the PTP hardware clock stuff and
will soon post a new round of patches.

Thanks,
Richard
--
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/