From: Borislav Petkov <bp@alien8.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
Evgeniy Baskov <baskov@ispras.ru>,
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>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Joerg Roedel <jroedel@suse.de>
Subject: Re: [PATCH v5 01/20] x86/efistub: Branch straight to kernel entry point from C code
Date: Wed, 7 Jun 2023 20:53:01 +0200 [thread overview]
Message-ID: <20230607185301.GNZIDSDWX8xnTaeENe@fat_crate.local> (raw)
In-Reply-To: <20230607072342.4054036-2-ardb@kernel.org>
On Wed, Jun 07, 2023 at 09:23:23AM +0200, Ard Biesheuvel wrote:
> - return bzimage_addr;
> + if (IS_ENABLED(CONFIG_X86_64))
> + /* add offset of startup_64() */
> + bzimage_addr += 0x200;
Uh, magic.
Well, there's this:
arch/x86/boot/compressed/head_64.S:
.code64
.org 0x200
SYM_CODE_START(startup_64)
/*
* 64bit entry is 0x200 and it is ABI so immutable!
* We come here either from startup_32 or directly from a
* 64bit bootloader.
Looking at Documentation/arch/x86/boot.rst, we actually say in the
xloadflags section:
Bit 0 (read): XLF_KERNEL_64
- If 1, this kernel has the legacy 64-bit entry point at 0x200.
and header.S sets that:
xloadflags:
#ifdef CONFIG_X86_64
# define XLF0 XLF_KERNEL_64 /* 64-bit kernel */
so you checking CONFIG_X86_64 is probably ok.
It might be cleaner, though, if you test XLF_KERNEL_64 directly and act
accordingly, although, do I understand it correctly, that the EFI
libstub goes together with the kernel it was built for so the checks
would be doing the same thing...? I.e., the libstub cannot be somehow
"glued" with another kernel or so, which doesn't set CONFIG_X86_64.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2023-06-07 18:53 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-07 7:23 [PATCH v5 00/20] efi/x86: Avoid bare metal decompressor during EFI boot Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 01/20] x86/efistub: Branch straight to kernel entry point from C code Ard Biesheuvel
2023-06-07 18:53 ` Borislav Petkov [this message]
2023-06-07 19:39 ` Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 02/20] x86/efistub: Simplify and clean up handover entry code Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 03/20] x86/decompressor: Avoid magic offsets for EFI handover entrypoint Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 04/20] x86/efistub: Clear BSS in EFI handover protocol entrypoint Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 05/20] x86/decompressor: Use proper sequence to take the address of the GOT Ard Biesheuvel
2023-06-21 11:08 ` Borislav Petkov
2023-06-23 14:00 ` Ard Biesheuvel
2023-07-07 13:56 ` Borislav Petkov
2023-06-07 7:23 ` [PATCH v5 06/20] x86/decompressor: Store boot_params pointer in callee save register Ard Biesheuvel
2023-07-10 9:06 ` Borislav Petkov
2023-07-10 21:55 ` Ard Biesheuvel
2023-07-11 7:57 ` Borislav Petkov
2023-06-07 7:23 ` [PATCH v5 07/20] x86/decompressor: Call trampoline as a normal function Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 08/20] x86/decompressor: Use standard calling convention for trampoline Ard Biesheuvel
2023-06-07 19:38 ` Yunhong Jiang
2023-06-07 20:07 ` Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 09/20] x86/decompressor: Avoid the need for a stack in the 32-bit trampoline Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 10/20] x86/decompressor: Call trampoline directly from C code Ard Biesheuvel
2023-06-07 18:09 ` Yunhong Jiang
2023-06-08 8:04 ` Ard Biesheuvel
2023-06-08 18:15 ` Yunhong Jiang
2023-06-07 7:23 ` [PATCH v5 11/20] x86/decompressor: Only call the trampoline when changing paging levels Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 12/20] x86/decompressor: Merge trampoline cleanup with switching code Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 13/20] x86/efistub: Perform 4/5 level paging switch from the stub Ard Biesheuvel
2023-06-07 20:19 ` Yunhong Jiang
2023-06-07 20:31 ` Ard Biesheuvel
2023-06-08 0:43 ` Yunhong Jiang
2023-06-08 6:34 ` Ard Biesheuvel
2023-06-08 16:10 ` Yunhong Jiang
2023-06-07 7:23 ` [PATCH v5 14/20] x86/efistub: Prefer EFI memory attributes protocol over DXE services Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 15/20] decompress: Use 8 byte alignment Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 16/20] x86/decompressor: Move global symbol references to C code Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 17/20] x86/decompressor: Factor out kernel decompression and relocation Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 18/20] efi/libstub: Add limit argument to efi_random_alloc() Ard Biesheuvel
2023-06-07 7:23 ` [PATCH v5 19/20] x86/efistub: Perform SNP feature test while running in the firmware Ard Biesheuvel
2023-06-07 16:07 ` Tom Lendacky
2023-06-07 16:51 ` Ard Biesheuvel
2023-06-07 17:29 ` Tom Lendacky
2023-06-07 7:23 ` [PATCH v5 20/20] x86/efistub: Avoid legacy decompressor when doing EFI boot Ard Biesheuvel
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=20230607185301.GNZIDSDWX8xnTaeENe@fat_crate.local \
--to=bp@alien8.de \
--cc=ardb@kernel.org \
--cc=baskov@ispras.ru \
--cc=dave.hansen@linux.intel.com \
--cc=dyoung@redhat.com \
--cc=jroedel@suse.de \
--cc=keescook@chromium.org \
--cc=khoroshilov@ispras.ru \
--cc=kirill.shutemov@linux.intel.com \
--cc=kraxel@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjones@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).