linux-kernel - Re: RTC: Restore alarm after resume

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] [day] [month] [year] [list]

Message-ID: <20150327132222.GC3568@piout.net>
Date:	Fri, 27 Mar 2015 14:22:22 +0100
From:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:	Matthew Garrett <matthew.garrett@...ula.com>
Cc:	a.zummo@...ertech.it, rtc-linux@...glegroups.com,
	linux-kernel@...r.kernel.org
Subject: Re: RTC: Restore alarm after resume

Hi Matthew,

On 22/12/2014 at 19:19:39 +0000, Matthew Garrett wrote :
> Some platform firmware may interfere with the RTC alarm over suspend,
> resulting in the kernel and hardware having different ideas about system state
> but also potentially causing problems with firmware that assumes the OS will
> clean this case up. This patch saves the RTC alarm state on suspend and will
> restore it on resume if the alarm has not yet fired - if it has, it will clear
> the RTC alarm.
> 
> Signed-off-by: Matthew Garrett <matthew.garrett@...ula.com>
> Tested-by: Gabriele Mazzotta <gabriele.mzt@...il.com>
> ---
>  drivers/rtc/class.c | 24 ++++++++++++++++++++++++
>  include/linux/rtc.h |  4 ++++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
> index 472a5ad..c7e09e2 100644
> --- a/drivers/rtc/class.c
> +++ b/drivers/rtc/class.c
> @@ -55,6 +55,8 @@ static int rtc_suspend(struct device *dev)
>  	struct timespec64	delta, delta_delta;
>  	int err;
>  
> +	rtc->valid_alarm = !rtc_read_alarm(rtc, &rtc->alarm);
> +
>  	if (has_persistent_clock())
>  		return 0;
>  
> @@ -102,6 +104,27 @@ static int rtc_resume(struct device *dev)
>  	struct timespec64	sleep_time;
>  	int err;
>  
> +	/*
> +	 * Ensure that the platform hasn't overwritten a pending alarm while
> +	 * suspended
> +	 */
> +	if (rtc->valid_alarm) {
> +		long now, scheduled;
> +
> +		rtc_read_time(rtc, &tm);
> +		rtc_tm_to_time(&rtc->alarm.time, &scheduled);
> +		rtc_tm_to_time(&tm, &now);
> +
> +		/* Clear the alarm registers if it went off during suspend */
> +		if (scheduled <= now) {
> +			rtc_time_to_tm(0, &rtc->alarm.time);
> +			rtc->alarm.enabled = 0;
> +		}
> +
> +		if (rtc->ops && rtc->ops->set_alarm)
> +			rtc->ops->set_alarm(rtc->dev.parent, &rtc->alarm);
> +	}
> +

My main concern here is that reading the time and the alarm can be slow,
in particular with i2c RTC.

Isn't that issue pretty much specific to x86? I know you think otherwise
but I believe this would better be done from your driver. If more
platforms/RTCs are affected, it will still be time to try to solve it in
a more generic way.

Moreover, the class suspend/resume functions are only defined when
CONFIG_RTC_HCTOSYS is set so you may still have broken platforms with
some configurations.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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/