Re: [chrony-users] Resume from suspend and default makestep configuration

[Pali Rohár <pali.rohar@xxxxxxxxx>]

On Tuesday 19 May 2020 17:36:15 Miroslav Lichvar wrote:
> On Tue, May 19, 2020 at 03:11:42PM +0200, Pali Rohár wrote:
> > Also when resuming from hibernation you may have been completely powered
> > off and also memory of system may have been modified. Plus multiOS
> > scenario may have applied, e.g. ordinary user just "booted" windows and
> > then turned it off and resumed linux from hibernation. I guess we would
> > agree that ordinary user does not use any virtualisation as you
> > described below.
> 
> I don't think that's a common practice. If you suspend an OS and boot
> another, all kind of things can break, like corrupted swaps, etc. If
> you know what you are doing, fine, but don't be surprised when things
> break.

I know that lot of people are doing it. They are not developers,
sysadmins or people who watch mailing list, ... just normal users.
So from my observation, this is common. Maybe it is less common by
developers who know what can happen and break, but not uncommon by
ordinary non-power users.

When hibernating windows it puts special signature on NTFS filesystems
and Linux's ntfs-fuse refuse to mount in R/W mode such "hibernated" NTFS
filesystem. So there is no corruption of hibernated windows state.

Windows does not support accessing ext4, btrfs or linux swap so there is
corruption of linux fs/swap from windows.

> When chronyd is running, it assumes it has full control over the
> system clock. When you suspend and resume the OS or machine, the
> system clock is reset to the RTC. chronyd can see there was a forward
> jump, but it doesn't know what happened. systemd should know that and
> there could be a unit to call the chronyc reset and makestep commands
> if a significant offset is expected.

But systemd cannot know that. It is chronyd who see that significant
jump occurred and only after it synchronize time via NTP. And until NTP
daemon tell (somehow) hat this jumps occurred, systemd cannot know that
during hibernation RTC clock was modified.

This looks like a chicken and egg problem. systemd (or any other init /
service system) does not know correct time after resuming system from
suspend/hibernate, so it cannot check if RTC jump occurred. chronyd is
waiting for some reset command from systemd to fix insecure system
clock but systemd does not know that clock is incorrect... So the result
it that system clock is incorrectly set, user has incorrect time.

-- 
Pali Rohár
pali.rohar@xxxxxxxxx

-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.