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

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: <ZowI9w7huVfcKJ7I@swahl-home.5wahls.com>
Date: Mon, 8 Jul 2024 10:42:47 -0500
From: Steve Wahl <steve.wahl@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: Ard Biesheuvel <ardb@...nel.org>, Steve Wahl <steve.wahl@....com>,
        Ashish Kalra <ashish.kalra@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        linux-kernel@...r.kernel.org, Pavin Joseph <me@...injoseph.com>,
        Eric Hagberg <ehagberg@...il.com>, Simon Horman <horms@...ge.net.au>,
        Eric Biederman <ebiederm@...ssion.com>, Dave Young <dyoung@...hat.com>,
        Sarah Brofeldt <srhb@....dk>, Russ Anderson <rja@....com>,
        Dimitri Sivanich <sivanich@....com>,
        Hou Wenlong <houwenlong.hwl@...group.com>,
        Andrew Morton <akpm@...ux-foundation.org>, Baoquan He <bhe@...hat.com>,
        Yuntao Wang <ytcoode@...il.com>, Bjorn Helgaas <bhelgaas@...gle.com>,
        Joerg Roedel <jroedel@...e.de>, Michael Roth <michael.roth@....com>
Subject: Re: [PATCH 0/3] Resolve problems with kexec identity mapping

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