netdev - Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

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: <20170621123535.b5fvwlydfhnhuqll@piout.net>
Date:   Wed, 21 Jun 2017 14:35:35 +0200
From:   Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Baruch Siach <baruch@...s.co.il>,
        "patches@...nsource.wolfsonmicro.com" 
        <patches@...nsource.wolfsonmicro.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        "x86@...nel.org" <x86@...nel.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Chen-Yu Tsai <wens@...e.org>, Ingo Molnar <mingo@...hat.com>,
        Sylvain Lemieux <slemieux.tyco@...il.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Len Brown <len.brown@...el.com>,
        "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
        Jason Cooper <jason@...edaemon.net>,
        "rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Hans Ulli Kroll <ulli.kroll@...glemail.com>,
        "adi-buildroot-devel@...ts.sourceforge.net" 
        <adi-buildroot-devel@...ts.sourceforge.net>,
        Vladimir Zapolskiy <vz@...ia.com>,
        John Stultz <john.stultz@...aro.org>,
        Gregory Clement <gregory.clement@...e-electrons.com>,
        Michael Chan <michael.chan@...adcom.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Barry Song <baohua@...nel.org>,
        Support Opensource <Support.Opensource@...semi.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Steve Twiss <stwiss.opensource@...semi.com>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

On 21/06/2017 at 08:34:43 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > > > platform can pass 2038 properly.
> > > > 
> > > > Yes, but there are still quite some issues to solve there:
> > > > 
> > > >      1) How do you tell the system that it should apply the offset in the
> > > >      	first place, i.e at boot time before NTP or any other mechanism can
> > > >      	correct it?
> > > 
> > > I'd not do offset. Instead, I'd select a threshold (perhaps year of
> > > release of given kernel?) and
> > > 
> > > 	if (rtc_time < year_of_release_of_kernel)
> > > 	   rtc_time += 0x100000000;
> > > 
> > > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> > > seen in some drivers.
> > > 
> > > >      2) Deal with creative vendors who have their own idea about the 'start
> > > >      	of the epoch'
> > > 
> > > If someone uses different threshold, well, there will be
> > > confusion. But only for users that have their rtc set to the past,
> > > which is quite unusual.
> > > 
> > 
> > Or not, having an RTC set in the past is actually quite common. I'd find
> > it weird to have a new device boot and be set to a date in the future.
> 
> ...but still better than board stuck in the past, no?
> 
> > Also note that the threshold or offset thing may seem like a good idea
> > but fails with many RTCs because of how they handle leap years.
> 
> Well, you can still convert time from rtc to unix time, then do adjustment
> there.
> 

You can only if your machine is running when that happens. If that is
not the case, then you lost and your time is not correct anymore.

There is currently one rtc doing that kind of trick but it is used as a
simple time counter from the beginning. Transitioning is the difficult
part.

> Anyway, I guess it would be cool for rtc drivers to annotate what limits
> underlying storage has to the common code, so that we can do fixups once
> per class, not once per driver.

Yes, I'm in the middle of the whole rework that allows that.

I don't understand the sudden urgency of fixing that and the amount of
bikeshedding, seeing that the closest cutoff date is actually 31st of
december 2069 in the rtc subsystem and that anyway the current 32bit
userspace will explode in february 2038.

My plan from the beginning was to have something for the next stable. I
know nobody can read my mind but again, I don't think there is currently
any urgency to change anything.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com