linux-kernel - Re: [PATCH] m68k: Remove read_persistent

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:   Mon, 23 Apr 2018 12:04:59 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Baolin Wang <baolin.wang@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Finn Thain <fthain@...egraphics.com.au>
Subject: Re: [PATCH] m68k: Remove read_persistent_clock()

On 23/04/2018 11:28:38+0200, Arnd Bergmann wrote:
> Some extra background on this:
> 
> read_persistent_clock64/read_persistent_clock is primarily needed when you
> have a real time source that is better than the one exposed in the RTC class
> driver.  For platforms doing suspend/resume, the timekeeping code will
> first try calling read_persistent_clock64() but fall back to the RTC
> if that fails.
> On only a few architectures like m68k, read_persistent_clock64() falls
> back to reading the RTC hardware, which means it will still work even if
> the RTC_DRV_GENERIC driver is not loaded. Removing that code will
> still work correctly as long as the generic RTC driver does get loaded
> before suspend. On platforms without suspend/resume, none of this matters.
> 
> The other user of read_persistent_clock() is to set the initial time at boot.
> This again can be done by the RTC subsystem if the correct RTC driver
> is built-in and CONFIG_RTC_HCTOSYS is set. Alexandre is planning
> to remove that option and instead force early user space to load the
> RTC driver and then sync it manually using the sysfs knob for it.
> 

There is still one use case that could require CONFIG_RTC_HCTOSYS, that's
when the rootfs is on a network fs that requires the time to be roughly
set before being accessed. This could be solved with an initramfs though
(and that initramfs would be required if the RTC driver is a module
anyway).

I still need to check the 'avoid unnecessary fsck runs at boot time'
claim but having the kernel modules and fsck on separate FS seems to be
a very very specific use case to me.

But yes, my plan is at least to get distros to stop enabling it by
default on all their kernels because this led to multiple reports of
systemd entering a loop and this not so nice workaround (still way
better than having each driver have its own version though):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/rtc/hctosys.c?id=b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43

> If you have ancient user space that doesn't do this, you might still
> rely on read_persistent_clock() to set the boot time.
> 

Last time I checked a default debian install on x86 would set the system
time 2 times from the kernel and then 2 times from userspace.

I'm pretty sure we could do without read_persistent_clock and
CONFIG_RTC_HCTOSYS and let userspace handle system time. For example, on
ARM, only omap and tegra are defining a read_persistent_clock callback.
All the other platforms are just working fine without it. As you pointed
out on IRC a while ago, s390 seems to be the only user where this is
actually useful.

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com