linux-kernel - Re: [PATCH v2] clocksource/arm_arch_timer: Fix masking for high freq counters

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 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:   Mon, 9 Aug 2021 08:08:19 -0700
From:   Oliver Upton <oupton@...gle.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Shier <pshier@...gle.com>,
        Raghavendra Rao Ananta <rananta@...gle.com>,
        Ricardo Koller <ricarkol@...gle.com>
Subject: Re: [PATCH v2] clocksource/arm_arch_timer: Fix masking for high freq counters

On Mon, Aug 9, 2021 at 3:45 AM Marc Zyngier <maz@...nel.org> wrote:
> > On that note, I wonder how (if ever) we will be able to move away from
> > unnecessarily masking a 64 bit counter, i.e. a v8.6 or above
> > implementation. With this patch, one such counter would wrap after
> > 36.56 years, short of the 40 year guarantee we have from the
> > architecture for < v8.6 implementations. Getting it to 64 bits would
> > squarely make it someone else's problem ~585 years from now :)
>
> Hmmm. If you end-up with something that falls short of 40 years, then
> I suspect something is wrong in the way you compute the required
> width.
>
> 40 years @1GHz (which we shall call FY1G from now on) fits comfortably
> in 61 bits, and I fear that your use of ilog2() gives you one less bit
> than what it should be:
>
> log2(FY1G) ~= 60.13

Right, this is round-down behavior was deliberate. Reading the ARM ARM
D11.1.2 'The system counter', I did not find any language that
suggested the counter saturates the register width before rolling
over. So, it may be paranoid, but I presumed it to be safer to wrap
within the guaranteed interval rather than assume the sanity of the
system counter implementation. That being said, fine with rounding up
instead, so long as we don't believe there's any chance of hardware
doing something crazy.

--
Thanks,
Oliver
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.