linux-kernel - Re: [patch 0/6] timekeeping: Cure the signed/unsigned wreckage

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:   Thu, 8 Dec 2016 20:52:20 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        David Gibson <david@...son.dropbear.id.au>,
        Liav Rehana <liavr@...lanox.com>,
        Chris Metcalf <cmetcalf@...lanox.com>,
        Richard Cochran <richardcochran@...il.com>,
        Parit Bhargava <prarit@...hat.com>,
        Laurent Vivier <lvivier@...hat.com>,
        "Christopher S. Hall" <christopher.s.hall@...el.com>
Subject: Re: [patch 0/6] timekeeping: Cure the signed/unsigned wreckage

On Thu, Dec 8, 2016 at 12:49 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> This series addresses the recently reintroduced signed vs. unsigned
> wreckage by cleaning up the whole call chain instead of just making a
> simple s64 -> u64 'fix' at one point and keeping the rest signed, which
> eventually led to the unintended signed conversion and brought back an
> issue that was fixed a year ago already.
>
> Here is the queue:
>
>   timekeeping: Force unsigned clocksource to nanoseconds conversions
>   timekeeping: Make the conversion call chain consistently unsigned
>   timekeeping: Get rid of pointless typecasts
>
> These three patches are definitely urgent material
>
>   timekeeping: Use mul_u64_u32_shr() instead of open coding it

Thanks for putting these together Thomas!

So I'm happy with the set above.

> Can wait for 4.11, but for sanity reasons it should go into 4.10
>
>   [RFD] timekeeping: Provide optional 128bit math
>
> This is material for discussion. I'm not sure if we want to do that at
> all, but it addresses the insanities of long time scheduled out VMs.

Yea. Here I feel like there has to be some bound after which we don't
function when we're starved of interrupts. On some systems it will be
the hardware clocksource wrapping, on other systems its the
multiplication overflowing.

I think we should avoid the system failing critically (which the
initial patches address), as there are cases like halting the system
via kdb or freezing a VM for a long period of time (hosts suspending
is an example), but having a smallish time inconsistency event in this
case doesn't seem tragic to me.

Providing a config option for folks who want robust time correctness
in the event of insane system scheduling/interrupt latency isn't
something I object to, but I worry it will just push the boundary of
what is "expected broken by design" out further (why bother
suspending/resuming the timekeeping subsystem when you can just starve
it, etc).

thanks
-john