[v2,5/7] arm: efi: split zImage code and data into separate PE/COFF sections

Message ID 20170629081849.15081-6-ard.biesheuvel@linaro.org
State Superseded
Headers show
Series
  • ARM: efi: PE/COFF cleanup/hardening
Related show

Commit Message

Ard Biesheuvel June 29, 2017, 8:18 a.m.
To prevent unintended modifications to the kernel text (malicious or
otherwise) while running the EFI stub, describe the kernel image as
two separate sections: a .text section with read-execute permissions,
covering .text, .rodata, .piggytext and the GOT sections (which the
stub does not care about anyway), and a .data section with read-write
permissions, covering .data and .bss.

This relies on the firmware to actually take the section permission
flags into account, but this is something that is currently being
implemented in EDK2, which means we will likely start seeing it in
the wild between one and two years from now.

Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

---
 arch/arm/boot/compressed/efi-header.S  | 32 ++++++++++++++------
 arch/arm/boot/compressed/vmlinux.lds.S | 30 +++++++++++++-----
 2 files changed, 46 insertions(+), 16 deletions(-)

-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Gregory CLEMENT Sept. 8, 2017, 1:50 p.m. | #1
Hi Ard,
 
 On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> To prevent unintended modifications to the kernel text (malicious or

> otherwise) while running the EFI stub, describe the kernel image as

> two separate sections: a .text section with read-execute permissions,

> covering .text, .rodata, .piggytext and the GOT sections (which the

> stub does not care about anyway), and a .data section with read-write

> permissions, covering .data and .bss.

>

> This relies on the firmware to actually take the section permission

> flags into account, but this is something that is currently being

> implemented in EDK2, which means we will likely start seeing it in

> the wild between one and two years from now.


This patch had been merged in mainline yesterday and now prevent the
Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect
that more Socs are impacted because the number of boot fail exploded
according to kci:
https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

I found this patch after bisecting (I can provide the bisect log if
needed).

The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in
multi_v7_defconfig but not with mvebu_v7_defconfig.

Currently the solution is to revert this patch.

Have you a better option?

Thanks,

Gregory

>

> Cc: Russell King <linux@armlinux.org.uk>

> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---

>  arch/arm/boot/compressed/efi-header.S  | 32 ++++++++++++++------

>  arch/arm/boot/compressed/vmlinux.lds.S | 30 +++++++++++++-----

>  2 files changed, 46 insertions(+), 16 deletions(-)

>

> diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S

> index 542e1ad432ae..c94a88ae834d 100644

> --- a/arch/arm/boot/compressed/efi-header.S

> +++ b/arch/arm/boot/compressed/efi-header.S

> @@ -54,20 +54,22 @@ coff_header:

>  			IMAGE_FILE_EXECUTABLE_IMAGE | \

>  			IMAGE_FILE_LINE_NUMS_STRIPPED	@ Characteristics

>  

> +#define __pecoff_code_size (__pecoff_data_start - __efi_start)

> +

>  optional_header:

>  		.short	PE_OPT_MAGIC_PE32		@ PE32 format

>  		.byte	0x02				@ MajorLinkerVersion

>  		.byte	0x14				@ MinorLinkerVersion

> -		.long	_end - __efi_start		@ SizeOfCode

> -		.long	0				@ SizeOfInitializedData

> +		.long	__pecoff_code_size		@ SizeOfCode

> +		.long	__pecoff_data_size		@ SizeOfInitializedData

>  		.long	0				@ SizeOfUninitializedData

>  		.long	efi_stub_entry - start		@ AddressOfEntryPoint

>  		.long	start_offset			@ BaseOfCode

> -		.long	0				@ BaseOfData

> +		.long	__pecoff_data_start - start	@ BaseOfData

>  

>  extra_header_fields:

>  		.long	0				@ ImageBase

> -		.long	SZ_512				@ SectionAlignment

> +		.long	SZ_4K				@ SectionAlignment

>  		.long	SZ_512				@ FileAlignment

>  		.short	0				@ MajorOsVersion

>  		.short	0				@ MinorOsVersion

> @@ -77,7 +79,7 @@ extra_header_fields:

>  		.short	0				@ MinorSubsystemVersion

>  		.long	0				@ Win32VersionValue

>  

> -		.long	_end - start			@ SizeOfImage

> +		.long	__pecoff_end - start		@ SizeOfImage

>  		.long	start_offset			@ SizeOfHeaders

>  		.long	0				@ CheckSum

>  		.short	IMAGE_SUBSYSTEM_EFI_APPLICATION	@ Subsystem

> @@ -98,9 +100,9 @@ extra_header_fields:

>  

>  section_table:

>  		.ascii	".text\0\0\0"

> -		.long	_end - __efi_start		@ VirtualSize

> +		.long	__pecoff_code_size		@ VirtualSize

>  		.long	__efi_start			@ VirtualAddress

> -		.long	_edata - __efi_start		@ SizeOfRawData

> +		.long	__pecoff_code_size		@ SizeOfRawData

>  		.long	__efi_start			@ PointerToRawData

>  		.long	0				@ PointerToRelocations

>  		.long	0				@ PointerToLineNumbers

> @@ -108,12 +110,24 @@ section_table:

>  		.short	0				@ NumberOfLineNumbers

>  		.long	IMAGE_SCN_CNT_CODE | \

>  			IMAGE_SCN_MEM_READ | \

> -			IMAGE_SCN_MEM_WRITE | \

>  			IMAGE_SCN_MEM_EXECUTE		@ Characteristics

>  

