Received-SPF: pass (google.com: domain of linux-kernel+bounces-112109-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <2ebe2ea5-b107-4020-8e60-ff8cf43a3aab@arm.com>
Date: Fri, 22 Mar 2024 18:40:54 -0500
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/1] arm64: syscall: Direct PRNG kstack randomization
Content-Language: en-US
To: Arnd Bergmann <arnd@arndb.de>, Kees Cook <keescook@chromium.org>
Cc: linux-arm-kernel@lists.infradead.org,
 Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>,
 "Jason A . Donenfeld" <Jason@zx2c4.com>,
 "Gustavo A. R. Silva" <gustavoars@kernel.org>,
 Mark Rutland <mark.rutland@arm.com>, Steven Rostedt <rostedt@goodmis.org>,
 Mark Brown <broonie@kernel.org>, Guo Hui <guohui@uniontech.com>,
 Manoj.Iyer@arm.com, linux-kernel@vger.kernel.org,
 linux-hardening@vger.kernel.org, James Yang <james.yang@arm.com>,
 Shiyou Huang <shiyou.huang@arm.com>
References: <20240305221824.3300322-1-jeremy.linton@arm.com>
 <20240305221824.3300322-2-jeremy.linton@arm.com>
 <202403051526.0BE26F99E@keescook>
 <34351804-ad1d-498f-932a-c1844b78589f@app.fastmail.com>
 <38f9541b-dd88-4d49-af3b-bc7880a4e2f4@arm.com>
 <f1dd15ce-69af-4315-8d7c-b7a480e541aa@app.fastmail.com>
 <db7dfa2d-c7c6-4b10-981a-a7ecc87c8541@arm.com>
 <acfc522a-5162-4b33-9d6c-1e25d0c44a71@app.fastmail.com>
From: Jeremy Linton <jeremy.linton@arm.com>
In-Reply-To: <acfc522a-5162-4b33-9d6c-1e25d0c44a71@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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,