Re: RTC wakealarm write-only, still has 644 permissions

[David Brownell <david-b@pacbell.net>]

On Friday 30 November 2007, Pavel Machek wrote:
> > 
> > It's not an issue of accidental writes, it's an issue of there being
> > no other synchronization for setting those alarms.  Remember that both
> > RTC_WKALM_SET and RTC_ALM_SET ioctls can set that same alarm, and so
> > could a different userspace activity ...
> 
> We have 3 interfaces to one hardware resource. I do not think kernel
> should try to arbitrate it here. There's just one alarm clock with
> three interfaces.

Having three interfaces is bad enough ... ensuring that none of
them can ever be used safely would be stupid.


> > As written, this allows one userspace activity to clobber another if
> > it does so explicitly, by first disabling the other one and then
> > setting its own alarm.  But the idea is to minimize "accidents" like
> > unintentionally clobbering an alarm set by someone else.
> 
> Well, I could not get it to work with this "avoid-clobber" feature.

I had earlier pointed out a different issue, whereby "oneshot"
semantics weren't consistently followed.  I've been working on
some patches to address that.  The ACPI bits still need work,
but I'll forward one part soonish.


> > > If I remove "accidental alarm modify" logic, I can actually use rtc to
> > > wake up more than once per boot.
> > 
> > Evidently the alarm isn't being disabled then...

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That's the issue addressed by those patches.  (Specific to rtc-cmos,
not to RTCs on saner hardware.)


> I think we should just remove the 'avoid-clobber' logic. If userland
> wants to somehow arbitrate access, it can.

Pray tell, *HOW* could it arbitrate?


> Now, if we want to provide "nice" interface for timed sleep, I think
> we can. Actually, I'd like to use normal select() as such an
> interface,

Yeah, what ever happened to timerfd?  :)


> and enable kernel to automatically detect when it can sleep 
> and when it has to wake up.

There's the "rtcwake" thing.  That got merged into util-linux-ng, but
I happened to notice its setup_alarm() is calling gmtime() instead
of localtime() ... my suspicion is that the uClibc version I was using
had some timezone bugs, or else there's some other bug lurking in the
vicinity of dual-bootiness.

Note that "wakealarm" is not intende to be a "timed sleep" interface
at all ... it's just to set the wakealarm.  Something else is in charge
of putting the system to sleep, such as "echo mem > /sys/power/state"
or some GUI thing hooked up to logic that knows about how to make frame
buffers recover.

- Dave