> +		.ascii	".data\0\0\0"

> +		.long	__pecoff_data_size		@ VirtualSize

> +		.long	__pecoff_data_start - start	@ VirtualAddress

> +		.long	__pecoff_data_rawsize		@ SizeOfRawData

> +		.long	__pecoff_data_start - start	@ PointerToRawData

> +		.long	0				@ PointerToRelocations

> +		.long	0				@ PointerToLineNumbers

> +		.short	0				@ NumberOfRelocations

> +		.short	0				@ NumberOfLineNumbers

> +		.long	IMAGE_SCN_CNT_INITIALIZED_DATA | \

> +			IMAGE_SCN_MEM_READ | \

> +			IMAGE_SCN_MEM_WRITE		@ Characteristics

> +

>  		.set	section_count, (. - section_table) / 40

>  

> -		.align	9

> +		.align	12

>  __efi_start:

>  #endif

>  		.endm

> diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S

> index 1fa62432e283..dfcc2baa0077 100644

> --- a/arch/arm/boot/compressed/vmlinux.lds.S

> +++ b/arch/arm/boot/compressed/vmlinux.lds.S

> @@ -53,13 +53,6 @@ SECTIONS

>      *(.rodata)

>      *(.rodata.*)

>    }

> -  .data : {

> -    /*

> -     * The EFI stub always executes from RAM, and runs strictly before the

> -     * decompressor, so we can make an exception for its r/w data, and keep it

> -     */

> -    *(.data.efistub)

> -  }

>    .piggydata : {

>      *(.piggydata)

>    }

> @@ -75,6 +68,26 @@ SECTIONS

>    /* ensure the zImage file size is always a multiple of 64 bits */

>    /* (without a dummy byte, ld just ignores the empty section) */

>    .pad			: { BYTE(0); . = ALIGN(8); }

> +

> +#ifdef CONFIG_EFI_STUB

> +  .data : ALIGN(4096) {

> +    __pecoff_data_start = .;

> +    /*

> +     * The EFI stub always executes from RAM, and runs strictly before the

> +     * decompressor, so we can make an exception for its r/w data, and keep it

> +     */

> +    *(.data.efistub)

> +    __pecoff_data_end = .;

> +

> +    /*

> +     * PE/COFF mandates a file size which is a multiple of 512 bytes if the

> +     * section size equals or exceeds 4 KB

> +     */

> +    . = ALIGN(512);

> +  }

> +  __pecoff_data_rawsize = . - ADDR(.data);

> +#endif

> +

>    _edata = .;

>  

>    _magic_sig = ZIMAGE_MAGIC(0x016f2818);

> @@ -89,6 +102,9 @@ SECTIONS

>    . = ALIGN(8);		/* the stack must be 64-bit aligned */

>    .stack		: { *(.stack) }

>  

> +  PROVIDE(__pecoff_data_size = ALIGN(512) - ADDR(.data));

> +  PROVIDE(__pecoff_end = ALIGN(512));

> +

>    .stab 0		: { *(.stab) }

>    .stabstr 0		: { *(.stabstr) }

>    .stab.excl 0		: { *(.stab.excl) }

> -- 

> 2.9.3

>

>

> _______________________________________________

> linux-arm-kernel mailing list

> linux-arm-kernel@lists.infradead.org

> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ard Biesheuvel Sept. 8, 2017, 1:54 p.m. | #2
On 8 September 2017 at 14:50, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi Ard,

>

>  On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>

>> To prevent unintended modifications to the kernel text (malicious or

>> otherwise) while running the EFI stub, describe the kernel image as

>> two separate sections: a .text section with read-execute permissions,

>> covering .text, .rodata, .piggytext and the GOT sections (which the

>> stub does not care about anyway), and a .data section with read-write

>> permissions, covering .data and .bss.

>>

>> This relies on the firmware to actually take the section permission

>> flags into account, but this is something that is currently being

>> implemented in EDK2, which means we will likely start seeing it in

>> the wild between one and two years from now.

>

> This patch had been merged in mainline yesterday and now prevent the

> Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect

> that more Socs are impacted because the number of boot fail exploded

> according to kci:

> https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

>


Ouch.

> I found this patch after bisecting (I can provide the bisect log if

> needed).

>

> The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in

> multi_v7_defconfig but not with mvebu_v7_defconfig.

>

> Currently the solution is to revert this patch.

>

> Have you a better option?

>


I will investigate.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ard Biesheuvel Sept. 8, 2017, 2:28 p.m. | #3
On 8 September 2017 at 14:54, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 8 September 2017 at 14:50, Gregory CLEMENT

> <gregory.clement@free-electrons.com> wrote:

>> Hi Ard,

>>

>>  On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>

>>> To prevent unintended modifications to the kernel text (malicious or

>>> otherwise) while running the EFI stub, describe the kernel image as

>>> two separate sections: a .text section with read-execute permissions,

>>> covering .text, .rodata, .piggytext and the GOT sections (which the

>>> stub does not care about anyway), and a .data section with read-write

>>> permissions, covering .data and .bss.

>>>

>>> This relies on the firmware to actually take the section permission

>>> flags into account, but this is something that is currently being

>>> implemented in EDK2, which means we will likely start seeing it in

>>> the wild between one and two years from now.

>>

>> This patch had been merged in mainline yesterday and now prevent the

>> Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect

>> that more Socs are impacted because the number of boot fail exploded

>> according to kci:

>> https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

>>

>

> Ouch.

>

>> I found this patch after bisecting (I can provide the bisect log if

>> needed).

