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

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: <200711301310.40360.david-b@pacbell.net>
Date:	Fri, 30 Nov 2007 13:10:40 -0800
From:	David Brownell <david-b@...bell.net>
To:	Pavel Machek <pavel@....cz>
Cc:	rtc-linux@...glegroups.com,
	kernel list <linux-kernel@...r.kernel.org>,
	Alessandro Zummo <alessandro.zummo@...ertech.it>
Subject: Re: RTC wakealarm write-only, still has 644 permissions

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