linux-kernel - Re: [PATCH] rtc: pcf-8563: Report previously detected low-voltage via RTC_VL_BACKUP

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]

Date:   Tue, 11 Jul 2023 22:54:39 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Jan Kiszka <jan.kiszka@...mens.com>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>, linux-rtc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rtc: pcf-8563: Report previously detected low-voltage
 via RTC_VL_BACKUP_LOW

On 11/07/2023 09:27:14+0200, Jan Kiszka wrote:
> >>> Nope, that could be easily avoided in software. The actual problem is
> >>> that the VL bit is not settable (clear-on-write). And that means we
> >>> can't do anything about losing the low battery information across
> >>> reboots - but that's no difference to the situation with the existing
> >>> driver.
> >>>
> >>> There is no "fix" for userspace as there is no standard framework to
> >>> read-out the status early and retrieve it from there when the user asks
> >>> for it. That's best done in the kernel.
> >>
> >> That's not true, nothing prevents userspace from reading the battery
> >> status before setting the time and destroying the information which is
> >> exactly what you should be doing.
> > 
> > What is your "userspace"? Mine is stock Debian with systemd and
> > timesyncd enabled. But there is no framework to read the status early
> > enough and propagate that after timesyncd did its job. Any concrete
> > suggestion to "fix" userspace?
> > 
> 
> Ping - I still have seen no suggestion to improve this situation otherwise.
> 

You can get systemd or any daemon to read the rtc flag before systemd
decides to use NTP and set the time, destroying the information.

This is a systemd issue, not a kernel issue. I already have to handle
two other issues caused by systemd because they don't want to budge, I
will not take a third one.


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