>>

>> The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in

>> multi_v7_defconfig but not with mvebu_v7_defconfig.

>>

>> Currently the solution is to revert this patch.

>>

>> Have you a better option?

>>

>

> I will investigate.


I cannot reproduce this on QEMU or my Beaglebone white. I have tried a
locally built zImage as well as the one built by kernelci.

Could you please try whether this fixes things? It does not explain
anything but it will help me figure out what is going on (hopefully)


diff --git a/arch/arm/boot/compressed/efi-header.S
b/arch/arm/boot/compressed/efi-header.S
index c94a88ae834d..671a6e5b7b99 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -127,7 +127,7 @@ section_table:

                .set    section_count, (. - section_table) / 40

-               .align  12
+               .align  9
 __efi_start:
 #endif
                .endm
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gregory CLEMENT Sept. 8, 2017, 2:33 p.m. | #4
Hi Ard,
 
 On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> On 8 September 2017 at 14:54, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>> On 8 September 2017 at 14:50, Gregory CLEMENT

>> <gregory.clement@free-electrons.com> wrote:

>>> Hi Ard,

>>>

>>>  On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>

>>>> To prevent unintended modifications to the kernel text (malicious or

>>>> otherwise) while running the EFI stub, describe the kernel image as

>>>> two separate sections: a .text section with read-execute permissions,

>>>> covering .text, .rodata, .piggytext and the GOT sections (which the

>>>> stub does not care about anyway), and a .data section with read-write

>>>> permissions, covering .data and .bss.

>>>>

>>>> This relies on the firmware to actually take the section permission

>>>> flags into account, but this is something that is currently being

>>>> implemented in EDK2, which means we will likely start seeing it in

>>>> the wild between one and two years from now.

>>>

>>> This patch had been merged in mainline yesterday and now prevent the

>>> Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect

>>> that more Socs are impacted because the number of boot fail exploded

>>> according to kci:

>>> https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

>>>

>>

>> Ouch.

>>

>>> I found this patch after bisecting (I can provide the bisect log if

>>> needed).

>>>

>>> The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in

>>> multi_v7_defconfig but not with mvebu_v7_defconfig.

>>>

>>> Currently the solution is to revert this patch.

>>>

>>> Have you a better option?

>>>

>>

>> I will investigate.

>

> I cannot reproduce this on QEMU or my Beaglebone white. I have tried a

> locally built zImage as well as the one built by kernelci.

>

> Could you please try whether this fixes things? It does not explain

> anything but it will help me figure out what is going on (hopefully)


I've just tested this change and it didn't fix anything.

Gregory

>

>

> diff --git a/arch/arm/boot/compressed/efi-header.S

> b/arch/arm/boot/compressed/efi-header.S

> index c94a88ae834d..671a6e5b7b99 100644

> --- a/arch/arm/boot/compressed/efi-header.S

> +++ b/arch/arm/boot/compressed/efi-header.S

> @@ -127,7 +127,7 @@ section_table:

>

>                 .set    section_count, (. - section_table) / 40

>

> -               .align  12

> +               .align  9

>  __efi_start:

>  #endif

>                 .endm


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ard Biesheuvel Sept. 8, 2017, 2:48 p.m. | #5
On 8 September 2017 at 15:33, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi Ard,

>

>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>

>> On 8 September 2017 at 14:54, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>> On 8 September 2017 at 14:50, Gregory CLEMENT

>>> <gregory.clement@free-electrons.com> wrote:

>>>> Hi Ard,

>>>>

>>>>  On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>

>>>>> To prevent unintended modifications to the kernel text (malicious or

>>>>> otherwise) while running the EFI stub, describe the kernel image as

>>>>> two separate sections: a .text section with read-execute permissions,

>>>>> covering .text, .rodata, .piggytext and the GOT sections (which the

>>>>> stub does not care about anyway), and a .data section with read-write

>>>>> permissions, covering .data and .bss.

>>>>>

>>>>> This relies on the firmware to actually take the section permission

>>>>> flags into account, but this is something that is currently being

>>>>> implemented in EDK2, which means we will likely start seeing it in

>>>>> the wild between one and two years from now.

>>>>

>>>> This patch had been merged in mainline yesterday and now prevent the

>>>> Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect

>>>> that more Socs are impacted because the number of boot fail exploded

>>>> according to kci:

>>>> https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

>>>>

>>>

>>> Ouch.

>>>

>>>> I found this patch after bisecting (I can provide the bisect log if

>>>> needed).

>>>>

>>>> The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in

>>>> multi_v7_defconfig but not with mvebu_v7_defconfig.

>>>>

>>>> Currently the solution is to revert this patch.

>>>>

>>>> Have you a better option?

>>>>

>>>

>>> I will investigate.

>>

>> I cannot reproduce this on QEMU or my Beaglebone white. I have tried a

>> locally built zImage as well as the one built by kernelci.

>>

>> Could you please try whether this fixes things? It does not explain

>> anything but it will help me figure out what is going on (hopefully)

>

> I've just tested this change and it didn't fix anything.

>

> Gregory

>

>>

>>

>> diff --git a/arch/arm/boot/compressed/efi-header.S

>> b/arch/arm/boot/compressed/efi-header.S

>> index c94a88ae834d..671a6e5b7b99 100644

>> --- a/arch/arm/boot/compressed/efi-header.S

>> +++ b/arch/arm/boot/compressed/efi-header.S

>> @@ -127,7 +127,7 @@ section_table:

>>

>>                 .set    section_count, (. - section_table) / 40

>>

