linux-kernel - Re: [PATCH 1/2] rtc-cmos: Clear expired 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4b934eae-d887-343c-c560-72cc6887d368@gmail.com>
Date:   Wed, 31 Aug 2016 17:05:58 +0200
From:   Gabriele Mazzotta <gabriele.mzt@...il.com>
To:     Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>,
        rtc-linux@...glegroups.com,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        matthew.garrett@...ula.com
Subject: Re: [PATCH 1/2] rtc-cmos: Clear expired alarm after resume

On 31/08/2016 01:28, Alexandre Belloni wrote:
> Hi,
> 
> On 25/08/2016 at 16:54:18 +0200, Gabriele Mazzotta wrote :
>> Hi,
>>
>> were you able to verify that no other driver is affect?
>>
> 
> I had a closer look at the issue. I think what is happening is that you
> don't enter the do/while loop in cmos_resume twice. That is supposed to
> handle then clear the RTC_AIE bit and that is why the alarm still seems
> enabled.
> 
> Can you add some tracing there to understand why? It is probably also
> useful to know the value of cmos->suspend_ctrl in cmos_suspend.

cmos->suspend_ctrl is 0x2 when no alarm is set, 0x22 otherwise.
The only way to clear RTC_AIE is to set an alarm and wait for it to
expire while the system is awake.

> My guess is that is_intr(mask) is false and you break out of the loop at
> the first pass, meaning that the RTC_AIE bit is never cleared from
> RTC_CONTROL. That would also mean that your RTC is not setting RTC_AF
> after waking your PC. Am I right?

You are right, is_intr(mask) is false and now I see where the problem is.

I thought cmos_interrupt() was taking care of everything, but I've just
noticed that it's executed only when the system is awake. That's because
cmos->wake_on is not NULL, so enable_irq_wake() is not called.

However, not even rtc_handler() is called, so I guess the BIOS silently
wakes the system when an alarm expires while suspended. This means that
we can't update RTC_CONTROL from rtc_handler() and that we have to do it
from cmos_resume().

There's a problem with this. We don't know whether the system is waking up
because of an alarm or because the user resumed it. In both cases RTC_AIE
is set.

One way to solve this problem is to manually check from cmos_resume() if
any alarm expired while suspended. If we find such an alarm, we don't
break early out of the loop and let it clear the flags.

Is this reasonable?

> Regards,
>