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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sat, 15 Sep 2018 17:06:42 +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

On Thu, 6 Sep 2018, Thomas Gleixner wrote:
> 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.

I had a second look and actually it's not that bad. My brain snapped on
boot time and we actually have two variants of boot time. One is the
monotonic time since boot aka CLOCK_BOOTTIME and the other one is the wall
clock time when the system was booted.

> So reverting this is not really an option.

Maybe we can :)

We have 3 users in tree:

1) /proc/stat btime

   It's trivial enough to clamp that value to 0, though it might be
   surprising for some users as uptime will tell something different.

2) sunrpc

   I think that can be converted to actually use CLOCK_BOOTTIME. This needs
   a bit of trickery to preserve the user space interfaces which are
   CLOCK_REALTIME based, but it should be doable.

3) x86/kvm

   That's actually the trickiest part of all and I haven't yet fully
   analyzed it, whether there is an issue that time can go negative.

   Actually there shouldn't be one as this is about wall time and that
   cannot go before the epoch. Needs some close inspection and while it
   might be trivial to adapt the code in question, it could be tricky or
   even impossible to fix it without breaking existing guests.

Thanks,

	tglx