>> -               .align  12

>> +               .align  9

>>  __efi_start:

>>  #endif

>>                 .endm

>



How about this?

diff --git a/arch/arm/boot/compressed/vmlinux.lds.S
b/arch/arm/boot/compressed/vmlinux.lds.S
index 7a4c59154361..dfcc2baa0077 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -29,6 +29,11 @@ SECTIONS
      * of the text/got segments.
      */
     *(.data)
+    /*
+     * C code that is shared with the kernel proper (but rebuilt for the
+     * decompressor) may contain exports that we have no use for here.
+     */
+    *(*ksymtab* *kcrctab*)
   }

   . = TEXT_START;
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gregory CLEMENT Sept. 8, 2017, 2:56 p.m. | #6
Hi Ard,
 
 On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> On 8 September 2017 at 15:33, Gregory CLEMENT

> <gregory.clement@free-electrons.com> wrote:

>> Hi Ard,

>>

>>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>

>>> On 8 September 2017 at 14:54, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>> On 8 September 2017 at 14:50, Gregory CLEMENT

>>>> <gregory.clement@free-electrons.com> wrote:

>>>>> Hi Ard,

>>>>>

>>>>>  On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>

>>>>>> To prevent unintended modifications to the kernel text (malicious or

>>>>>> otherwise) while running the EFI stub, describe the kernel image as

>>>>>> two separate sections: a .text section with read-execute permissions,

>>>>>> covering .text, .rodata, .piggytext and the GOT sections (which the

>>>>>> stub does not care about anyway), and a .data section with read-write

>>>>>> permissions, covering .data and .bss.

>>>>>>

>>>>>> This relies on the firmware to actually take the section permission

>>>>>> flags into account, but this is something that is currently being

>>>>>> implemented in EDK2, which means we will likely start seeing it in

>>>>>> the wild between one and two years from now.

>>>>>

>>>>> This patch had been merged in mainline yesterday and now prevent the

>>>>> Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect

>>>>> that more Socs are impacted because the number of boot fail exploded

>>>>> according to kci:

>>>>> https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

>>>>>

>>>>

>>>> Ouch.

>>>>

>>>>> I found this patch after bisecting (I can provide the bisect log if

>>>>> needed).

>>>>>

>>>>> The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in

>>>>> multi_v7_defconfig but not with mvebu_v7_defconfig.

>>>>>

>>>>> Currently the solution is to revert this patch.

>>>>>

>>>>> Have you a better option?

>>>>>

>>>>

>>>> I will investigate.

>>>

>>> I cannot reproduce this on QEMU or my Beaglebone white. I have tried a

>>> locally built zImage as well as the one built by kernelci.

>>>

>>> Could you please try whether this fixes things? It does not explain

>>> anything but it will help me figure out what is going on (hopefully)

>>

>> I've just tested this change and it didn't fix anything.

>>

>> Gregory

>>

>>>

>>>

>>> diff --git a/arch/arm/boot/compressed/efi-header.S

>>> b/arch/arm/boot/compressed/efi-header.S

>>> index c94a88ae834d..671a6e5b7b99 100644

>>> --- a/arch/arm/boot/compressed/efi-header.S

>>> +++ b/arch/arm/boot/compressed/efi-header.S

>>> @@ -127,7 +127,7 @@ section_table:

>>>

>>>                 .set    section_count, (. - section_table) / 40

>>>

>>> -               .align  12

>>> +               .align  9

>>>  __efi_start:

>>>  #endif

>>>                 .endm

>>

>

>

> How about this?


It fixed the bug! (I tested with and without your previous patch and it
worked in both case)

When you will send your patch, you can add my:
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>


Thanks,

Gregory


>

> diff --git a/arch/arm/boot/compressed/vmlinux.lds.S

> b/arch/arm/boot/compressed/vmlinux.lds.S

> index 7a4c59154361..dfcc2baa0077 100644

> --- a/arch/arm/boot/compressed/vmlinux.lds.S

> +++ b/arch/arm/boot/compressed/vmlinux.lds.S

> @@ -29,6 +29,11 @@ SECTIONS

>       * of the text/got segments.

>       */

>      *(.data)

> +    /*

> +     * C code that is shared with the kernel proper (but rebuilt for the

> +     * decompressor) may contain exports that we have no use for here.

> +     */

> +    *(*ksymtab* *kcrctab*)

>    }

>

>    . = TEXT_START;

>

> _______________________________________________

> linux-arm-kernel mailing list

> linux-arm-kernel@lists.infradead.org

> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ard Biesheuvel Sept. 8, 2017, 2:57 p.m. | #7
On 8 September 2017 at 15:56, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi Ard,

>

>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>

>> On 8 September 2017 at 15:33, Gregory CLEMENT

>> <gregory.clement@free-electrons.com> wrote:

>>> Hi Ard,

>>>

>>>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>

>>>> On 8 September 2017 at 14:54, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>> On 8 September 2017 at 14:50, Gregory CLEMENT

>>>>> <gregory.clement@free-electrons.com> wrote:

>>>>>> Hi Ard,

>>>>>>

>>>>>>  On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>>

>>>>>>> To prevent unintended modifications to the kernel text (malicious or

>>>>>>> otherwise) while running the EFI stub, describe the kernel image as

>>>>>>> two separate sections: a .text section with read-execute permissions,

>>>>>>> covering .text, .rodata, .piggytext and the GOT sections (which the

>>>>>>> stub does not care about anyway), and a .data section with read-write

>>>>>>> permissions, covering .data and .bss.

>>>>>>>

