linux-kernel - Re: [PATCH v7 14/18] x86/boot: make sure KASLR does not step over KHO preserved memory

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: <d6c09132-05bb-481a-93dd-8e9d664981ae@intel.com>
Date: Fri, 2 May 2025 14:36:25 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: Changyuan Lyu <changyuanl@...gle.com>, linux-kernel@...r.kernel.org,
 akpm@...ux-foundation.org, anthony.yznaga@...cle.com, arnd@...db.de,
 ashish.kalra@....com, benh@...nel.crashing.org, bp@...en8.de,
 catalin.marinas@....com, corbet@....net, dave.hansen@...ux.intel.com,
 devicetree@...r.kernel.org, dwmw2@...radead.org, ebiederm@...ssion.com,
 graf@...zon.com, hpa@...or.com, jgowans@...zon.com,
 kexec@...ts.infradead.org, krzk@...nel.org,
 linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
 linux-mm@...ck.org, luto@...nel.org, mark.rutland@....com, mingo@...hat.com,
 pasha.tatashin@...een.com, pbonzini@...hat.com, peterz@...radead.org,
 ptyadav@...zon.de, robh@...nel.org, rostedt@...dmis.org,
 saravanak@...gle.com, skinsburskii@...ux.microsoft.com, tglx@...utronix.de,
 thomas.lendacky@....com, will@...nel.org, x86@...nel.org
Subject: Re: [PATCH v7 14/18] x86/boot: make sure KASLR does not step over KHO
 preserved memory

On 5/2/25 14:16, Mike Rapoport wrote:
>>> +/*
>>> + * If KHO is active, only process its scratch areas to ensure we are not
>>> + * stepping onto preserved memory.
>>> + */
>>> +#ifdef CONFIG_KEXEC_HANDOVER
>>> +static bool process_kho_entries(unsigned long minimum, unsigned long image_size)
>>> +{
>> I thought we agreed to rework this to unconditionally define the
>> kho_scratch structures so the #ifdef can go away?
> It's either #ifdef or double casting and my understanding was that your
> preference was to get rid of the double casting.

Looking back at the other message... Sorry, you did make it clear there
and it just didn't penetrate my thick skull.

The double cast is goofy, but it does seem to be the normal way of doing
things. There are lots of examples of it. So, grudgingly, I prefer the
double cast over the #ifdef.

BTW, _please_ changelog this stuff. It would have saved this round of
back-and-forth. The changelog is the perfect place to say something like:

	This looks goofy out of context, but it is unfortunately the way
	that this is handled across the tree. There are at least a dozen
	instances of casting like this.

This series is generally a bit sparse in the changelog and comment
departments.