linux-kernel - RE: [PATCH v2] Added "Preserve Boot Time Support"

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]

Date:   Thu, 4 May 2017 10:54:41 +0000
From:   "Mirea, Bogdan-Stefan" <Bogdan-Stefan_Mirea@...tor.com>
To:     Oleksij Rempel <ore@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "john.stultz@...aro.org" <john.stultz@...aro.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>
CC:     "kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: RE: [PATCH v2] Added "Preserve Boot Time Support"

Hi Oleksij,

On Thursday, May 04, 2017 12:27 PM, Oleksij Rempel wrote:
> Hi Bogdan,
>
> are there any example what and how bootloader should do to provide
> correct values?

I will give you an example with a real behavior on Renesas RCAR Gen3
Salvator-x:

We have an ARM64 SOC with the following boot stages:
ARM Trusted Firmware BL2 -> ARM Trusted Firmware BL31 -> U-Boot -> Linux

[First]
On ARM Trusted Firmware BL31 "programs the CNTFRQ_EL0 register with the
clock frequency of the system counter, which is provided by the
platform"(Aarch64 Bl31 documentation [1]). And after this step the timer
is up and running so every timer cycle is counted in the CCNT register.

[Step A]
After this step BL31 will load and start execution of U-Boot(BL33). In
U-Boot we will spend for example 4 seconds and then load and start
execution of Linux Kernel.

[Step B]
Linux Kernel starts and after kernel timer is initiallized the
sched_clock_register will be called.

[Step C]
Testing with "$: uptime > /dev/kmsg"

Test 1: Testing with default kernel (no patch added)
Log will be:
[Step A]
[    0.165573]
[    0.167127] U-Boot 2015.04 (Apr 06 2017 - 12:28:41)
...
[    4.364556]
[    4.366065] Starting kernel ...

[Step B]
...
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
max_cycles: 0x1ec02923e, max_idle_ns: 440795202125 ns
[    0.000003] sched_clock: 56 bits at 8MHz, resolution 120ns, wraps
every 2199023255496ns
[    0.000214] Console: colour dummy device 80x25
[    0.000594] console [tty0] enabled
...
[Step C]
$ uptime  > /dev/kmsg
[   9.148458]  00:00:09 up 0 min,  load average: 0.00, 0.00, 0.00

There is no inconsistency between kmsg and uptime, but from [Step B] we
observe that the time spent before kernel start is not added.

Test 2: Testing only with preserve boot time "kernel/time/sched_clock" 
modifications:
Log will be:
[Step A]
[    0.164567]
[    0.166122] U-Boot 2015.04 (Apr 06 2017 - 12:28:41)
...
[    4.357793]
[    4.359301] Starting kernel ...

[Step B]
...
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
max_cycles: 0x1ec02923e, max_idle_ns: 440795202125 ns
[    4.641512] sched_clock: 56 bits at 8MHz, resolution 120ns, wraps
every 2199023255496ns
[    4.641724] Console: colour dummy device 80x25
[    4.642105] console [tty0] enabled
...

[Step C]
uptime  > /dev/kmsg
[   13.933217]  00:00:09 up 0 min,  load average: 0.00, 0.00, 0.00

We can see that the preserve boottime changes in
"kernel/time/sched_clock" updates the kmsg time [Step B], but there is
an inconsistency between kmsg time and uptime since uptime is not
updated accordingly to the timer's CCNT value [Step C]. The uptime
starts from 0, and dt~=4sec inconsistency between kmsg and uptime is
observable.

Test 3: Testing with the full preserve boot time support with
"kernel/time/sched_clock" and "drivers/clocksource/arm_arch_timer":
Log will be:
[Step A]
[    0.164564]
[    0.166119] U-Boot 2015.04 (Apr 06 2017 - 12:28:41)
...
[    4.357751]
[    4.359259] Starting kernel ...
[Step B]
...
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
max_cycles: 0x1ec02923e, max_idle_ns: 440795202125 ns
[    4.638667] sched_clock: 56 bits at 8MHz, resolution 120ns, wraps
every 2199023255496ns
[    4.638884] Console: colour dummy device 80x25
[    4.639265] console [tty0] enabled
...

[Step C]
$ uptime > /dev/kmsg
[   17.728591]  00:00:17 up 0 min,  load average: 0.00, 0.00, 0.00

We can observe that the patch updates kmsg time with the time spent
before kernel starts [Step B]("kernel/time/sched_clock") and also
updates kernel uptime("drivers/clocksource/arm_arch_timer") in [Step C]
no inconsistency being present between kmsg and uptime.

Best Regards,
Bogdan
[1]
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/firmware-design.md