linux-kernel - Re: [PATCH 0/7] rtc: Add support for limited alarm timer offsets

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: <20230816150353137debc5@mail.local>
Date:   Wed, 16 Aug 2023 17:03:53 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>,
        Benson Leung <bleung@...omium.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        John Stultz <jstultz@...gle.com>,
        Stephen Boyd <sboyd@...nel.org>, linux-rtc@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Brian Norris <briannorris@...omium.org>
Subject: Re: [PATCH 0/7] rtc: Add support for limited alarm timer offsets

Hello,

On 16/08/2023 06:39:29-0700, Guenter Roeck wrote:
> Some alarm timers are based on time offsets, not on absolute times.
> In some situations, the amount of time that can be scheduled in the
> future is limited. This may result in a refusal to suspend the system,
> causing substantial battery drain.
> 
> This problem was previously observed on a Chromebook using the cros_ec
> rtc driver. EC variants on some older Chromebooks only support 24 hours
> of alarm time in the future. To work around the problem on affected
> Chromebooks, code to limit the maximum alarm time was added to the cros_ec
> rtc driver with commit f27efee66370 ("rtc: cros-ec: Limit RTC alarm range
> if needed"). The problem is now seen again on a system using the cmos
> RTC driver on hardware limited to 24 hours of alarm time, so a more
> generic solution is needed.
> 
> Some RTC drivers remedy the situation by setting the alarm time to the
> maximum supported time if a request for an out-of-range timeout is made.
> This is not really desirable since it may result in unexpected early
> wakeups. It would be even more undesirable to change the behavior
> of existing widely used drivers such as the cmos RTC driver.
> 
> The existing range_max variable in struct rtc_device can not be used
> to determine the maximum time offset supported by an rtc chip since
> it describes the maximum absolute time supported by the chip, not the
> maximum time offset that can be set for alarms.
> 
> To reduce the impact of this problem, introduce a new variable
> rtc_time_offset in struct rtc_device to let RTC drivers report the maximum
> supported alarm time offset. The code setting alarm timers can then
> decide if it wants to reject setting alarm timers to a larger value, if it
> wants to implement recurring alarms until the actually requested alarm
> time is met, or if it wants to accept the limited alarm time. Use the new
> variable to limit the alarm timer range.
> 
> The series is intended to solve the problem with minimal changes in the
> rtc core and in affected drivers.
> 
> An alternative I had considered was to have the alarmtimer code guess the
> maximum timeout supported by the rtc hardware. I discarded it as less
> desirable since it had to retry repeatedly depending on rtc limitations.
> This often resulted in error messages by the rtc driver.  On top of that,
> it was all but impossible to support rtc chips such as tps6586x which
> can only support wake alarms up to 16,383 seconds in the future.
> 
> The first patch of the series adds support for providing the maximum
> supported time offset to the rtc core. The second patch uses that value
> in the alarmtimer code to set the maximum wake-up time from system suspend.
> Subsequent patches add support for reporting the maximum alarm timer offset
> to a subset of affected drivers.
> 
> Previous discussion:
>     https://lore.kernel.org/lkml/Y19AdIntJZGnBh%2Fy@google.com/T/#mc06d206d5bdb77c613712148818934b4f5640de5
> 

I'm fine with the series, however, this doesn't solve the issue for RTCs
that have an absolute limit on the alarm (as opposed to an offset to the
current time/date).



> ----------------------------------------------------------------
> Guenter Roeck (7):
>       rtc: Add support for limited alarm timer offsets
>       rtc: alarmtimer: Use maximum alarm time offset
>       rtc: cros-ec: Detect and report supported alarm window size
>       rtc: cmos: Report supported alarm limit to rtc infrastructure
>       rtc: tps6586x: Report maximum alarm limit to rtc core
>       rtc: ds1305: Report maximum alarm limit to rtc core
>       rtc: rzn1: Report maximum alarm limit to rtc core
> 
>  drivers/rtc/rtc-cmos.c     | 11 +++++++++++
>  drivers/rtc/rtc-cros-ec.c  | 38 +++++++++++++++++++++++---------------
>  drivers/rtc/rtc-ds1305.c   |  3 ++-
>  drivers/rtc/rtc-rzn1.c     |  1 +
>  drivers/rtc/rtc-tps6586x.c |  1 +
>  include/linux/rtc.h        |  1 +
>  kernel/time/alarmtimer.c   | 13 +++++++++++++
>  7 files changed, 52 insertions(+), 16 deletions(-)

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com