linux-kernel - RE: [PATCH v3] 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]

Message-ID: <1136356b7bf043aaae4982ee7865bbe2@svr-ies-mbx-01.mgc.mentorg.com>
Date:   Wed, 24 May 2017 09:35:46 +0000
From:   "Mirea, Bogdan-Stefan" <Bogdan-Stefan_Mirea@...tor.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "john.stultz@...aro.org" <john.stultz@...aro.org>,
        "ore@...gutronix.de" <ore@...gutronix.de>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: RE: [PATCH v3] Added "Preserve Boot Time Support"

On Tuesday, May 23, 2017 7:39 PM, Thomas Gleixner wrote:
> On Tue, 23 May 2017, Mirea, Bogdan-Stefan wrote:
> > On Monday, May 22, 2017 12:36 AM, Thomas Gleixner wrote:
> > > On Fri, 19 May 2017, Bogdan Mirea wrote:
> > > This adds a arch_timer specific command line option. Why is this
> > > arch_timer
> > > specific? So if any other platform wants to gain this feature then we
> > > end
> > > up copying that mess to every single timer implementation? Certainly
> > > NOT!
> > > Exactly nothing. settimeofday() modifies CLOCK_REALTIME and if the
> > > platform
> > > has an early accessible RTC, you hereby wreckaged wall_time. If the
> > > RTC
> > > readout comes later then CLOCK_REALTIME is overwritten. So what is
> > > this
> > > supposed to do?
> > >
> > > It has absolutely nothing to do with CLOCK_BOOTTIME. /proc/uptime is
> > > based
> > > on CLOCK_BOOTTIME, which is the CLOCK_MONOTONIC time since system
> > > boot. The
> > > difference between CLOCK_MONOTONIC and CLOCK_BOOTTIME is that
> > > CLOCK_MONOTONIC does not advance during suspend, but
> CLOCK_BOOTTIME
> > > takes
> > > the suspended time into account.
> > Thanks for feedback.
> > The idea of this patch was of a POC and this is why the code was
> > isolated in timer driver, which I agree is not a good idea for other
> > platforms to copy this since we can simply do all the things in
> > sched_clock_register() function guarded with
> CONFIG_BOOT_TIME_PRESERVE.
> > The patch was created for an internal project where no RTC was available
> > and no user-space apps were making any settimeofday(), and the use of
> > do_settimeofday() seemed safe. But yes, considering that the
> > CLOCK_REALTIME can be easily changed it should not be used here.
> 
> It does not matter at all whether you have a RTC or settimeofday() is used
> or not.
> 
> Again:
> 
> > > It has absolutely nothing to do with CLOCK_BOOTTIME. /proc/uptime is
> > > based on CLOCK_BOOTTIME, which is the CLOCK_MONOTONIC time since
> system
> > > boot. The difference between CLOCK_MONOTONIC and CLOCK_BOOTTIME
> is that
> > > CLOCK_MONOTONIC does not advance during suspend, but
> CLOCK_BOOTTIME
> > > takes the suspended time into account.
> 
> So using settimeofday() for any of what you want to do is bogus and
> useless.

Got it. Thanks!

I am thinking about using timekeeping_inject_sleeptime64(delta) hook to
add a delta time at boot to the CLOCK_BOOTTIME, but the problem that
arise here is that this hook is intended to be used on rtc_resume()
code (to add the time spent in suspend to CLOCK_BOOTTIME).
>From my point of view this will do the trick even if the
CONFIG_BOOT_TIME_PRESERVE will then depend on PM_SLEEP && RTC_HCTOSYS
(needed by timekeeping_inject_sleeptime64 to work).
Do you think this is a good approach?

Regards,
Bogdan