[PATCH] ARM: compressed: discard ksym/kcrctab input section

[Matthias Brugger]

On 10/23/2017 01:48 PM, Russell King - ARM Linux wrote:
> On Mon, Oct 23, 2017 at 10:29:56AM +0100, Russell King - ARM Linux wrote:
>> On Mon, Oct 23, 2017 at 12:00:46AM +0200, Matthias Brugger wrote:
>>> Hi Ard,
>>>
>>> On 10/21/2017 10:14 AM, Ard Biesheuvel wrote:
>>>> On 21 October 2017 at 08:56, Matthias Brugger <mbrugger at suse.com> wrote:
>>>>> On 09/08/2017 05:31 PM, Ard Biesheuvel wrote:
>>>>>> As it turns out, building the ARM kernel with EFI support pulls in
>>>>>> a couple of sections that we don't really need in the decompressor.
>>>>>> This is due to the fact the the UEFI stub uses sort() to sort the UEFI
>>>>>> memory map, which is an exported symbol pulled in from lib/sort.c.
>>>>>>
>>>>>> Before commit e4bae4d0b5f3 ("arm/efi: Split zImage code and data into
>>>>>> separate PE/COFF sections"), this resulted in the following layout
>>>>>> for the decompressor ELF binary.
>>>>>>
>>>>>>   [Nr] Name              Type     Addr     Off    Size   ES Flg Lk Inf Al
>>>>>>   [ 0]                   NULL     00000000 000000 000000 00      0   0  0
>>>>>>   [ 1] .text             PROGBITS 00000000 010000 009b3c 00  AX  0   0 512
>>>>>>   [ 2] .rodata           PROGBITS 00009b3c 019b3c 001684 00   A  0   0  4
>>>>>>   [ 3] __ksymtab_strings PROGBITS 0000b1c0 01b1c0 000005 00   A  0   0  1
>>>>>>   [ 4] .data             PROGBITS 0000b1c8 01b1c8 000020 00  WA  0   0  8
>>>>>>   [ 5] ___ksymtab+sort   PROGBITS 0000b1e8 01b1e8 000008 00  WA  0   0  4
>>>>>>   [ 6] .piggydata        PROGBITS 0000b1f0 01b1f0 77ac38 00   A  0   0  1
>>>>>>   [ 7] .got.plt          PROGBITS 00785e28 795e28 00000c 04  WA  0   0  4
>>>>>>   [ 8] .got              PROGBITS 00785e34 795e34 000028 00  WA  0   0  4
>>>>>>   [ 9] .pad              PROGBITS 00785e5c 795e5c 000004 00  WA  0   0  1
>>>>>>   [10] .bss              NOBITS   00785e60 795e60 00001c 00  WA  0   0  4
>>>>>>   [11] .stack            NOBITS   00785e80 795e60 001000 00  WA  0   0  1
>>>>>>
>>>>>> Commit e4bae4d0b5f3 made some changes to the linker script to allow the
>>>>>> UEFI firmware to map the decompressor with strict R-X/RW- permissions
>>>>>> before invoking it. Unfortunately, this turns out to break the boot on
>>>>>> some systems, because the linker now also moves the ksymtab/kcrctab
>>>>>> sections around, resulting in .piggydata to appear misaligned.
>>>>>>
>>>>>>   [Nr] Name              Type     Addr     Off    Size   ES Flg Lk Inf Al
>>>>>>   [ 0]                   NULL     00000000 000000 000000 00      0   0  0
>>>>>>   [ 1] .text             PROGBITS 00000000 010000 00a93c 00  AX  0   0 4096
>>>>>>   [ 2] .rodata           PROGBITS 0000a93c 01a93c 001684 00   A  0   0  4
>>>>>>   [ 3] __ksymtab_strings PROGBITS 0000bfc0 01bfc0 000005 00   A  0   0  1
>>>>>>   [ 4] .piggydata        PROGBITS 0000bfc5 01bfc5 77ac47 00   A  0   0  1
>>>>>>   [ 5] .got.plt          PROGBITS 00786c0c 796c0c 00000c 04  WA  0   0  4
>>>>>>   [ 6] .got              PROGBITS 00786c18 796c18 000028 00  WA  0   0  4
>>>>>>   [ 7] .pad              PROGBITS 00786c40 796c40 000008 00  WA  0   0  1
>>>>>>   [ 8] .data             PROGBITS 00787000 797000 000200 00  WA  0   0 4096
>>>>>>   [ 9] ___ksymtab+sort   PROGBITS 00787200 797200 000008 00  WA  0   0  4
>>>>>>   [10] .bss              NOBITS   00787208 797208 00001c 00  WA  0   0  4
>>>>>>   [11] .stack            NOBITS   00787228 797208 001000 00  WA  0   0  1
>>>>>>
>>>>>> So let's align piggydata explicitly, and discard these sections from the
>>>>>> binary.
>>>>>>
>>>>>> Cc: Russell King <linux at armlinux.org.uk>
>>>>>> Fixes: e4bae4d0b5f3 ("arm/efi: Split zImage code and data into separate ...")
>>>>>> Tested-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>>>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>>>>> ---
>>>>>>  arch/arm/boot/compressed/piggy.S       | 1 +
>>>>>>  arch/arm/boot/compressed/vmlinux.lds.S | 1 +
>>>>>>  2 files changed, 2 insertions(+)
>>>>>>
>>>>>
>>>>> This fixes the boot regression on bananapi-r2.
>>>>> Thanks! Feel free to add:
>>>>>
>>>>> Tested-by: Matthias Brugger <mbrugger at suse.com>
>>>>>
>>>>
>>>> Thanks for confirming Matthias. Could you please check whether this
>>>> patch from Arnd
>>>>
>>>> https://marc.info/?l=linux-kernel&m=150852980119217&w=2
>>>>
>>>> fixes the issue as well? (after reverting this one)
>>>>
>>>
>>> After only applying this patch on top of v4.14-rc5 I was not able to boot.
>>
>> Which decompression method are you using?
>>
>> What does objdump -h arch/arm/boot/vmlinux say?
> 
> Oh, and one more question: are you appending a dtb to your zImage (and
> if so, why are you doing that, that's supposed to be for obsolete boot
> loaders only.)
> 

Yes, I apply a dtb to my zImage. I do that because the board has no support on
mainline u-boot right now and I do kernel enablement on the board. Support in
u-boot is no priority ATM.

Regards,
Matthias