linux-hardening - Re: [PATCH 1/1] arm64: syscall: Direct PRNG kstack randomization

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]

Date: Thu, 07 Mar 2024 22:56:56 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Kees Cook" <keescook@...omium.org>
Cc: "Jeremy Linton" <jeremy.linton@....com>,
 linux-arm-kernel@...ts.infradead.org,
 "Catalin Marinas" <catalin.marinas@....com>, "Will Deacon" <will@...nel.org>,
 "Jason A . Donenfeld" <Jason@...c4.com>,
 "Gustavo A. R. Silva" <gustavoars@...nel.org>,
 "Mark Rutland" <mark.rutland@....com>,
 "Steven Rostedt" <rostedt@...dmis.org>, "Mark Brown" <broonie@...nel.org>,
 "Guo Hui" <guohui@...ontech.com>, Manoj.Iyer@....com,
 linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
 "James Yang" <james.yang@....com>, "Shiyou Huang" <shiyou.huang@....com>
Subject: Re: [PATCH 1/1] arm64: syscall: Direct PRNG kstack randomization

On Thu, Mar 7, 2024, at 20:10, Kees Cook wrote:
> On Thu, Mar 07, 2024 at 12:10:34PM +0100, Arnd Bergmann wrote:
>> For the strength, we have at least four options:
>> 
>> - strong rng, most expensive
>> - your new prng, less strong but somewhat cheaper and/or more
>>   predictable overhead
>> - cycle counter, cheap but probably even less strong,
>>   needs architecture code.
>
> Are the low bits of a cycler counter really less safe than a
> deterministic pRNG?

I don't know, that was based on Jeremy's assertion. I'm not
even convinced that either one is actually safer than no
randomization. ;-)

For both the timer and the pRNG, I guess you'd need a gadget
to extract the current offset and from there extract the
per-cpu state value. Once you know the state and there is no
reseed, you can pick the value you want for the next syscall
by either calling getpid() repeatedly or waiting for the
cycle counter to reach the desired value before calling
a vulnerable syscall. At that point the pRNG and no
randomization are reliably predictable, while the timer
may still have some jitter left.

>> - no rng, no overhead and no protection.
>
> For the pRNG, why not just add a reseed timer or something that'll
> happen outside the syscall window, if that's the concern about reseeding
> delay? (In which case, why not continue to use the strong rng?)

I fear a timer or workqueue would be both weaker than a forced
reseed if the attacker wins the race against the reseed, and
still cause latency that hurts realtime usecases.

       Arnd