>>>>>>> This relies on the firmware to actually take the section permission

>>>>>>> flags into account, but this is something that is currently being

>>>>>>> implemented in EDK2, which means we will likely start seeing it in

>>>>>>> the wild between one and two years from now.

>>>>>>

>>>>>> This patch had been merged in mainline yesterday and now prevent the

>>>>>> Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect

>>>>>> that more Socs are impacted because the number of boot fail exploded

>>>>>> according to kci:

>>>>>> https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

>>>>>>

>>>>>

>>>>> Ouch.

>>>>>

>>>>>> I found this patch after bisecting (I can provide the bisect log if

>>>>>> needed).

>>>>>>

>>>>>> The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in

>>>>>> multi_v7_defconfig but not with mvebu_v7_defconfig.

>>>>>>

>>>>>> Currently the solution is to revert this patch.

>>>>>>

>>>>>> Have you a better option?

>>>>>>

>>>>>

>>>>> I will investigate.

>>>>

>>>> I cannot reproduce this on QEMU or my Beaglebone white. I have tried a

>>>> locally built zImage as well as the one built by kernelci.

>>>>

>>>> Could you please try whether this fixes things? It does not explain

>>>> anything but it will help me figure out what is going on (hopefully)

>>>

>>> I've just tested this change and it didn't fix anything.

>>>

>>> Gregory

>>>

>>>>

>>>>

>>>> diff --git a/arch/arm/boot/compressed/efi-header.S

>>>> b/arch/arm/boot/compressed/efi-header.S

>>>> index c94a88ae834d..671a6e5b7b99 100644

>>>> --- a/arch/arm/boot/compressed/efi-header.S

>>>> +++ b/arch/arm/boot/compressed/efi-header.S

>>>> @@ -127,7 +127,7 @@ section_table:

>>>>

>>>>                 .set    section_count, (. - section_table) / 40

>>>>

>>>> -               .align  12

>>>> +               .align  9

>>>>  __efi_start:

>>>>  #endif

>>>>                 .endm

>>>

>>

>>

>> How about this?

>

> It fixed the bug! (I tested with and without your previous patch and it

> worked in both case)

>

> When you will send your patch, you can add my:

> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

>

> Thanks,

>

> Gregory

>


Thanks a lot. I will send it out today.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ard Biesheuvel Sept. 8, 2017, 3:11 p.m. | #8
On 8 September 2017 at 15:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 8 September 2017 at 15:56, Gregory CLEMENT

> <gregory.clement@free-electrons.com> wrote:

>> Hi Ard,

>>

>>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>

>>> On 8 September 2017 at 15:33, Gregory CLEMENT

>>> <gregory.clement@free-electrons.com> wrote:

>>>> Hi Ard,

>>>>

>>>>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>

>>>>> On 8 September 2017 at 14:54, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>> On 8 September 2017 at 14:50, Gregory CLEMENT

>>>>>> <gregory.clement@free-electrons.com> wrote:

>>>>>>> Hi Ard,

>>>>>>>

>>>>>>>  On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>>>

>>>>>>>> To prevent unintended modifications to the kernel text (malicious or

>>>>>>>> otherwise) while running the EFI stub, describe the kernel image as

>>>>>>>> two separate sections: a .text section with read-execute permissions,

>>>>>>>> covering .text, .rodata, .piggytext and the GOT sections (which the

>>>>>>>> stub does not care about anyway), and a .data section with read-write

>>>>>>>> permissions, covering .data and .bss.

>>>>>>>>

>>>>>>>> This relies on the firmware to actually take the section permission

>>>>>>>> flags into account, but this is something that is currently being

>>>>>>>> implemented in EDK2, which means we will likely start seeing it in

>>>>>>>> the wild between one and two years from now.

>>>>>>>

>>>>>>> This patch had been merged in mainline yesterday and now prevent the

>>>>>>> Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect

>>>>>>> that more Socs are impacted because the number of boot fail exploded

>>>>>>> according to kci:

>>>>>>> https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

>>>>>>>

>>>>>>

>>>>>> Ouch.

>>>>>>

>>>>>>> I found this patch after bisecting (I can provide the bisect log if

>>>>>>> needed).

>>>>>>>

>>>>>>> The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in

>>>>>>> multi_v7_defconfig but not with mvebu_v7_defconfig.

>>>>>>>

>>>>>>> Currently the solution is to revert this patch.

>>>>>>>

>>>>>>> Have you a better option?

>>>>>>>

>>>>>>

>>>>>> I will investigate.

>>>>>

>>>>> I cannot reproduce this on QEMU or my Beaglebone white. I have tried a

>>>>> locally built zImage as well as the one built by kernelci.

>>>>>

>>>>> Could you please try whether this fixes things? It does not explain

>>>>> anything but it will help me figure out what is going on (hopefully)

>>>>

>>>> I've just tested this change and it didn't fix anything.

>>>>

>>>> Gregory

>>>>

>>>>>

>>>>>

>>>>> diff --git a/arch/arm/boot/compressed/efi-header.S

>>>>> b/arch/arm/boot/compressed/efi-header.S

>>>>> index c94a88ae834d..671a6e5b7b99 100644

>>>>> --- a/arch/arm/boot/compressed/efi-header.S

>>>>> +++ b/arch/arm/boot/compressed/efi-header.S

>>>>> @@ -127,7 +127,7 @@ section_table:

>>>>>

>>>>>                 .set    section_count, (. - section_table) / 40

>>>>>

>>>>> -               .align  12

>>>>> +               .align  9

