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: <c348c507-c06b-4611-87f4-c498e144fa45@intel.com>
Date: Fri, 2 May 2025 11:48:54 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Changyuan Lyu <changyuanl@...gle.com>, linux-kernel@...r.kernel.org
Cc: 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, rppt@...nel.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/1/25 15:54, Changyuan Lyu wrote:
> KHO uses "scratch regions" to bootstrap a kexec'ed kernel. These regions are
> guaranteed to not have any memory that KHO would preserve.

I understand how these changelogs got written. They were written by
someone thinking *only* about KHO and hacking it into the existing code.
That's fine and understandable.

But everyone else is coming at this from the perspective of not knowing
what scratch memory is.

"Scratch memory" in the KHO world is basically "normal kernel memory" to
anybody else. So I think it's a disservice to everyone else reading
these changelogs to act like it's something special.

The thing that *is* special is that KHO kernels don't have a lot of
"normal kernel memory". At least they're designed to tolerate lots of
handed-off memory and little "scratch memory"

When you run through these again, could you please try to write these
changelogs and comments for folks that are not familiar with KHO?

> +/*
> + * 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?

> +	struct kho_scratch *kho_scratch;
> +	struct setup_data *ptr;
> +	int i, nr_areas = 0;
> +
> +	ptr = (struct setup_data *)boot_params_ptr->hdr.setup_data;
> +	while (ptr) {
> +		if (ptr->type == SETUP_KEXEC_KHO) {
> +			struct kho_data *kho = (struct kho_data *)ptr->data;
> +
> +			kho_scratch = (void *)kho->scratch_addr;
> +			nr_areas = kho->scratch_size / sizeof(*kho_scratch);
> +
> +			break;
> +		}
> +
> +		ptr = (struct setup_data *)ptr->next;
> +	}
> +
> +	if (!nr_areas)
> +		return false;
> +
> +	for (i = 0; i < nr_areas; i++) {
> +		struct kho_scratch *area = &kho_scratch[i];
> +		struct mem_vector region = {
> +			.start = area->addr,
> +			.size = area->size,
> +		};
> +
> +		if (process_mem_region(&region, minimum, image_size))
> +			break;
> +	}
> +
> +	return true;
> +}
> +#else
> +static inline bool process_kho_entries(unsigned long minimum,
> +				       unsigned long image_size)
> +{
> +	return false;
> +}
> +#endif
> +
>  static unsigned long find_random_phys_addr(unsigned long minimum,
>  					   unsigned long image_size)
>  {
> @@ -775,7 +824,8 @@ static unsigned long find_random_phys_addr(unsigned long minimum,
>  		return 0;
>  	}
>  
> -	if (!process_efi_entries(minimum, image_size))
> +	if (!process_kho_entries(minimum, image_size) &&
> +	    !process_efi_entries(minimum, image_size))
>  		process_e820_entries(minimum, image_size);
>  
>  	phys_addr = slots_fetch_random();

I made a comment about this in the last round, making this the second
thing that I've noticed that was not addressed.

Could you please go back through the last round of comments before you
repost these?

Just to be clear: these are making progress, but they're not OK from the
x86 side yet.