Re: [PATCH 0/3] Resolve problems with kexec identity mapping

[Steve Wahl]

On Wed, Jul 03, 2024 at 06:14:41PM +0200, Borislav Petkov wrote:
> On Tue, Jul 02, 2024 at 08:32:22PM +0200, Ard Biesheuvel wrote:
> > For kexec on a 64-bit system, I would expect the high-level support
> > code to be capable of simply mapping all of DRAM 1:1, rather than
> > playing these games with #PF handlers and on-demand mapping.
> 
> Yeah, apparently we can't do that on SGI, as Steve said.
> 
> I like the aspect that the #PF handler won't fire in the first kernel because
> of EFI mapping all RAM. That's good.
> 
> So we could try to wire in a #PF handler in stage1, see below.
> 
> Steve, I don't have a good idea how to test that. Maybe some of those
> reporters you were talking about, would be willing to...
> 
> ---
> diff --git a/arch/x86/boot/compressed/idt_64.c b/arch/x86/boot/compressed/idt_64.c
> index d100284bbef4..a258587c8949 100644
> --- a/arch/x86/boot/compressed/idt_64.c
> +++ b/arch/x86/boot/compressed/idt_64.c
> @@ -32,6 +32,7 @@ void load_stage1_idt(void)
>  {
>  	boot_idt_desc.address = (unsigned long)boot_idt;
>  
> +	set_idt_entry(X86_TRAP_PF, boot_page_fault);
>  
>  	if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT))
>  		set_idt_entry(X86_TRAP_VC, boot_stage1_vc);
> 
> -- 
> Regards/Gruss,
>     Boris.

Boris,

Eric Hagberg tested this patch for me and it didn't work.  (Thanks,
Eric.)

So I looked at the code more closely, and I don't think
boot_page_fault is going to work prior to the call to
initialize_identity_maps.  In the current flow in head_64.S, that
comes after load_stage2_idt, where here we were trying to use it
just after load_stage1_idt, quite a bit earlier.

Is there a reason you want to avoid having these areas already entered
in the identity map setup by kexec?

I can see this could have the appearance of getting out of hand if we
had to continually add things to it. But only those pieces that need
to be referenced before the page fault handler is established actually
require this treatment.

--> Steve

-- 
Steve Wahl, Hewlett Packard Enterprise