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 <>
To:     Marc Zyngier <>
Cc:     Linus Walleij <>,
        Linux ARM <>,
        linux-kernel <>,
        Mark Rutland <>,
        Daniel Lezcano <>,
        Thomas Gleixner <>,
        Peter Shier <>,
        Raghavendra Rao Ananta <>,
        Ricardo Koller <>
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 <> 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,
>         M.
> --
> Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists