From: Will Deacon <will@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: mark.rutland@arm.com, catalin.marinas@arm.com,
james.morse@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/4] arm64: head: tidy up the Image header definition
Date: Wed, 28 Oct 2020 14:17:27 +0000 [thread overview]
Message-ID: <20201028141726.GE28554@willie-the-truck> (raw)
In-Reply-To: <20201027073209.2897-5-ardb@kernel.org>
On Tue, Oct 27, 2020 at 08:32:09AM +0100, Ard Biesheuvel wrote:
> Even though support for EFI boot remains entirely optional for arm64,
> it is unlikely that we will ever be able to repurpose the image header
> fields that the EFI loader relies on, i.e., the magic NOP at offset
> 0x0 and the PE header address at offset 0x3c.
>
> So let's factor out the differences into a 'magic_nop' macro and a local
> symbol representing the PE header address, and move the conditional
> definitions into efi-header.S, taking into account whether CONFIG_EFI is
> enabled or not.
How many architectures can claim to have both a "magic nop" and a
"mysterious nop", hey?
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm64/kernel/efi-header.S | 43 +++++++++++++++-----
> arch/arm64/kernel/head.S | 19 +--------
> 2 files changed, 35 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi-header.S b/arch/arm64/kernel/efi-header.S
> index ddaf57d825b5..7b7ac4316d95 100644
> --- a/arch/arm64/kernel/efi-header.S
> +++ b/arch/arm64/kernel/efi-header.S
> @@ -7,7 +7,27 @@
> #include <linux/pe.h>
> #include <linux/sizes.h>
>
> + .macro magic_nop
> +#ifdef CONFIG_EFI
> +.L_head:
> + /*
> + * This add instruction has no meaningful effect except that
> + * its opcode forms the magic "MZ" signature required by UEFI.
> + */
> + add x13, x18, #0x16
It's probably faster too ;)
> +#else
> + /*
> + * Bootloaders may inspect the opcode at the start of the kernel
> + * image to decide if the kernel is capable of booting via UEFI.
> + * So put an ordinary NOP here, not the "MZ.." pseudo-nop above.
> + */
> + nop
Let's just hope nobody was decoding the branch instruction...
Acked-by: Will Deacon >will@kernel.org>
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-28 14:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-27 7:32 [PATCH 0/4] arm64: head: pad Image header to 64 KB and unmap it Ard Biesheuvel
2020-10-27 7:32 ` [PATCH 1/4] arm64: efi: increase EFI PE/COFF header padding to 64 KB Ard Biesheuvel
2020-10-27 7:32 ` [PATCH 2/4] arm64: omit [_text, _stext) from permanent kernel mapping Ard Biesheuvel
2020-10-28 14:10 ` Will Deacon
2020-10-27 7:32 ` [PATCH 3/4] arm64/head: avoid symbol names pointing into first 64 KB of kernel image Ard Biesheuvel
2020-10-28 14:12 ` Will Deacon
2020-10-27 7:32 ` [PATCH 4/4] arm64: head: tidy up the Image header definition Ard Biesheuvel
2020-10-28 14:17 ` Will Deacon [this message]
2020-10-28 17:56 ` Robin Murphy
2020-10-29 7:30 ` Ard Biesheuvel
2020-10-29 13:06 ` Robin Murphy
2020-11-03 7:13 ` Ard Biesheuvel
2020-11-04 11:29 ` Robin Murphy
2020-10-28 15:12 ` [PATCH 0/4] arm64: head: pad Image header to 64 KB and unmap it Will Deacon
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=20201028141726.GE28554@willie-the-truck \
--to=will@kernel.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
/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