>>>>>  __efi_start:

>>>>>  #endif

>>>>>                 .endm

>>>>

>>>

>>>

>>> How about this?

>>

>> It fixed the bug! (I tested with and without your previous patch and it

>> worked in both case)

>>

>> When you will send your patch, you can add my:

>> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

>>


Would you mind checking whether this fixes the issue as well?

diff --git a/arch/arm/boot/compressed/piggy.S b/arch/arm/boot/compressed/piggy.S
index f72088495f43..5d52c556dd32 100644
--- a/arch/arm/boot/compressed/piggy.S
+++ b/arch/arm/boot/compressed/piggy.S
@@ -1,5 +1,6 @@
        .section .piggydata,#alloc
        .globl  input_data
+       .align  2
 input_data:
        .incbin "arch/arm/boot/compressed/piggy_data"
        .globl  input_data_end

There may be other reasons than ksymtab entries that could result in
piggydata ending up unaligned in the decompressor (which is what
caused the issue before)
This is a better fix, because it addresses the root cause.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gregory CLEMENT Sept. 8, 2017, 3:17 p.m. | #9
Hi Ard,
 
 On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> On 8 September 2017 at 15:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>> On 8 September 2017 at 15:56, Gregory CLEMENT

>> <gregory.clement@free-electrons.com> wrote:

>>> Hi Ard,

>>>

>>>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>

>>>> On 8 September 2017 at 15:33, Gregory CLEMENT

>>>> <gregory.clement@free-electrons.com> wrote:

>>>>> Hi Ard,

>>>>>

>>>>>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>

>>>>>> On 8 September 2017 at 14:54, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>>> On 8 September 2017 at 14:50, Gregory CLEMENT

>>>>>>> <gregory.clement@free-electrons.com> wrote:

>>>>>>>> Hi Ard,

>>>>>>>>

>>>>>>>>  On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>>>>

>>>>>>>>> To prevent unintended modifications to the kernel text (malicious or

>>>>>>>>> otherwise) while running the EFI stub, describe the kernel image as

>>>>>>>>> two separate sections: a .text section with read-execute permissions,

>>>>>>>>> covering .text, .rodata, .piggytext and the GOT sections (which the

>>>>>>>>> stub does not care about anyway), and a .data section with read-write

>>>>>>>>> permissions, covering .data and .bss.

>>>>>>>>>

>>>>>>>>> This relies on the firmware to actually take the section permission

>>>>>>>>> flags into account, but this is something that is currently being

>>>>>>>>> implemented in EDK2, which means we will likely start seeing it in

>>>>>>>>> the wild between one and two years from now.

>>>>>>>>

>>>>>>>> This patch had been merged in mainline yesterday and now prevent the

>>>>>>>> Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect

>>>>>>>> that more Socs are impacted because the number of boot fail exploded

>>>>>>>> according to kci:

>>>>>>>> https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

>>>>>>>>

>>>>>>>

>>>>>>> Ouch.

>>>>>>>

>>>>>>>> I found this patch after bisecting (I can provide the bisect log if

>>>>>>>> needed).

>>>>>>>>

>>>>>>>> The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in

>>>>>>>> multi_v7_defconfig but not with mvebu_v7_defconfig.

>>>>>>>>

>>>>>>>> Currently the solution is to revert this patch.

>>>>>>>>

>>>>>>>> Have you a better option?

>>>>>>>>

>>>>>>>

>>>>>>> I will investigate.

>>>>>>

>>>>>> I cannot reproduce this on QEMU or my Beaglebone white. I have tried a

>>>>>> locally built zImage as well as the one built by kernelci.

>>>>>>

>>>>>> Could you please try whether this fixes things? It does not explain

>>>>>> anything but it will help me figure out what is going on (hopefully)

>>>>>

>>>>> I've just tested this change and it didn't fix anything.

>>>>>

>>>>> Gregory

>>>>>

>>>>>>

>>>>>>

>>>>>> diff --git a/arch/arm/boot/compressed/efi-header.S

>>>>>> b/arch/arm/boot/compressed/efi-header.S

>>>>>> index c94a88ae834d..671a6e5b7b99 100644

>>>>>> --- a/arch/arm/boot/compressed/efi-header.S

>>>>>> +++ b/arch/arm/boot/compressed/efi-header.S

>>>>>> @@ -127,7 +127,7 @@ section_table:

>>>>>>

>>>>>>                 .set    section_count, (. - section_table) / 40

>>>>>>

>>>>>> -               .align  12

>>>>>> +               .align  9

>>>>>>  __efi_start:

>>>>>>  #endif

>>>>>>                 .endm

>>>>>

>>>>

>>>>

>>>> How about this?

>>>

>>> It fixed the bug! (I tested with and without your previous patch and it

>>> worked in both case)

>>>

>>> When you will send your patch, you can add my:

>>> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

>>>

>

> Would you mind checking whether this fixes the issue as well?

>

> diff --git a/arch/arm/boot/compressed/piggy.S b/arch/arm/boot/compressed/piggy.S

> index f72088495f43..5d52c556dd32 100644

> --- a/arch/arm/boot/compressed/piggy.S

> +++ b/arch/arm/boot/compressed/piggy.S

> @@ -1,5 +1,6 @@

>         .section .piggydata,#alloc

>         .globl  input_data

> +       .align  2

>  input_data:

>         .incbin "arch/arm/boot/compressed/piggy_data"

>         .globl  input_data_end

>

> There may be other reasons than ksymtab entries that could result in

> piggydata ending up unaligned in the decompressor (which is what

> caused the issue before)

