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]

Message-ID: <20190625191945.GH5690@piout.net>
Date:   Tue, 25 Jun 2019 21:19:45 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Trent Piepho <tpiepho@...inj.com>
Cc:     "fthain@...egraphics.com.au" <fthain@...egraphics.com.au>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "userm57@...oo.com" <userm57@...oo.com>,
        "linux-kernel@...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 17:16:52+0000, Trent Piepho wrote:
> On Tue, 2019-06-25 at 11:29 +0200, Alexandre Belloni wrote:
> > 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.
> 
> hctosys is very handy in that it sets the system time before any log
> messages are generated.  Either in a main boot or in an initramfs. 
> Having property time-stamped log messages is very important for
> managing a large deployment.
> 
> If the system time is set by some script or systemd unit, then there
> will always be all the things that need to run before that script or
> unit can work.  E.g., udev creating rtc device nodes, mounting /sys and
> /proc, systemd generator for local file system unis, the other parts of
> systemd to do that, etc. All this won't be able to log with correct
> system time.
> 

I'd argue that this system time is not correct anyway and hence is not
that useful. Especially since the boot time to anything reading the RTC
will still be smaller than the maximum error hctosys can have (that is
up to two seconds). This is even worse if the RTC sotres local time.

Instead of using a systemd unit, we could make systemd read the RTC as
soon as possible and set the system time correctly (at least, that is my
plan). This would be especially useful when using NTP because as already
reported, it may take a few hours to actually synchronize because
hctosys didn't set the correct time.

I would agree that there are remaining use cases for hctosys, e.g. when
wanting to boot a rootfs over a network filesystem and without an
initramfs.

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