Bug#819019: fake-hwclock: allow the saved time to go backwards under normal use

[Roddy Shuler]

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.

--

............................................................................

Roddy Shuler  |  +1.585.530.7960  |  Endless

[Roddy Shuler]

Following up, another important use case (which turned out to be what caused problems for us in the first case)...  At least with some hardware implementations, upon disconnecting and reconnecting the battery, the hardware clock is initialized to a random date/time, which can easily be years in the future.  Again, once in this state, the fake-hwclock can never be set back properly under normal usage, and thus overrides the real hwclock on every future boot.

[Steve McIntyre]

[ Including a CC to Robie from the previous bug #763589... ]

Hey guys,

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

[Roddy Shuler]

> 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?

That sounds like a good policy in general, and it would solve my concerns.  Thanks!

[Robie Basak]

On Fri, Apr 08, 2016 at 06:49:35PM +0100, Steve McIntyre wrote:
> 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.

Could you leave something in /run that notes that load has been called?
Or is /run not available at the right time for that?

> 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?

That would work for my use case, I think. Since in my failure case the
time ends up right back near the epoch and nowhere near the present
time.

Robie

[Steve McIntyre]

I'd rather go this way than the /run route, for simplicity. About to
add this in a new release.

--
Steve McIntyre, Cambridge, UK. st...@einval.com

"Arguing that you don't care about the right to privacy because you have
nothing to hide is no different than saying you don't care about free
speech because you have nothing to say."
-- Edward Snowden