[ Including a CC to Robie from the previous bug #763589... ] Hey guys,
On Tue, Mar 22, 2016 at 11:37:56PM +0000, Roddy Shuler wrote: >Package: fake-hwclock >Version: 0.10 > >On bug #763589, protection was added around the save operation so that the >saved time cannot go backwards without forcing. While this clearly >mitigates the race condition of concern, I don't believe it is an >acceptable solution for normal users. > >Consider the following use case... > >1. The user accidentally sets a wrong time to a date in the future -- for >example, sets the year to 2017 rather than 2016 >2. The fake-hwclock.data file is written with the future time >3. The user then realizes the mistake, and tries to fix the time back to >the year 2016 >4. Now, the cron job and service will not update the fake-hwclock.data, >since it appears that the current system time is in the past (relative to >the invalid saved time) >5. On reboot, the clock reverts to the future date in the year 2017, and >continues to do so on every reboot for the next year (unless the user is >advanced enough to know to manually run the script with the force flag) > >Other than races on startup, the normal case is that the system time will >not go backwards unless it was intentionally changed (either by a user or >by an update from an NTP server), so I don't believe it makes sense to >reject such saves by default. (The protection for loads, on the other >hand, is clearly needed.) > >For my specific use case, I simply reverted to the original behavior >without any protection against saving, but I suppose the upstream solution >would require an alternate solution to the race reported on #763589. Right. And in #763589 we have: >I've observed a system with a correctly working fake-hwclock >(originally initalised by NTP) set its time back to shortly after the >epoch, including in /etc/fake-hwclock.data. > >I believe this happened because "fake-hwclock save" was called after >boot before "fake-hwclock load" was called. > >I think this happens in the case of a very early shutdown event that >calls "/etc/init.d/rc 0" before "/etc/init.d/rcS" has completed. > >In my case, I have a Raspberry Pi rigged with an external shutdown >signal hooked up via udev. If the signal is "high" at boot time, then >the Pi shuts down without fully booting up. > >I'm not entirely sure that this is the cause, but the race is there. We have two conflicting requirements here, I think. Thanks for explaining your logic, both of you. The problem is that I don't think there's a good solution to both problems here. We can't *know* that the system time has been read from fake-hwclock.data before calling "save". I briefly considered adding a "I've seen this" flag that could be set in "load", but that's no guarantee at all - if we power down unexpectedly then it'll be set already at next boot. What we *can* do is instead add an extra declaration of system time based on the build/release date of the particular version of the fake-hwclock package in use, and refuse to back to a date before *that* unless --force is used. How does that sound? Or can you think of any other possible fixes here? [ I've also just realised that I'll need to go back and re-add initramfs support now that we automatically attempt to mount and fsck /usr in the initramfs. Joy \o/ ] -- Steve McIntyre, Cambridge, UK. st...@einval.com "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds
