linux-kernel - Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

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:	Fri, 4 Dec 2015 16:25:58 -0800
From:	Julius Werner <jwerner@...omium.org>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Julius Werner <jwerner@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Sonny Rao <sonnyrao@...omium.org>,
	Chris Zhong <zyw@...k-chips.com>,
	Heiko Stuebner <heiko@...ech.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	rtc-linux@...glegroups.com
Subject: Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st

> If a device is in S3 for the whole day that the glitch occurs and then
> we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd,
> right?  That case _could_ be handled by knowing that the last time we
> read the clock it was before 12/1 and that this time it is after
> 11/30.  Then we add the extra day.  In order to do this, we'd have to
> know that we're on hardware with the glitch, which I guess could
> either be done with a device tree property or by spending 1 second
> probing the device at bootup (that would be a bit of a pain...).
>
> Obviously the trick above wouldn't handle if the clock ticked when the
> device was in S5, but I'd imagine that most systems treat the RTC as
> slightly questionable on an initial bootup anyway (though I'd imagine
> that they rely on it working across S3).

True, we could do that. I don't think it makes much sense to
differentiate between S3 and S5 like that, though... the problem can
happen just the same after both, and I don't think there's a practical
difference in how systems treat that (if userspace has ways to
double-check the system time, such as syncing to a network time
source, it should really be doing that after both resume and reboot).
Of course, building a work-around like that for S5 will become more
complicated and requires persistent storage.

For Chromium OS, we're already planning to improve tlsdated such that
I don't think this will be an issue anymore (making it schedule a
resync after resume, not just after reboot, which is a probably a good
idea in general). For other systems that don't have any kind of
network time sync, I think the best solution would be to handle this
completely with a small userspace hook on boot and resume (because you
probably need to access the file system to keep track of the last seen
time anyway, you can do the device identification through
/proc/device-tree just as well, and this avoids putting too much hacky
workaround logic into the kernel).

The other thing that would worry me about this approach is that it
requires perfect identification of the problem, and Rockchip will
hopefully eventually be able to fix this either in RK808 or a
successor chip that might use the same RTC interface (and thus
driver). Detecting it at boot is probably a bad idea because a
crash/brownout at the wrong moment will permanently leave you with a
bad time. I really think fixing this as best as we easily can and
leaving the hard edge-cases to userspace is the best approach here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/