| Message ID | 20200228002244.15240-8-keescook@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Enable orphan section warning | expand |
On Thu, Feb 27, 2020 at 04:22:42PM -0800, Kees Cook wrote: > We don't want to depend on the linker's orphan section placement > heuristics as these can vary between linkers, and may change between > versions. All sections need to be explicitly named in the linker > script. > > Explicitly include debug sections when they're present. Add .eh_frame* > to discard as it seems that these are still generated even though > -fno-asynchronous-unwind-tables is being specified. Add .plt and > .data.rel.ro to discards as they are not actually used. Add .got.plt > to the image as it does appear to be mapped near .data. Finally enable > orphan section warnings. Hmm, I don't understand what .got.plt is doing here. Please can you elaborate? Will
On Tue, Mar 17, 2020 at 09:56:14PM +0000, Will Deacon wrote: > On Thu, Feb 27, 2020 at 04:22:42PM -0800, Kees Cook wrote: > > We don't want to depend on the linker's orphan section placement > > heuristics as these can vary between linkers, and may change between > > versions. All sections need to be explicitly named in the linker > > script. > > > > Explicitly include debug sections when they're present. Add .eh_frame* > > to discard as it seems that these are still generated even though > > -fno-asynchronous-unwind-tables is being specified. Add .plt and > > .data.rel.ro to discards as they are not actually used. Add .got.plt > > to the image as it does appear to be mapped near .data. Finally enable > > orphan section warnings. > > Hmm, I don't understand what .got.plt is doing here. Please can you > elaborate? I didn't track it down, but it seems to have been present (and merged into the kernel .data) for a while now. I can try to track this down if you want?
On Tue, Mar 17, 2020 at 4:01 PM Kees Cook <keescook@chromium.org> wrote: > > On Tue, Mar 17, 2020 at 09:56:14PM +0000, Will Deacon wrote: > > On Thu, Feb 27, 2020 at 04:22:42PM -0800, Kees Cook wrote: > > > We don't want to depend on the linker's orphan section placement > > > heuristics as these can vary between linkers, and may change between > > > versions. All sections need to be explicitly named in the linker > > > script. > > > > > > Explicitly include debug sections when they're present. Add .eh_frame* > > > to discard as it seems that these are still generated even though > > > -fno-asynchronous-unwind-tables is being specified. Add .plt and > > > .data.rel.ro to discards as they are not actually used. Add .got.plt > > > to the image as it does appear to be mapped near .data. Finally enable > > > orphan section warnings. > > > > Hmm, I don't understand what .got.plt is doing here. Please can you > > elaborate? > > I didn't track it down, but it seems to have been present (and merged > into the kernel .data) for a while now. I can try to track this down if > you want? Yes, the presence of a procedure linkage table makes sense for symbol interposition and lazy binding in userspace executables with runtime shared object loading support, but not so much the kernel, I would think. (Though someone did just recently ask me if loadable kernel modules could interpose weakly defined symbols in the kernel, and if so what happens on unload. I have no idea and suspect kernel modules cannot do that, but I have looked into the kernel's runtime relocation support.)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index dca1a97751ab..c682a65b3ab8 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -30,6 +30,10 @@ LDFLAGS_vmlinux += --fix-cortex-a53-843419 endif endif +# We never want expected sections to be placed heuristically by the +# linker. All sections should be explicitly named in the linker script. +LDFLAGS_vmlinux += --orphan-handling=warn + ifeq ($(CONFIG_ARM64_USE_LSE_ATOMICS), y) ifneq ($(CONFIG_ARM64_LSE_ATOMICS), y) $(warning LSE atomics not supported by binutils) diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index c61d9ab3211c..6141d5b72f8f 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -98,7 +98,8 @@ SECTIONS /DISCARD/ : { *(.interp .dynamic) *(.dynsym .dynstr .hash .gnu.hash) - *(.eh_frame) + *(.plt) *(.data.rel.ro) + *(.eh_frame) *(.init.eh_frame) } . = KIMAGE_VADDR + TEXT_OFFSET; @@ -212,6 +213,7 @@ SECTIONS _data = .; _sdata = .; RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_ALIGN) + .got.plt : ALIGN(8) { *(.got.plt) } /* * Data written with the MMU off but read with the MMU on requires @@ -246,6 +248,7 @@ SECTIONS _end = .; STABS_DEBUG + DWARF_DEBUG HEAD_SYMBOLS }
We don't want to depend on the linker's orphan section placement heuristics as these can vary between linkers, and may change between versions. All sections need to be explicitly named in the linker script. Explicitly include debug sections when they're present. Add .eh_frame* to discard as it seems that these are still generated even though -fno-asynchronous-unwind-tables is being specified. Add .plt and .data.rel.ro to discards as they are not actually used. Add .got.plt to the image as it does appear to be mapped near .data. Finally enable orphan section warnings. Signed-off-by: Kees Cook <keescook@chromium.org> --- arch/arm64/Makefile | 4 ++++ arch/arm64/kernel/vmlinux.lds.S | 5 ++++- 2 files changed, 8 insertions(+), 1 deletion(-)