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: <alpine.DEB.2.20.1705231836040.2740@nanos>
Date:   Tue, 23 May 2017 18:39:04 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Mirea, Bogdan-Stefan" <Bogdan-Stefan_Mirea@...tor.com>
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 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.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