Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230424165726.2245548-1-ardb@kernel.org> <20230424165726.2245548-5-ardb@kernel.org>
 <20230426104200.drmuewhwmhh3xljh@box.shutemov.name>
In-Reply-To: <20230426104200.drmuewhwmhh3xljh@box.shutemov.name>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Wed, 26 Apr 2023 22:29:38 +0100
Message-ID: <CAMj1kXEhZ_R7tvdjKfnt63y41JE98wi3vOpav=a_Hqhnmo0xXw@mail.gmail.com>
Subject: Re: [PATCH 4/6] x86: efistub: Perform 4/5 level paging switch from
 the stub
To:     "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc:     linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
        Evgeniy Baskov <baskov@ispras.ru>,
        Borislav Petkov <bp@alien8.de>,
        Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Alexey Khoroshilov <khoroshilov@ispras.ru>,
        Peter Jones <pjones@redhat.com>,
        Gerd Hoffmann <kraxel@redhat.com>,
        Dave Young <dyoung@redhat.com>,
        Mario Limonciello <mario.limonciello@amd.com>,
        Kees Cook <keescook@chromium.org>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 26 Apr 2023 at 11:42, Kirill A . Shutemov
<kirill.shutemov@linux.intel.com> wrote:
>
> On Mon, Apr 24, 2023 at 06:57:24PM +0200, Ard Biesheuvel wrote:
> > In preparation for updating the EFI stub boot flow to avoid the bare
> > metal decompressor code altogether, implement the support code for
> > switching between 4 and 5 levels of paging before jumping to the kernel
> > proper.
>
> I must admit it is neat. I like it a lot.
>

Thanks!

> Any chance we can share the code with the traditional decompressor?
> There's not much that EFI specific here. It should be possible to isolate
> it from the rest, no?
>

I agree. The EFI boot code should still avoid the bare metal
trampoline allocation/deallocation, but the actual payload could be
the same - it's just an indirect call with the GDT and page table
pointers as arguments.

>
> > @@ -792,6 +925,14 @@ asmlinkage unsigned long efi_main(efi_handle_t handle,
> >                               (get_efi_config_table(ACPI_20_TABLE_GUID) ?:
> >                                get_efi_config_table(ACPI_TABLE_GUID));
> >
> > +#ifdef CONFIG_X86_64
> > +     status = efi_setup_5level_paging();
> > +     if (status != EFI_SUCCESS) {
> > +             efi_err("efi_setup_5level_paging() failed!\n");
> > +             goto fail;
> > +     }
> > +#endif
> > +
> >       /*
> >        * If the kernel isn't already loaded at a suitable address,
> >        * relocate it.
> > @@ -910,6 +1051,10 @@ asmlinkage unsigned long efi_main(efi_handle_t handle,
> >               goto fail;
> >       }
> >
> > +#ifdef CONFIG_X86_64
> > +     efi_5level_switch();
> > +#endif
> > +
> >       return bzimage_addr;
> >  fail:
> >       efi_err("efi_main() failed!\n");
>
> Maybe use IS_ENABLED() + dummy efi_setup_5level_paging()/efi_5level_switch()
> instead of #ifdefs?
>

These are functions returning void so I can just move the #ifdef into
the function implementation. Wo do need #ifdefs at some level, as i386
does not provide a definition for __KERNEL32_CS