> This is a better fix, because it addresses the root cause.


I've tested this single patch and it does not fix the boot issue :(

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ard Biesheuvel Sept. 8, 2017, 3:18 p.m. | #10
On 8 September 2017 at 16:17, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi Ard,

>

>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>

>> On 8 September 2017 at 15:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>> On 8 September 2017 at 15:56, Gregory CLEMENT

>>> <gregory.clement@free-electrons.com> wrote:

>>>> Hi Ard,

>>>>

>>>>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>

>>>>> On 8 September 2017 at 15:33, Gregory CLEMENT

>>>>> <gregory.clement@free-electrons.com> wrote:

>>>>>> Hi Ard,

>>>>>>

>>>>>>  On ven., sept. 08 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>>

>>>>>>> On 8 September 2017 at 14:54, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>>>> On 8 September 2017 at 14:50, Gregory CLEMENT

>>>>>>>> <gregory.clement@free-electrons.com> wrote:

>>>>>>>>> Hi Ard,

>>>>>>>>>

>>>>>>>>>  On jeu., juin 29 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

>>>>>>>>>

>>>>>>>>>> To prevent unintended modifications to the kernel text (malicious or

>>>>>>>>>> otherwise) while running the EFI stub, describe the kernel image as

>>>>>>>>>> two separate sections: a .text section with read-execute permissions,

>>>>>>>>>> covering .text, .rodata, .piggytext and the GOT sections (which the

>>>>>>>>>> stub does not care about anyway), and a .data section with read-write

>>>>>>>>>> permissions, covering .data and .bss.

>>>>>>>>>>

>>>>>>>>>> This relies on the firmware to actually take the section permission

>>>>>>>>>> flags into account, but this is something that is currently being

>>>>>>>>>> implemented in EDK2, which means we will likely start seeing it in

>>>>>>>>>> the wild between one and two years from now.

>>>>>>>>>

>>>>>>>>> This patch had been merged in mainline yesterday and now prevent the

>>>>>>>>> Marvell Armada 370 and the Armada XP based SoC to boot. I also suspect

>>>>>>>>> that more Socs are impacted because the number of boot fail exploded

>>>>>>>>> according to kci:

>>>>>>>>> https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.13-8899-g8dc5b3a6cb2f/

>>>>>>>>>

>>>>>>>>

>>>>>>>> Ouch.

>>>>>>>>

>>>>>>>>> I found this patch after bisecting (I can provide the bisect log if

>>>>>>>>> needed).

>>>>>>>>>

>>>>>>>>> The kernel failed to boot only if CONFIG_EFI is enabled so it occurs in

>>>>>>>>> multi_v7_defconfig but not with mvebu_v7_defconfig.

>>>>>>>>>

>>>>>>>>> Currently the solution is to revert this patch.

>>>>>>>>>

>>>>>>>>> Have you a better option?

>>>>>>>>>

>>>>>>>>

>>>>>>>> I will investigate.

>>>>>>>

>>>>>>> I cannot reproduce this on QEMU or my Beaglebone white. I have tried a

>>>>>>> locally built zImage as well as the one built by kernelci.

>>>>>>>

>>>>>>> Could you please try whether this fixes things? It does not explain

>>>>>>> anything but it will help me figure out what is going on (hopefully)

>>>>>>

>>>>>> I've just tested this change and it didn't fix anything.

>>>>>>

>>>>>> Gregory

>>>>>>

>>>>>>>

>>>>>>>

>>>>>>> diff --git a/arch/arm/boot/compressed/efi-header.S

>>>>>>> b/arch/arm/boot/compressed/efi-header.S

>>>>>>> index c94a88ae834d..671a6e5b7b99 100644

>>>>>>> --- a/arch/arm/boot/compressed/efi-header.S

>>>>>>> +++ b/arch/arm/boot/compressed/efi-header.S

>>>>>>> @@ -127,7 +127,7 @@ section_table:

>>>>>>>

>>>>>>>                 .set    section_count, (. - section_table) / 40

>>>>>>>

>>>>>>> -               .align  12

>>>>>>> +               .align  9

>>>>>>>  __efi_start:

>>>>>>>  #endif

>>>>>>>                 .endm

>>>>>>

>>>>>

>>>>>

>>>>> How about this?

>>>>

>>>> It fixed the bug! (I tested with and without your previous patch and it

>>>> worked in both case)

>>>>

>>>> When you will send your patch, you can add my:

>>>> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

>>>>

>>

>> Would you mind checking whether this fixes the issue as well?

>>

>> diff --git a/arch/arm/boot/compressed/piggy.S b/arch/arm/boot/compressed/piggy.S

>> index f72088495f43..5d52c556dd32 100644

>> --- a/arch/arm/boot/compressed/piggy.S

>> +++ b/arch/arm/boot/compressed/piggy.S

>> @@ -1,5 +1,6 @@

>>         .section .piggydata,#alloc

>>         .globl  input_data

>> +       .align  2

>>  input_data:

>>         .incbin "arch/arm/boot/compressed/piggy_data"

>>         .globl  input_data_end

>>

>> There may be other reasons than ksymtab entries that could result in

>> piggydata ending up unaligned in the decompressor (which is what

>> caused the issue before)

>> This is a better fix, because it addresses the root cause.

>

> I've tested this single patch and it does not fix the boot issue :(

>


OK, strange. Anyway, thanks for testing. I will post the original fix then.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
index 542e1ad432ae..c94a88ae834d 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -54,20 +54,22 @@  coff_header:
 			IMAGE_FILE_EXECUTABLE_IMAGE | \
 			IMAGE_FILE_LINE_NUMS_STRIPPED	@ Characteristics
 
