From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
<msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org"
<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH v3] arm64/efi: efistub: jump to 'stext' directly, not through the header
Date: Thu, 9 Oct 2014 18:23:54 +0100 [thread overview]
Message-ID: <20141009172354.GA466@leverpostej> (raw)
In-Reply-To: <1412777487-13636-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Ard,
On Wed, Oct 08, 2014 at 03:11:27PM +0100, Ard Biesheuvel wrote:
> After the EFI stub has done its business, it jumps into the kernel by
> branching to offset #0 of the loaded Image, which is where it expects
> to find the header containing a 'branch to stext' instruction.
>
> However, the UEFI spec 2.1.1 states the following regarding PE/COFF
> image loading:
> "A UEFI image is loaded into memory through the LoadImage() Boot
> Service. This service loads an image with a PE32+ format into memory.
> This PE32+ loader is required to load all sections of the PE32+ image
> into memory."
>
> In other words, it is /not/ required to load parts of the image that are
> not covered by a PE/COFF section, so it may not have loaded the header
> at the expected offset, as it is not covered by any PE/COFF section.
What does this mean for handle_kernel_image? Given we might not have
_text through to _stext mapped, do we not need to take that into
account?
Also, have we seen problems on any systems yet?
Otherwise, this looks like a good fix for hte problem.
Thanks,
Mark.
> So instead, jump to 'stext' directly, which is at the base of the
> PE/COFF .text section, by supplying a symbol 'stext_offset' to
> efi-entry.o which contains the relative offset of stext into the Image.
> Also replace other open coded calculations of the same value with a
> reference to 'stext_offset'
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Changes since v2:
> - rebased onto 3.17+
> - added spec reference to commit message
>
> Changes since v1:
> - drop :lo12: relocation against stext_offset in favor of using a literal
> '=stext_offset' which is safer
>
> arch/arm64/kernel/efi-entry.S | 3 ++-
> arch/arm64/kernel/head.S | 10 ++++++----
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
> index 619b1dd7bcde..a0016d3a17da 100644
> --- a/arch/arm64/kernel/efi-entry.S
> +++ b/arch/arm64/kernel/efi-entry.S
> @@ -61,7 +61,8 @@ ENTRY(efi_stub_entry)
> */
> mov x20, x0 // DTB address
> ldr x0, [sp, #16] // relocated _text address
> - mov x21, x0
> + ldr x21, =stext_offset
> + add x21, x0, x21
>
> /*
> * Flush dcache covering current runtime addresses
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 0a6e4f924df8..8c06c9d269d2 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -132,6 +132,8 @@ efi_head:
> #endif
>
> #ifdef CONFIG_EFI
> + .globl stext_offset
> + .set stext_offset, stext - efi_head
> .align 3
> pe_header:
> .ascii "PE"
> @@ -155,7 +157,7 @@ optional_header:
> .long 0 // SizeOfInitializedData
> .long 0 // SizeOfUninitializedData
> .long efi_stub_entry - efi_head // AddressOfEntryPoint
> - .long stext - efi_head // BaseOfCode
> + .long stext_offset // BaseOfCode
>
> extra_header_fields:
> .quad 0 // ImageBase
> @@ -172,7 +174,7 @@ extra_header_fields:
> .long _end - efi_head // SizeOfImage
>
> // Everything before the kernel image is considered part of the header
> - .long stext - efi_head // SizeOfHeaders
> + .long stext_offset // SizeOfHeaders
> .long 0 // CheckSum
> .short 0xa // Subsystem (EFI application)
> .short 0 // DllCharacteristics
> @@ -217,9 +219,9 @@ section_table:
> .byte 0
> .byte 0 // end of 0 padding of section name
> .long _end - stext // VirtualSize
> - .long stext - efi_head // VirtualAddress
> + .long stext_offset // VirtualAddress
> .long _edata - stext // SizeOfRawData
> - .long stext - efi_head // PointerToRawData
> + .long stext_offset // PointerToRawData
>
> .long 0 // PointerToRelocations (0 for executables)
> .long 0 // PointerToLineNumbers (0 for executables)
> --
> 1.8.3.2
>
>
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] arm64/efi: efistub: jump to 'stext' directly, not through the header
Date: Thu, 9 Oct 2014 18:23:54 +0100 [thread overview]
Message-ID: <20141009172354.GA466@leverpostej> (raw)
In-Reply-To: <1412777487-13636-1-git-send-email-ard.biesheuvel@linaro.org>
Hi Ard,
On Wed, Oct 08, 2014 at 03:11:27PM +0100, Ard Biesheuvel wrote:
> After the EFI stub has done its business, it jumps into the kernel by
> branching to offset #0 of the loaded Image, which is where it expects
> to find the header containing a 'branch to stext' instruction.
>
> However, the UEFI spec 2.1.1 states the following regarding PE/COFF
> image loading:
> "A UEFI image is loaded into memory through the LoadImage() Boot
> Service. This service loads an image with a PE32+ format into memory.
> This PE32+ loader is required to load all sections of the PE32+ image
> into memory."
>
> In other words, it is /not/ required to load parts of the image that are
> not covered by a PE/COFF section, so it may not have loaded the header
> at the expected offset, as it is not covered by any PE/COFF section.
What does this mean for handle_kernel_image? Given we might not have
_text through to _stext mapped, do we not need to take that into
account?
Also, have we seen problems on any systems yet?
Otherwise, this looks like a good fix for hte problem.
Thanks,
Mark.
> So instead, jump to 'stext' directly, which is at the base of the
> PE/COFF .text section, by supplying a symbol 'stext_offset' to
> efi-entry.o which contains the relative offset of stext into the Image.
> Also replace other open coded calculations of the same value with a
> reference to 'stext_offset'
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> Changes since v2:
> - rebased onto 3.17+
> - added spec reference to commit message
>
> Changes since v1:
> - drop :lo12: relocation against stext_offset in favor of using a literal
> '=stext_offset' which is safer
>
> arch/arm64/kernel/efi-entry.S | 3 ++-
> arch/arm64/kernel/head.S | 10 ++++++----
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
> index 619b1dd7bcde..a0016d3a17da 100644
> --- a/arch/arm64/kernel/efi-entry.S
> +++ b/arch/arm64/kernel/efi-entry.S
> @@ -61,7 +61,8 @@ ENTRY(efi_stub_entry)
> */
> mov x20, x0 // DTB address
> ldr x0, [sp, #16] // relocated _text address
> - mov x21, x0
> + ldr x21, =stext_offset
> + add x21, x0, x21
>
> /*
> * Flush dcache covering current runtime addresses
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 0a6e4f924df8..8c06c9d269d2 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -132,6 +132,8 @@ efi_head:
> #endif
>
> #ifdef CONFIG_EFI
> + .globl stext_offset
> + .set stext_offset, stext - efi_head
> .align 3
> pe_header:
> .ascii "PE"
> @@ -155,7 +157,7 @@ optional_header:
> .long 0 // SizeOfInitializedData
> .long 0 // SizeOfUninitializedData
> .long efi_stub_entry - efi_head // AddressOfEntryPoint
> - .long stext - efi_head // BaseOfCode
> + .long stext_offset // BaseOfCode
>
> extra_header_fields:
> .quad 0 // ImageBase
> @@ -172,7 +174,7 @@ extra_header_fields:
> .long _end - efi_head // SizeOfImage
>
> // Everything before the kernel image is considered part of the header
> - .long stext - efi_head // SizeOfHeaders
> + .long stext_offset // SizeOfHeaders
> .long 0 // CheckSum
> .short 0xa // Subsystem (EFI application)
> .short 0 // DllCharacteristics
> @@ -217,9 +219,9 @@ section_table:
> .byte 0
> .byte 0 // end of 0 padding of section name
> .long _end - stext // VirtualSize
> - .long stext - efi_head // VirtualAddress
> + .long stext_offset // VirtualAddress
> .long _edata - stext // SizeOfRawData
> - .long stext - efi_head // PointerToRawData
> + .long stext_offset // PointerToRawData
>
> .long 0 // PointerToRelocations (0 for executables)
> .long 0 // PointerToLineNumbers (0 for executables)
> --
> 1.8.3.2
>
>
next prev parent reply other threads:[~2014-10-09 17:23 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 14:11 [PATCH v3] arm64/efi: efistub: jump to 'stext' directly, not through the header Ard Biesheuvel
2014-10-08 14:11 ` Ard Biesheuvel
[not found] ` <1412777487-13636-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-10-09 17:23 ` Mark Rutland [this message]
2014-10-09 17:23 ` Mark Rutland
2014-10-09 19:03 ` Ard Biesheuvel
2014-10-09 19:03 ` Ard Biesheuvel
[not found] ` <CAKv+Gu-D812Rn32rm5wQJfSM+NzPXZWbxDcDkZ8mBzbi5RQJXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-09 22:19 ` Mark Salter
2014-10-09 22:19 ` Mark Salter
[not found] ` <1412893179.29182.71.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-10-09 23:20 ` Roy Franz
2014-10-09 23:20 ` Roy Franz
[not found] ` <CAFECyb9Tz2Fo2ix0VYiM7WPeie7C=woiVwyQtR4aH_HPcLwkOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-10 6:30 ` Ard Biesheuvel
2014-10-10 6:30 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_6uww=W9M9hDfoSmY+zr2i75Y=JOxTLCya2rr=HiT6Bw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-10 14:14 ` Mark Salter
2014-10-10 14:14 ` Mark Salter
[not found] ` <1412950468.29182.82.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-10-10 14:28 ` Ard Biesheuvel
2014-10-10 14:28 ` Ard Biesheuvel
2014-10-10 13:53 ` Peter Jones
2014-10-10 13:53 ` Peter Jones
2014-10-10 10:49 ` Mark Rutland
2014-10-10 10:49 ` Mark Rutland
2014-10-10 11:52 ` Ard Biesheuvel
2014-10-10 11:52 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_mx3uWqnRESAjqz6MdUJqBSjgeMCdnpzKiRQ+1FxUjCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-10 12:19 ` Mark Rutland
2014-10-10 12:19 ` Mark Rutland
2014-10-10 12:31 ` Ard Biesheuvel
2014-10-10 12:31 ` Ard Biesheuvel
[not found] ` <CAKv+Gu-Kk=hZ78T+_ePceTgb9m4KmvpLcYOwvxEWuUcT+ScK_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-10 13:03 ` Mark Rutland
2014-10-10 13:03 ` Mark Rutland
2014-10-10 13:27 ` Ard Biesheuvel
2014-10-10 13:27 ` Ard Biesheuvel
[not found] ` <CAKv+Gu-OJ+byitcYSsajgEhgPOwP2ooF4Ro1QgJzXw1Z_VX1Ow-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-10 14:02 ` Mark Rutland
2014-10-10 14:02 ` Mark Rutland
2014-10-10 15:38 ` Roy Franz
2014-10-10 15:38 ` Roy Franz
2014-10-10 15:52 ` Ard Biesheuvel
2014-10-10 15:52 ` 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=20141009172354.GA466@leverpostej \
--to=mark.rutland-5wv7dgnigg8@public.gmane.org \
--cc=Catalin.Marinas-5wv7dgnIgG8@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.