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
| ||
|
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.
Powered by blists - more mailing lists