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]

Date:	Thu, 29 Nov 2007 00:26:47 +0100
From:	Pavel Machek <pavel@....cz>
To:	David Brownell <david-b@...bell.net>
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

Hi!

Sorry for long delay. I got rtc wakeup to work... once per boot. On
2.6.24-rc3.


> > > root@amd:/sys/class/rtc/rtc0# ls -al wakealarm 
> > > -rw-r--r-- 1 root root 0 Sep 20 12:30 wakealarm
> > > root@amd:/sys/class/rtc/rtc0# cat wakealarm 
> > > root@amd:/sys/class/rtc/rtc0# cat wakealarm 
> 
> The alarm isn't set; so no value gets displayed.
> 
> 
> > > root@amd:/sys/class/rtc/rtc0# 
> > > 
> > > 
> > > ...standard PC with reasonably recent kernel...
> 
> Yeah, well a "standard PC" is chock full of fairly bizarrely
> glitchey hardware.  Clocks and timers have more than their
> fair share, or x86_64 NOHZ support would be merged by now!

Oops. Ok, this is thinkpad x60, if that helps.

> > root@amd:/sys/class/rtc/rtc0# cat wakealarm 
> > 2051629528
> > root@amd:/sys/class/rtc/rtc0# date +%s
> > 1190285030
> 
> OK, in that situation you've definitely got some buglike behavior.
> My question is:  how to fix it?
> 
> The problem is that the RTC is reporting an alarm value with some
> fields flagged as "wildcard" -- e.g. day/month/year "out of range"
> so the hardware ignores those fields.  This is very common on PC
> based RTCs, and much less common on embedded systems.  (Which for
> some reason don't tend to cheap out on full date specs like PCs.)

I see... so situation is not nice :-(.

> I'm not sure which fix would be best; maybe Alessandro has an
> opinion.

Alessandro?

> Better might be
> 
> 	echo $(( $(cat since_epoch) + 20 )) > wakealarm
> 
> which has no timezone offset issues.

Good. that actually works.

> > root@amd:/sys/class/rtc/rtc0# cat wakealarm 
> > root@amd:/sys/class/rtc/rtc0# 
> > 
> > Also, is there some documentation for wakealarm?
> 
> "git show 3925a5ce44330767f7f0de5c58c6a797009f0f75" has some.

Thanks. Will put it into Doc*/rtc.txt.

> Are you sure it's not working?  Other than the two issues I noted
> above -- borkage w.r.t. ACPI (which wasn't necessarily shown in your
> scripts above), and with wildcarding -- it looked to be correct.

It seems to be working now, not sure what changed.

rtc-sysfs.c: why this?

        if (alarm > now) {
                /* Avoid accidentally clobbering active alarms; we
can't
                 * entirely prevent that here, without even the
minimal
                 * locking from the /dev/rtcN api.
                 */
                retval = rtc_read_alarm(rtc, &alm);
                if (retval < 0)
                        return retval;
                if (alm.enabled)
                        return -EBUSY;

                alm.enabled = 1;

People should not be "accidentally" writing to sysfs files...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/