Project

General

Profile

Bug #9364

Do not set the hardware clock to the system time on shutdown

Added by intrigeri over 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
bugfix/9364-do-not-modify-hardware-clock
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

As discovered when looking into a similar problem on Jessie (#9363), util-linux's hwclock.sh on Wheezy is supposed to set the hardware clock to the system time on shutdown, which contradicts one of our design goals.

And indeed, on Tails 1.3.2 this seems to be confirmed by:

root@amnesia:~# hwclock -r
Sat May  9 13:05:37 2015  -0.469382 seconds
root@amnesia:~# hwclock --set --date="2010-01-01 12:00:00" 
root@amnesia:~# hwclock -r
Fri Jan  1 12:00:04 2010  -0.767842 seconds
root@amnesia:~# date
Sat May  9 13:06:29 UTC 2015
root@amnesia:~# /etc/init.d/hwclock.sh stop
[info] Saving the system clock.
[info] Hardware Clock updated to Sat May  9 13:06:36 UTC 2015.
root@amnesia:~# hwclock -r
Sat May  9 13:06:40 2015  -0.500988 seconds

I didn't check on bare metal whether the time set in the hardware clock survives a reboot yet. I'm pretty sure I did verify that it didn't in the past, but it was surely during Squeeze (or even Lenny) area, so perhaps it was caused by a bug that was fixed in Wheezy.

Sadly, if we tried to fix this by setting HWCLOCKACCESS=no in /etc/default/hwclock, then this would also disable sync'ing system time from the hardware clock on startup, which is not desirable. So, we'll have to patch the initscript's LSB headers so that it's not run at shutdown/reboot time. Not worth improving this in Debian, since that initscript is obsolete in Jessie anyway.


Related issues

Related to Tails - Bug #9363: Disable hwclock-save.service on Jessie Resolved
Related to Tails - Bug #9557: Write regression test for the hardware clock not being saved Resolved 06/10/2015

Associated revisions

Revision 3f0ac507 (diff)
Added by intrigeri over 4 years ago

Disable the hwclock.sh initscript at reboot/shutdown time.

Otherwise it would set the hardware clock to the system time, violating (a
strict interpretation of) our "don't leave traces on the hardware being used"
design goal.

Will-fix: #9364

Revision 3b5fd763
Added by anonym over 4 years ago

Merge remote-tracking branch 'origin/bugfix/9364-do-not-modify-hardware-clock' into stable

Fix-committed: #9364

History

#1 Updated by intrigeri over 4 years ago

  • Status changed from New to Confirmed

#2 Updated by BitingBird over 4 years ago

  • Related to Bug #9363: Disable hwclock-save.service on Jessie added

#3 Updated by BitingBird over 4 years ago

  • Description updated (diff)

#4 Updated by intrigeri over 4 years ago

  • Status changed from Confirmed to In Progress

#5 Updated by intrigeri over 4 years ago

  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/9364-do-not-modify-hardware-clock

#6 Updated by intrigeri over 4 years ago

Next step: build an ISO, run the relevant parts of the automated test suite on it, and test it on bare metal to make sure it indeed improves things, or at least doesn't break anything.

#7 Updated by intrigeri over 4 years ago

  • % Done changed from 10 to 20

Passes features/time_syncing.feature.

#8 Updated by intrigeri over 4 years ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 20 to 30
  • QA Check set to Ready for QA

#9 Updated by anonym over 4 years ago

  • Related to Bug #9557: Write regression test for the hardware clock not being saved added

#10 Updated by anonym over 4 years ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Ready for QA to Info Needed

Did you manage to confirm that without this fix, then the hardware clock is actually set on shutdown? I booted Tails 1.4 in KVM/Qemu, set $CRAZY_TIME_1, hwclock -w, set $CRAZY_TIME_2, reboot. When Tails booted again then hwclock -r (and date of course) still reports $CRAZY_TIME_1, so $CRAZY_TIME_2 was never set at shutdown by hwclock.sh.

#11 Updated by intrigeri over 4 years ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Info Needed to Ready for QA

Did you manage to confirm that without this fix, then the hardware clock is actually set on shutdown?

Nope, as said in my merge request on -dev@ I couldn't easily find an adequate bare metal machine to do that, and I (perhaps wrongly) prioritized submitting this merge request earlier. Note that I didn't want to trust QEMU's hardware clock implementation to test this.

#12 Updated by anonym over 4 years ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Ready for QA to Info Needed

intrigeri wrote:

Note that I didn't want to trust QEMU's hardware clock implementation to test this.

Ok. My test quite clearly indicates that the hardware clock implementation does seem to do what we'd expect of it, i.e. it's kept across a "warm" reboot, at least.

Any way, my tests in Tails 1.4 indicates that even without your fix, we do not save the hardware clock. Indeed, it isn't present anywhere in /etc/rc*.d, and from my reading of live-build's lb_chroot_sysvinit it seems like this should be expected. To be extra sure, I added a sleep 30 (in the top-level) so I definitely would notice if the script was run on shutdown/reboot, but I never noticed such a sleep. As for why the script is started during boot at all, I have no idea. Do you? (I noticed that it's listed as a "TARGET" in /etc/init.d/.depend.boot, whatever that means)

Still I'd like to merge your branch for completeness (and I do not expect a high maintenance burden for the patch, which we'll drop in Jessie any way). What do you think?

(Btw, I remember us looking into this at least twice before years ago (probably on Debian Lenny and Squeeze) and we concluded the same: the hardware clock is never written too. We did get a few reports from users that it did, though, but we could never confirm it (and it might as well be a confusion about UTC vs local timezone).)

#13 Updated by intrigeri over 4 years ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Info Needed to Ready for QA

Any way, my tests in Tails 1.4 indicates that even without your fix, we do not save the hardware clock.

Cool.

As for why the script is started during boot at all, I have no idea. Do you?

No.

Still I'd like to merge your branch for completeness (and I do not expect a high maintenance burden for the patch, which we'll drop in Jessie any way). What do you think?

+1

#14 Updated by anonym over 4 years ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 30 to 100

#15 Updated by anonym over 4 years ago

  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Pass

#16 Updated by intrigeri about 4 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF