mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Evgeniy Baskov <baskov@ispras.ru>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: 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>,
	lvc-project@linuxtesting.org, x86@kernel.org,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH 13/16] efi/x86: Support extracting kernel from libstub
Date: Thu, 20 Oct 2022 15:36:36 +0300	[thread overview]
Message-ID: <531f40fb580b98cb048d105f5edd381c@ispras.ru> (raw)
In-Reply-To: <CAMj1kXH3BjwgeVrUED04HzqD=WQMtarsas9SH_+Au7bSC6w07g@mail.gmail.com>

On 2022-10-19 10:35, Ard Biesheuvel wrote:
> On Tue, 6 Sept 2022 at 12:42, Evgeniy Baskov <baskov@ispras.ru> wrote:
>> 
>> Doing it that way allows setting up stricter memory attributes,
>> simplifies boot code path and removes potential relocation
>> of kernel image.
>> 
>> Wire up required interfaces and minimally initialize zero page
>> fields needed for it to function correctly.
>> 
>> Signed-off-by: Evgeniy Baskov <baskov@ispras.ru>
>> 
>>  create mode 100644 arch/x86/include/asm/shared/extract.h
>>  create mode 100644 drivers/firmware/efi/libstub/x86-extract-direct.c
>> ---
>>  arch/x86/boot/compressed/head_32.S            |   6 +-
>>  arch/x86/boot/compressed/head_64.S            |  45 ++++
>>  arch/x86/include/asm/shared/extract.h         |  25 ++
>>  drivers/firmware/efi/Kconfig                  |  14 ++
>>  drivers/firmware/efi/libstub/Makefile         |   1 +
>>  drivers/firmware/efi/libstub/efistub.h        |   5 +
>>  .../firmware/efi/libstub/x86-extract-direct.c | 220 
>> ++++++++++++++++++
>>  drivers/firmware/efi/libstub/x86-stub.c       |  45 ++--
>>  8 files changed, 343 insertions(+), 18 deletions(-)
>>  create mode 100644 arch/x86/include/asm/shared/extract.h
>>  create mode 100644 drivers/firmware/efi/libstub/x86-extract-direct.c
>> 
>> diff --git a/arch/x86/boot/compressed/head_32.S 
>> b/arch/x86/boot/compressed/head_32.S
>> index b46a1c4109cf..d2866f06bc9f 100644
>> --- a/arch/x86/boot/compressed/head_32.S
>> +++ b/arch/x86/boot/compressed/head_32.S
>> @@ -155,7 +155,11 @@ SYM_FUNC_START(efi32_stub_entry)
>>         add     $0x4, %esp
>>         movl    8(%esp), %esi   /* save boot_params pointer */
>>         call    efi_main
>> -       /* efi_main returns the possibly relocated address of 
>> startup_32 */
>> +
>> +       /*
>> +        * efi_main returns the possibly
>> +        * relocated address of exteracted kernel entry point.
> 
> extracted

Thanks, will fix.
> 

...
>> diff --git a/arch/x86/include/asm/shared/extract.h 
>> b/arch/x86/include/asm/shared/extract.h
>> new file mode 100644
>> index 000000000000..163678145884
>> --- /dev/null
>> +++ b/arch/x86/include/asm/shared/extract.h
>> @@ -0,0 +1,25 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef ASM_SHARED_EXTRACT_H
>> +#define ASM_SHARED_EXTRACT_H
>> +
>> +#define MAP_WRITE      0x02 /* Writable memory */
>> +#define MAP_EXEC       0x04 /* Executable memory */
>> +#define MAP_ALLOC      0x10 /* Range needs to be allocated */
>> +#define MAP_PROTECT    0x20 /* Set exact memory attributes for memory 
>> range */
>> +
>> +struct efi_iofunc {
>> +       void (*putstr)(const char *msg);
>> +       void (*puthex)(unsigned long x);
>> +       unsigned long (*map_range)(unsigned long start,
>> +                                  unsigned long end,
>> +                                  unsigned int flags);
> 
> This looks a bit random - having a map_range() routine as a member of
> the console I/O struct. Can we make this abstraction a bit more
> natural?

Hmm, I can either change the name of this stucture
to something more generic (like efi_extract_callbacks) or
split map_range separately as a separate function argument.
(Renaming seems simpler, so I will do that for now.)

>> +};
>> +
>> +void *efi_extract_kernel(struct boot_params *rmode,
>> +                        struct efi_iofunc *iofunc,
>> +                        unsigned char *input_data,
>> +                        unsigned long input_len,
>> +                        unsigned char *output,
>> +                        unsigned long output_len);
>> +
>> +#endif /* ASM_SHARED_EXTRACT_H */
>> diff --git a/drivers/firmware/efi/Kconfig 
>> b/drivers/firmware/efi/Kconfig
>> index 6cb7384ad2ac..2418402a0bda 100644
>> --- a/drivers/firmware/efi/Kconfig
>> +++ b/drivers/firmware/efi/Kconfig
>> @@ -91,6 +91,20 @@ config EFI_DXE_MEM_ATTRIBUTES
>>           Use DXE services to check and alter memory protection
>>           attributes during boot via EFISTUB to ensure that memory
>>           ranges used by the kernel are writable and executable.
>> +         This option also enables stricter memory attributes
>> +         on compressed kernel PE image.
>> +
>> +config EFI_STUB_EXTRACT_DIRECT
>> +       bool "Extract kernel directly from UEFI environment"
>> +       depends on EFI && EFI_STUB && X86_64
>> +       default y
> 
> What is the reason for making this configurable? Couldn't we just
> enable it unconditionally?
> 
When I first implemented it it was too hackish, but now it seems OK, so
I can make it unconditional, and it will make things simpler in several
places. Although making it work on x86_32 will require some additional 
work.

Also kernel with EFI_STUB_EXTRACT_DIRECT disabled breaks boot process 
with Mu
firmware when W^X enabled, as pointed out by Peter.

So, I guess, I will just remove the switch.

>> 
>> +#ifdef CONFIG_X86
>> +unsigned long extract_kernel_direct(struct boot_params *boot_params);
>> +void startup_32(struct boot_params *boot_params);
>> +#endif
>> +
> 
> Please put this somewhere else
> 

Will adding little x86-specific header file for these be appropriate?

>> +
>> +#include "efistub.h"
>> +
>> +static void do_puthex(unsigned long value);
>> +static void do_putstr(const char *msg);
>> +
> 
> Can we get rid of these forward declarations?
> 

Yes, I will move those functions here and remove declarations.

...
>> +       /* First page of trampoline is a top level page table */
>> +       efi_adjust_memory_range_protection(trampoline_start,
>> +                                          PAGE_SIZE,
>> +                                          EFI_MEMORY_XP);
>> +
>> +       /* Second page of trampoline is the code (with a padding) */
>> +       status = efi_get_memory_map(&map);
> 
> efi_get_memory_map() has been updated in the mean time, so this needs a 
> rewrite.

Yep, it needs a rebase now.
> 
...
>>  setup_memory_protection(unsigned long image_base, unsigned long 
>> image_size)
>>  {
>>         /*
>> -        * Allow execution of possible trampoline used
>> -        * for switching between 4- and 5-level page tables
>> -        * and relocated kernel image.
>> -        */
>> +       * Allow execution of possible trampoline used
>> +       * for switching between 4- and 5-level page tables
>> +       * and relocated kernel image.
>> +       */
>> 
> 
> Drop this hunk please

That was unintentional, thanks.


  reply	other threads:[~2022-10-20 12:37 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06 10:41 [PATCH 00/16] x86_64: Improvements at compressed kernel stage Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 01/16] x86/boot: Align vmlinuz sections on page size Evgeniy Baskov
2022-10-19  7:01   ` Ard Biesheuvel
2022-10-20 11:13     ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 02/16] x86/build: Remove RWX sections and align on 4KB Evgeniy Baskov
2022-10-19  7:04   ` Ard Biesheuvel
2022-10-20 11:15     ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 03/16] x86/boot: Set cr0 to known state in trampoline Evgeniy Baskov
2022-10-19  7:06   ` Ard Biesheuvel
2022-10-20 11:23     ` Evgeniy Baskov
2022-10-19  7:44   ` Andrew Cooper
2022-10-20 13:25     ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 04/16] x86/boot: Increase boot page table size Evgeniy Baskov
2022-10-19  7:08   ` Ard Biesheuvel
2022-10-20 11:29     ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 05/16] x86/boot: Support 4KB pages for identity mapping Evgeniy Baskov
2022-10-19  7:11   ` Ard Biesheuvel
2022-10-20 11:30     ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 06/16] x86/boot: Setup memory protection for bzImage code Evgeniy Baskov
2022-10-19  7:17   ` Ard Biesheuvel
2022-10-20 12:07     ` Evgeniy Baskov
2022-10-19  7:57   ` Andrew Cooper
2022-10-20 13:30     ` Evgeniy Baskov
2022-10-20 16:51       ` Andrew Cooper
2022-09-06 10:41 ` [PATCH 07/16] x86/boot: Map memory explicitly Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 08/16] x86/boot: Remove mapping from page fault handler Evgeniy Baskov
2022-10-19  7:20   ` Ard Biesheuvel
2022-09-06 10:41 ` [PATCH 09/16] efi/libstub: Move helper function to related file Evgeniy Baskov
2022-10-19  7:21   ` Ard Biesheuvel
2022-09-06 10:41 ` [PATCH 10/16] x86/boot: Make console interface more abstract Evgeniy Baskov
2022-10-19  7:23   ` Ard Biesheuvel
2022-10-20 12:10     ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 11/16] x86/boot: Split trampoline and pt init code Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 12/16] x86/boot: Add EFI kernel extraction interface Evgeniy Baskov
2022-10-19  7:27   ` Ard Biesheuvel
2022-10-20 12:14     ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 13/16] efi/x86: Support extracting kernel from libstub Evgeniy Baskov
2022-10-19  7:35   ` Ard Biesheuvel
2022-10-20 12:36     ` Evgeniy Baskov [this message]
2022-09-06 10:41 ` [PATCH 14/16] x86/build: Make generated PE more spec compliant Evgeniy Baskov
2022-10-19  7:39   ` Ard Biesheuvel
2022-10-20 13:07     ` Evgeniy Baskov
2022-09-06 10:41 ` [PATCH 15/16] efi/libstub: Add memory attribute protocol definitions Evgeniy Baskov
2022-10-19  7:39   ` Ard Biesheuvel
2022-09-06 10:41 ` [PATCH 16/16] efi/libstub: Use memory attribute protocol Evgeniy Baskov
2022-10-18 20:51   ` [PATCH] efi/libstub: make memory protection warnings include newlines Peter Jones
2022-10-19  7:44     ` Ard Biesheuvel
2022-10-19  7:42   ` [PATCH 16/16] efi/libstub: Use memory attribute protocol Ard Biesheuvel
2022-10-20 13:13     ` Evgeniy Baskov
2022-10-18 21:04 ` [PATCH 00/16] x86_64: Improvements at compressed kernel stage Peter Jones
2022-10-20 11:05   ` Evgeniy Baskov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=531f40fb580b98cb048d105f5edd381c@ispras.ru \
    --to=baskov@ispras.ru \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=khoroshilov@ispras.ru \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=lvc-project@linuxtesting.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome