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:   Wed, 17 May 2017 14:42:24 +0000
From:   "Mirea, Bogdan-Stefan" <Bogdan-Stefan_Mirea@...tor.com>
To:     Sascha Hauer <s.hauer@...gutronix.de>
CC:     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>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: RE: [PATCH v2] Added "Preserve Boot Time Support"

Hello Sascha,

On Wednesday, May 17, 2017 2:30 PM Sascha Hauer wrote:
> As John already said, there's the read_boot_clock64() interface which
> should be used here.
> By using the read_boot_clock64() interface you can make sure that you
> only provide the functionality when it's actually supposed to work.
The read_boot_clock64() function is called from timekeeping_init().
The arm arch timer init callback arch_timer_of_init() function is called
from time_init() function.
We will have an uninitialized arm arch timer (this is our only timer
source) at the read_boot_clock64() function call since both
timekeeping_init() and time_init() functions are called from
start_kernel() in the following order:
    asmlinkage __visible void __init start_kernel(void)
    {
        /* ... */
        timekeeping_init();
        time_init();
        /* ... */
    }
So in our case, we cannot use a read_boot_clock64() function to read cyc
value.


> In your patch you provide a generic option (BOOT_TIME_PRESERVE) which
> only works as expected in some special cases. You assume that the
> bootloader has started the same timer with the same frequency as Linux
> does.
Yes, I assume that the bootloader and Linux use and configure the same
timer at the same frequency. This is a must since we want to measure the
exact boottime. The reason the code is guarded with BOOT_TIME_PRESERVE
is because we want to avoid situations like the one you described.


> Also you assume that the timer startup code doesn't reset the
> timer. When these assumptions are not true then you just get bogus
> random timing information.
If the timer initialization code will reset the timer, the Linux system
will work exactly as before, showing boottime 0 in kmsg and 0 in
uptime, so no bugs/crashes will occur.

Kind Regards,
Bogdan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