linux-kernel - 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: Fri, 22 Mar 2024 18:40:54 -0500
From: Jeremy Linton <jeremy.linton@....com>
To: Arnd Bergmann <arnd@...db.de>, Kees Cook <keescook@...omium.org>
Cc: 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

Hi,

Sorry about the delay here, PTO and I actually wanted to verify my 
assumptions.

On 3/8/24 14:29, Arnd Bergmann wrote:
> On Fri, Mar 8, 2024, at 17:49, Jeremy Linton wrote:
>> On 3/7/24 05:10, Arnd Bergmann wrote:
>>>
>>> I'm not sure I understand the logic. Do you mean that accessing
>>> CNTVCT itself is slow, or that reseeding based on CNTVCT is slow
>>> because of the overhead of reseeding?
>>
>> Slow, as in, its running at a much lower frequency than a cycle counter.
> 
> Ok, I see. Would it be possible to use PMEVCNTR0 instead?

So, I presume you actually mean PMCCNTR_EL0 because I don't see the 
point of a dedicated event, although maybe...

So, the first and maybe largest problem is the PMxxx registers are all 
optional because the PMU is optional! Although, they are strongly 
recommended and most (AFAIK) machines do implement them. So, maybe if 
its just using a cycle counter to dump some entropy into rnd_state it 
becomes a statement that kstack randomization is slower or unsupported 
if there isn't a PMU?

But then we have to basically enable the PMU cycle counter globally, 
which requires reworking how it works, because the cycle counter is 
enabled/disabled and reset on the fly depending on whether the user is 
trying to profile something. So, I have hacked that up, and it appears 
to be working, although i'm not sure what kind of interaction will 
happen with KVM yet.

But I guess the larger question is whether its worth changing the PMU 
behavior for this?

Thanks,