Re: [DISCUSSION] kstack offset randomization: bugs and performance

["Arnd Bergmann" <arnd@arndb.de>]

On Mon, Nov 17, 2025, at 18:46, Mark Rutland wrote:
> On Mon, Nov 17, 2025 at 05:47:05PM +0100, Arnd Bergmann wrote:
>> As I understand, the other architectures already just use the cycle counter
>> because that is random enough, but for arm64 the cntvct runs on an
>> unspecified frequency that is often too low.
>> 
>> However, most future machines are ARMv9.1 or higher and require a 1GHz
>> timer frequency. I also checked Graviton-3 (Neoverse-V1, ARMv8.4), which
>> is running its timer at 1.05GHz.
>
> Note that 1GHz requirement is for the *effective frequency*, not the
> underlying counter resolution. The 1GHz requirement means that the
> counter must increment by 10^9 per second, but it doesn't mean that it
> actually increments by 1 every 1 ns.
>
> See ARM DDI 0487 L.b, page D12-6793, which says:
>
> | Counter resolution
> |
> | The counter resolution is a representation of how frequently the
> | counter is updated.
> |
> | For example, a counter might have an effective frequency of 1GHz, but
> | the actual clock runs at 125MHz and therefore the counter resolution
> | is 125Mhz.
> |
> | From Armv8.6, Arm recommends the counter resolution is not less than
> | 50MHz in normal running operation.
>
> ... and note that (unfortunately) that latter point is a recommendation,
> not a requirement.

Right, I see. As far as I can tell, the actual resolution on s390,
x86 and powerpc is also lower than the effective frequency, but
it does indeed seem to be sufficiently higher than this so it's
usually above six bits of entropy there per syscall there.

     Arnd