lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7c015680-01b7-9c3e-c4c7-5d0b6e964781@hygon.cn>
Date:   Sat, 4 Jan 2020 05:44:37 +0000
From:   Jinke Fan <fanjinke@...on.cn>
To:     Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>
CC:     J William Piggott <elseifthen@....com>,
        Karel Zak <kzak@...hat.com>,
        "util-linux@...r.kernel.org" <util-linux@...r.kernel.org>,
        "Linux List Kernel Mailing" <linux-kernel@...r.kernel.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>
Subject: Re: [bugreport] "hwclock -w" reset time instead of setting the right
 time

Hi Mike,
The root cause of the bug you encountered is unclear.

I also tested it at "AMD Ryzen 7 3700X" with mainboard "ASUS ROG STRIX
X570-E GAMING". kernel version are linus 5.5.0-rc4 and fedora
5.5.0-0.rc4.git0.1.fc32.x86_64.

[root@...on  ]# hwclock -v
hwclock from util-linux 2.35-rc1-20-63f8
System Time: 1578110670.568539
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 0 seconds after 1969
Last calibration done at 0 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2020/01/04 04:04:31
Hw clock time : 2020/01/04 04:04:31 = 1578110671 seconds since 1969
Time since last adjustment is 1578110671 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2020-01-04 12:04:30.764426+08:00
[root@...on  ]#
[root@...on  ]# hwclock -w -v
hwclock from util-linux 2.35-rc1-20-63f8
System Time: 1578110696.999848
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 0 seconds after 1969
Last calibration done at 0 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
RTC type: 'rtc_cmos'
Using delay: 0.500000 seconds
1578110697.500000 is close enough to 1578110697.500000 (0.000000 < 0.001000)
Set RTC to 1578110697 (1578110697 + 0; refsystime = 1578110697.000000)
Setting Hardware Clock to 04:04:57 = 1578110697 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Not adjusting drift factor because the --update-drift option was not used.
New /etc/adjtime data:
0.000000 1578110697 0.000000
1578110697
UTC
[root@...on  ]# hwclock -v
hwclock from util-linux 2.35-rc1-20-63f8
System Time: 1578110720.716094
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1578110697 seconds after 1969
Last calibration done at 1578110697 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2020/01/04 04:05:21
Hw clock time : 2020/01/04 04:05:21 = 1578110721 seconds since 1969
Time since last adjustment is 24 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2020-01-04 12:05:20.920803+08:00
[root@...on  ]#
[root@...on  ]# reboot

[root@...on  ]# hwclock -v
hwclock from util-linux 2.35-rc1-20-63f8
System Time: 1578110959.144472
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1578110697 seconds after 1969
Last calibration done at 1578110697 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2020/01/04 04:09:20
Hw clock time : 2020/01/04 04:09:20 = 1578110960 seconds since 1969
Time since last adjustment is 263 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2020-01-04 12:09:19.358191+08:00
[root@...on  ]# dmesg |grep -i rtc
[    0.127226] PM: RTC time: 04:06:59, date: 2020-01-04
[    1.546411] rtc_cmos 00:03: RTC can wake from S4
[    1.546532] rtc_cmos 00:03: registered as rtc0
[    1.546533] rtc_cmos 00:03: alarms up to one month, y3k, 114 bytes 
nvram, hpet irqs
[    1.589157] rtc_cmos 00:03: setting system clock to 
2020-01-04T04:07:01 UTC (1578110821)
[root@...on  ]#

There is no date reset found in the bios after reboot.
The first time during OS startup get date from rtc_cmos is:
[    1.589157] rtc_cmos 00:03: setting system clock to 
2020-01-04T04:07:01 UTC (1578110821)

I watched the video on youtube. The date is reseted when startup into 
bios at Mike's platform.
As we know that the bios will check the validity of rtc time, if not, 
bios will reset the rtc time. RTC time reset may be done by the BIOS.

Whatever I'm so sorry for the issue.

Best regards.
Jinke Fan

On 2020/1/3 22:22, Mikhail Gavrilov wrote:
> On Fri, 3 Jan 2020 at 15:19, Alexandre Belloni
> <alexandre.belloni@...tlin.com> wrote:
>> I'm going to revert 7ad295d5196a58c22abecef62dd4f99e2f86e831, I think
>> this will solve this issue.
>>
> 
> Just checked kernel with reverted commit
> 7ad295d5196a58c22abecef62dd4f99e2f86e831,
> and I can confirm that any time could be successfully set via 'hwclock -w'.
> Thanks, waiting for the patch in master.
> 
> --
> Best Regards,
> Mike Gavrilov.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