linux-kernel - Re: [DISCUSSION] kstack offset randomization: bugs and performance

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]

Message-ID: <aRtfabU9UaflfHYm@J2N7QTR9R3>
Date: Mon, 17 Nov 2025 17:46:49 +0000
From: Mark Rutland <mark.rutland@....com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Ryan Roberts <ryan.roberts@....com>, Kees Cook <kees@...nel.org>,
	Ard Biesheuvel <ardb@...nel.org>,
	Jeremy Linton <jeremy.linton@....com>,
	Will Deacon <will@...nel.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [DISCUSSION] kstack offset randomization: bugs and performance

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.

> My M2 Mac is running at a slower 24MHz timer. Between two getpid()
> syscalls, I see cntvct_el0 advance between 20 and 70 cycles, which
> still gives a few bits of entropy but not the six bits we actually
> want to use.
> 
> How about we just check the timer frequency at boot and patch out the
> get_random_u16 call for a cntvct read if it gets updated fast enough?
> That would at least take care of the overhead on most new designs and
> hopefully on a large subset of the servers that are in active use.

As above, we cannot rely on the frequency for this, and I don't think we
should use the timer in this way.

To be clear, my objection here is purely about the timer. I don't want
us to rely upon something that doesn't actually provide the guarantee we
need. I'm more than happy with the mechanism for randomization being
changed.

Mark.