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] [day] [month] [year] [list]

Date:   Mon, 24 Sep 2018 17:58:02 +0000
From:   Rick Ratzel <rick.ratzel@...com>
To:     Thomas Gleixner <tglx@...utronix.de>
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>,
        Gratian Crisan <gratian.crisan@...com>
Subject: RE: Ensuring wall_to_monotonic is not positive breaks use case

On Sat, 15 Sep 2018, Thomas Gleixner wrote:
> > 
> > So reverting this is not really an option.

> Maybe we can :)

Thanks for checking into this more.  We've been looking at the uses you described, and hopefully we can have something to submit for review (or at least discuss) relatively soon.

>
> 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.
>

Agreed.

> 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.
>

It looks like this can use CLOCK_BOOTTIME as you describe, but "properly" converting to the REALTIME timescale might be hard, as you noticed. One proposal is to floor the conversion to the Epoch, just like your proposal to floor /proc/stat btime to 0, but we're not sure how that'll impact users yet.

> 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.

We're still looking at this one as well...

-Rick