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.ro...@gmail.com -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.