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
| ||
|
Date: Tue, 29 Apr 2008 12:12:40 -0700 From: David Brownell <david-b@...bell.net> To: Uwe Kleine-König <Uwe.Kleine-Koenig@...i.com> Cc: Alessandro Zummo <a.zummo@...ertech.it>, linux-kernel@...r.kernel.org Subject: Re: rtc: how should I handle an invalid state? On Tuesday 29 April 2008, Uwe Kleine-König wrote: > The problem is that hwclock tries to read the current time before > setting the new one. And if that fails, it doesn't update the rtc. Which version of hwclock? That does seem like a bug in that particular version. If it's in util-linux-ng or busybox, please send in a patch. I don't think anyone should be deploying *new* systems using *old/unmaintained* util-linux. I'll suspect this is on some util-linux version, since I'm quite sure that I've had busybox based systems that don't show this misbehavior. Haven't had occasion to use non-PC RTCs with a util-linux-ng version; I wouldn't call a bug in such combinations a kernel regression, either... I think the preferred solution never returns invalid times as valid. Some RTC drivers do this themselves: int my_rtc_read_time(struct device *dev, struct rtc_time *time) { ... read the hardware into *time ... return rtc_valid_tm(time); } Or rtc_valid_tm() might be checked in the RTC framework glue, to provide more uniform behavior at the framework level. Either way, it's not unknown that an un-initialized RTC have undefined state, and thus return invalid times until they've been set (using wall clock, NTP, or whatever). - Dave -- 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/
Powered by blists - more mailing lists