linux-kernel - Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't

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, 25 Jun 2019 11:29:26 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Finn Thain <fthain@...egraphics.com.au>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>, userm57@...oo.com,
        linux-rtc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it
 doesn't

On 25/06/2019 11:53:49+1000, Finn Thain wrote:
> On Mon, 24 Jun 2019, Alexandre Belloni wrote:
> 
> > On 21/06/2019 11:51:26+1000, Finn Thain wrote:
> > > Some machines store local time in the Real Time Clock. The hard-coded 
> > > "UTC" string is wrong on those machines so just omit that string. 
> > > Update the log parser so it doesn't require the string "UTC".
> > > 
> > 
> > I don't agree, hctossys will always think the RTC is in UTC.
> 
> Well, I wasn't speculating about a theoretical problem. This is a bug that 
> was reported to me by a user of Debian/powerpc system.
> 
> I was able to confirm that the bug also affects dual-boot Windows/Linux on 
> x86 with CONFIG_RTC_HCTOSYS=y.
> 
> > If you store local time in the RTC, then you are probably not using 
> > hctosys because it definitively doesn't know about the timezone and will 
> > incorrectly set the system time. That information is usually kept in 
> > /etc/adjtime.
> > 
> 
> In the Debian/powerpc bug report, the timezone is obtained from the NVRAM:
> 
> [    0.000000] PowerMac motherboard: PowerBook Wallstreet
> ...
> [    0.000000] GMT Delta read from XPRAM: -360 minutes, DST: on
> ...
> [   37.605859] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
> ...
> [   40.346255] rtc-generic rtc-generic: setting system clock to 2019-06-19 15:17:35 UTC (1560957455)
> ...
> 
> Though I don't know whether the sys_tz value is relevant here.
> 
> Anyway, here's the bug reproduced on x86 --
> 
> # dmesg | grep rtc_cmos
> [    0.543878] rtc_cmos 00:02: RTC can wake from S4
> [    0.544090] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> [    0.544090] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
> [    0.545807] rtc_cmos 00:02: setting system clock to 2019-06-25 11:24:14 UTC (1561461854)
> # grep . /etc/adjtime /etc/timezone
> /etc/adjtime:0.000120 1550184138 0.000000
> /etc/adjtime:1550184138
> /etc/adjtime:LOCAL
> /etc/timezone:Australia/Melbourne
> # hwclock --show
> 2019-06-25 11:47:49.702660+10:00
> # date --iso-8601=s
> 2019-06-25T11:48:01+10:00
> # 
> 
> Looks wrong to me. What am I missing?
> 

Userspace is certainly adjusting the timezone after the kernel did. Can
you run the same commands without running your init? 

On stable, you have /etc/init.d/hwclock.sh that still runs and does the
correct thing. My understanding is that systemd also handles the TZ
properly after hctosys (see clock_is_localtime()).

Seriously, hctosys does a really bad job at setting the system time, it
is guaranteed to be always wrong on most platforms. My plan is still to
try to get distros to stop enabling it and do that properly in
userspace. This is already ok when using sysV but systemd would need a
few changes to stop relying on it when then is no hwclock initscript.
Unfortunately, I didn't have time to work on that yet.



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