linux-kernel - Re: [rtc-linux] [PATCH 04/10] RTC: Cleanup rtc_class_ops->read

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: <1298362178.4222.57.camel@work-vm>
Date:	Tue, 22 Feb 2011 00:09:38 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	rtc-linux@...glegroups.com, LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Marcelo Roberto Jimenez <mroberto@...i.cetuc.puc-rio.br>
Subject: Re: [rtc-linux] [PATCH 04/10] RTC: Cleanup
 rtc_class_ops->read_alarm()

On Mon, 2011-02-21 at 18:55 -0800, John Stultz wrote:
> On Tue, 2011-02-22 at 02:34 +0000, Mark Brown wrote:
> > Can you go into more detail on the rationale behind this virtualised
> > functionality and how it works?  I'd really expect the RTC alarm to be
> > preserved over system reboots (on some systems it can be used to
> > initiate a boot) and that would mean that we need to go to the hardware
> > for at least the initial configuration.
[snip]
> Now, to your point about persistence across reboots:
> 
> It is an interesting point to consider. 
> 
> So currently, if the hardware supports it, then the behavior should
> remain the same: As long as no application sets a new alarm, the
> previous alarm should persist in the RTC hardware.
> 
> However, an application's ability to notice that such an alarm is set,
> is currently limited.  So your point about reading the hardware to
> initialize the state is quite valid, and shows a good reason to preserve
> the read_alarm() method. 

So I've been working on a fix for the issue described here, but have run
into a few complications:

1) Prior to my rework landing, on the rtc-cmos driver, after a reboot,
calls to rtc_read_alarm() do return the alarm time from hardware.
However, the AIE mode bit is off (even if it was left on). So the alarm
does not seem like it would persist across reboots, and the value
returned form rtc_read_alarm is technically invalid as the code to fill
in the -1 fields doesn't run.

I realize that the cmos is fairly simplistic, but do you have examples
of hardware where the AIE mode does persist on bootup?

2) One larger complication I see coming down the road with this is how
do we handle persistence with multiplexed events? If we have two
rtc_timers set to fire, one at 1pm and the other at 3pm. If we reboot
the box at noon, only the 1pm timer will persist. 

This could cause some additional confusion if the first timer was a
posix-alarm-timer and the second was the classic wake alarm set
by /dev/rtc0. In that case, after a reboot at noon, the system will show
a 1pm wake alarm via /dev/rtc0.

I need to think more about #2. I suspect we could claim that soonest
alarm should be preserved regardless of what its source was.

Just so I can better get a grip of the cases your considering, could you
maybe give me some more detailed examples of where you'd like to see the
alarm timer be set and then persist across multiple power cycles before
firing? And how is that persistent value managed by the application
setting it?

thanks
-john

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