+#define __pecoff_code_size (__pecoff_data_start - __efi_start)
+
 optional_header:
 		.short	PE_OPT_MAGIC_PE32		@ PE32 format
 		.byte	0x02				@ MajorLinkerVersion
 		.byte	0x14				@ MinorLinkerVersion
-		.long	_end - __efi_start		@ SizeOfCode
-		.long	0				@ SizeOfInitializedData
+		.long	__pecoff_code_size		@ SizeOfCode
+		.long	__pecoff_data_size		@ SizeOfInitializedData
 		.long	0				@ SizeOfUninitializedData
 		.long	efi_stub_entry - start		@ AddressOfEntryPoint
 		.long	start_offset			@ BaseOfCode
-		.long	0				@ BaseOfData
+		.long	__pecoff_data_start - start	@ BaseOfData
 
 extra_header_fields:
 		.long	0				@ ImageBase
-		.long	SZ_512				@ SectionAlignment
+		.long	SZ_4K				@ SectionAlignment
 		.long	SZ_512				@ FileAlignment
 		.short	0				@ MajorOsVersion
 		.short	0				@ MinorOsVersion
@@ -77,7 +79,7 @@  extra_header_fields:
 		.short	0				@ MinorSubsystemVersion
 		.long	0				@ Win32VersionValue
 
-		.long	_end - start			@ SizeOfImage
+		.long	__pecoff_end - start		@ SizeOfImage
 		.long	start_offset			@ SizeOfHeaders
 		.long	0				@ CheckSum
 		.short	IMAGE_SUBSYSTEM_EFI_APPLICATION	@ Subsystem
@@ -98,9 +100,9 @@  extra_header_fields:
 
 section_table:
 		.ascii	".text\0\0\0"
-		.long	_end - __efi_start		@ VirtualSize
+		.long	__pecoff_code_size		@ VirtualSize
 		.long	__efi_start			@ VirtualAddress
-		.long	_edata - __efi_start		@ SizeOfRawData
+		.long	__pecoff_code_size		@ SizeOfRawData
 		.long	__efi_start			@ PointerToRawData
 		.long	0				@ PointerToRelocations
 		.long	0				@ PointerToLineNumbers
@@ -108,12 +110,24 @@  section_table:
 		.short	0				@ NumberOfLineNumbers
 		.long	IMAGE_SCN_CNT_CODE | \
 			IMAGE_SCN_MEM_READ | \
-			IMAGE_SCN_MEM_WRITE | \
 			IMAGE_SCN_MEM_EXECUTE		@ Characteristics
 
+		.ascii	".data\0\0\0"
+		.long	__pecoff_data_size		@ VirtualSize
+		.long	__pecoff_data_start - start	@ VirtualAddress
+		.long	__pecoff_data_rawsize		@ SizeOfRawData
+		.long	__pecoff_data_start - start	@ PointerToRawData
+		.long	0				@ PointerToRelocations
+		.long	0				@ PointerToLineNumbers
+		.short	0				@ NumberOfRelocations
+		.short	0				@ NumberOfLineNumbers
+		.long	IMAGE_SCN_CNT_INITIALIZED_DATA | \
+			IMAGE_SCN_MEM_READ | \
+			IMAGE_SCN_MEM_WRITE		@ Characteristics
+
 		.set	section_count, (. - section_table) / 40
 
-		.align	9
+		.align	12
 __efi_start:
 #endif
 		.endm
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S b/arch/arm/boot/compressed/vmlinux.lds.S
index 1fa62432e283..dfcc2baa0077 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -53,13 +53,6 @@  SECTIONS
     *(.rodata)
     *(.rodata.*)
   }
-  .data : {
-    /*
-     * The EFI stub always executes from RAM, and runs strictly before the
-     * decompressor, so we can make an exception for its r/w data, and keep it
-     */
-    *(.data.efistub)
-  }
   .piggydata : {
     *(.piggydata)
   }
@@ -75,6 +68,26 @@  SECTIONS
   /* ensure the zImage file size is always a multiple of 64 bits */
   /* (without a dummy byte, ld just ignores the empty section) */
   .pad			: { BYTE(0); . = ALIGN(8); }
+
+#ifdef CONFIG_EFI_STUB
+  .data : ALIGN(4096) {
+    __pecoff_data_start = .;
+    /*
+     * The EFI stub always executes from RAM, and runs strictly before the
+     * decompressor, so we can make an exception for its r/w data, and keep it
+     */
+    *(.data.efistub)
+    __pecoff_data_end = .;
+
+    /*
+     * PE/COFF mandates a file size which is a multiple of 512 bytes if the
+     * section size equals or exceeds 4 KB
+     */
+    . = ALIGN(512);
+  }
+  __pecoff_data_rawsize = . - ADDR(.data);
+#endif
+
   _edata = .;
 
   _magic_sig = ZIMAGE_MAGIC(0x016f2818);
@@ -89,6 +102,9 @@  SECTIONS
   . = ALIGN(8);		/* the stack must be 64-bit aligned */
   .stack		: { *(.stack) }
 
+  PROVIDE(__pecoff_data_size = ALIGN(512) - ADDR(.data));
+  PROVIDE(__pecoff_end = ALIGN(512));
+
   .stab 0		: { *(.stab) }
   .stabstr 0		: { *(.stabstr) }
   .stab.excl 0		: { *(.stab.excl) }