linux-kernel - Re: Ensuring wall_to_monotonic is not positive breaks use case

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Sep 2018 18:34:55 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Rick Ratzel <rick.ratzel@...com>
cc:     "john.stultz@...aro.org" <john.stultz@...aro.org>,
        "udknight@...il.com" <udknight@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Julia Cartwright <julia.cartwright@...com>
Subject: Re: Ensuring wall_to_monotonic is not positive breaks use case

Rick,

On Wed, 5 Sep 2018, Rick Ratzel wrote:

> We're looking for suggestions on how best to proceed with a new change
> that ideally both supports the use case described above, as well as
> addresses the symptoms brought up in the initial commit (negative boot
> time causes get_expiry() to overflow time_t, and show_stat() uses
> "unsigned long" to print negative btime).  Any thoughts on this would be
> greatly appreciated.

Those symptoms are just the tip of the iceberg. For sure it screws up
everything around boot time and a lot of things use boottime nowadays.

So reverting this is not really an option.

Chosing a PTP grandmaster which populates random time is a really great
idea. Why has this industry the tendency to turn everything into a
trainwreck?

Thanks,

	tglx