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] [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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