This is a note to let you know that I've just added the patch titled

arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27

to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...

The filename of the patch is: arm64-prevent-regressions-in-compressed-kernel-image-size-when-upgrading-to-binutils-2.27.patch and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.

From foo@baz Mon Dec 18 13:28:59 CET 2017

From: Nick Desaulniers ndesaulniers@google.com Date: Fri, 27 Oct 2017 09:33:41 -0700 Subject: arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27

From: Nick Desaulniers ndesaulniers@google.com

[ Upstream commit fd9dde6abcb9bfe6c6bee48834e157999f113971 ]

Upon upgrading to binutils 2.27, we found that our lz4 and gzip compressed kernel images were significantly larger, resulting is 10ms boot time regressions.

As noted by Rahul: "aarch64 binaries uses RELA relocations, where each relocation entry includes an addend value. This is similar to x86_64. On x86_64, the addend values are also stored at the relocation offset for relative relocations. This is an optimization: in the case where code does not need to be relocated, the loader can simply skip processing relative relocations. In binutils-2.25, both bfd and gold linkers did this for x86_64, but only the gold linker did this for aarch64. The kernel build here is using the bfd linker, which stored zeroes at the relocation offsets for relative relocations. Since a set of zeroes compresses better than a set of non-zero addend values, this behavior was resulting in much better lz4 compression.

The bfd linker in binutils-2.27 is now storing the actual addend values at the relocation offsets. The behavior is now consistent with what it does for x86_64 and what gold linker does for both architectures. The change happened in this upstream commit: https://sourceware.org/git/?p=binutils-gdb.git%3Ba=commit%3Bh=1f56df9d0d5ad8... Since a bunch of zeroes got replaced by non-zero addend values, we see the side effect of lz4 compressed image being a bit bigger.

To get the old behavior from the bfd linker, "--no-apply-dynamic-relocs" flag can be used: $ LDFLAGS="--no-apply-dynamic-relocs" make With this flag, the compressed image size is back to what it was with binutils-2.25.

If the kernel is using ASLR, there aren't additional runtime costs to --no-apply-dynamic-relocs, as the relocations will need to be applied again anyway after the kernel is relocated to a random address.

If the kernel is not using ASLR, then presumably the current default behavior of the linker is better. Since the static linker performed the dynamic relocs, and the kernel is not moved to a different address at load time, it can skip applying the relocations all over again."

Some measurements:

$ ld -v GNU ld (binutils-2.25-f3d35cf6) 2.25.51.20141117 ^ $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300652760 Oct 26 11:57 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932627 Oct 26 11:57 Image.lz4-dtb

$ ld -v GNU ld (binutils-2.27-53dd00a1) 2.27.0.20170315 ^ pre patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 11:43 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 18159474 Oct 26 11:43 Image.lz4-dtb

post patch: $ ls -l vmlinux -rwxr-x--- 1 ndesaulniers eng 300376208 Oct 26 12:06 vmlinux $ ls -l Image.lz4-dtb -rw-r----- 1 ndesaulniers eng 16932466 Oct 26 12:06 Image.lz4-dtb

By Siqi's measurement w/ gzip: binutils 2.27 with this patch (with --no-apply-dynamic-relocs): Image 41535488 Image.gz 13404067

binutils 2.27 without this patch (without --no-apply-dynamic-relocs): Image 41535488 Image.gz 14125516

Any compression scheme should be able to get better results from the longer runs of zeros, not just GZIP and LZ4.

10ms boot time savings isn't anything to get excited about, but users of arm64+compression+bfd-2.27 should not have to pay a penalty for no runtime improvement.

Reported-by: Gopinath Elanchezhian gelanchezhian@google.com Reported-by: Sindhuri Pentyala spentyala@google.com Reported-by: Wei Wang wvw@google.com Suggested-by: Ard Biesheuvel ard.biesheuvel@linaro.org Suggested-by: Rahul Chaudhry rahulchaudhry@google.com Suggested-by: Siqi Lin siqilin@google.com Suggested-by: Stephen Hines srhines@google.com Signed-off-by: Nick Desaulniers ndesaulniers@google.com Reviewed-by: Ard Biesheuvel ard.biesheuvel@linaro.org [will: added comment to Makefile] Signed-off-by: Will Deacon will.deacon@arm.com

Signed-off-by: Sasha Levin alexander.levin@verizon.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/arm64/Makefile | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -14,8 +14,12 @@ LDFLAGS_vmlinux :=-p --no-undefined -X CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET) GZFLAGS :=-9

-ifneq ($(CONFIG_RELOCATABLE),) -LDFLAGS_vmlinux += -pie -shared -Bsymbolic +ifeq ($(CONFIG_RELOCATABLE), y) +# Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour +# for relative relocs, since this leads to better Image compression +# with the relocation offsets always being zero. +LDFLAGS_vmlinux += -pie -shared -Bsymbolic \ + $(call ld-option, --no-apply-dynamic-relocs) endif

ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)

Patches currently in stable-queue which might be from ndesaulniers@google.com are

queue-4.14/arm64-prevent-regressions-in-compressed-kernel-image-size-when-upgrading-to-binutils-2.27.patch