linux-kernel - Re: battery switch-over detection on pcf2127

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]

Date:   Tue, 5 May 2020 23:01:19 +0200
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Bruno Thomsen <bruno.thomsen@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc:     Per Nørgaard Christensen 
        <per.christensen@...vas.dk>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: battery switch-over detection on pcf2127

On 05/05/2020 22.38, Bruno Thomsen wrote:
> Hi Rasmus
> 
> Den tir. 5. maj 2020 kl. 22.07 skrev Alexandre Belloni
> <alexandre.belloni@...tlin.com>:
>>
>> On 05/05/2020 21:54:47+0200, Rasmus Villemoes wrote:
>>> Hi Bruno
>>>
>>> I just noticed your "rtc: pcf2127: add tamper detection support"
>>> (03623b4b04) from 5.4. Unfortunately, clearing the BTSE bit breaks a use
>>> case of ours:
>>>
>>> We rely on the battery switch-over detection to distinguish a powerfail
>>> during boot from a PORESET by the external watchdog (in the latter case,
>>> the RTC is still powered throughout, meaning there is no battery
>>> switch-over event). OTOH, we do not use the tamper detection - in fact,
>>> the TS signal is unconnected on our board.
>>>
>>> We're currently still on 4.19, but we will eventually upgrade to a
>>> kernel containing the above commit. So I was wondering if we could
>>> figure out a way that would work for both of us - either some CONFIG
>>> knob, or perhaps something in the device-tree. Any ideas?
>>>
>>
>> Yes, I was working on a patch series last week allowing to read BF. I'm
>> not sure clearing BTSE is your issue but clearing BF is.
>>
>> I'm going to send it tonight, I'll copy you, let me now if that works
>> for you. You can then read BF using the RTC_VL_READ ioctl. The
>> RTC_VL_BACKUP_SWITCH flag will be set if a switchover happened.
>> The RTC_VL_CLR ioctl can be used to clear the flag.
>>
>> I think clearing BTSE is still the right thing to do.
> 
> I think your use case is valid and it sounds like Alexandre solution will
> solve it as you just need to know if a battery switch-over has happened
> not when exactly it happened.
> 
> I can help test the patches too.

Thanks for the quick replies, both. Unfortunately, being able to read BF
from linux is not relevant to us - all the handling happens early in the
bootloader (including clearing BF, so that we can detect that the
previous boot failed only because of power fail - hence whether the
linux driver clears BF or not is not relevant). We really just want
linux to not touch the bits in CTRL3 at all.

Hm, wait. Re-reading the above suggests that BF can get set even if BTSE
is not, and a quick experiment shows that is true - I must have misread
the data sheet. While I think that's fine for now (currently I only
print the time of last switch-over as a diagnostic), I did have some use
case in mind for comparing that timestamp to the current time and make
decisions based on that. But until I figure out exactly what I want to
use it for, and until we actually upgrade to 5.4+, there's no rush.

Thanks,
Rasmus