Message ID | 20200821194310.3089815-1-keescook@chromium.org (mailing list archive) |
---|---|
Headers | show |
Series | Warn on orphan section placement | expand |
On Fri, Aug 21, 2020 at 12:42:41PM -0700, Kees Cook wrote: > Hi Ingo, > > Based on my testing, this is ready to go. I've reviewed the feedback on > v5 and made a few small changes, noted below. If no one objects, I'll pop this into my tree for -next. I'd prefer it go via -tip though! :) Thanks! -Kees > > > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=linker/orphans/warn/v6 > > v6: > - rebase to -tip x86/boot > - remove 0-sized NOLOAD > - move .got.plt to end with INFO (NOLOAD warns) > - add Reviewed-bys > v5: https://lore.kernel.org/lkml/20200731230820.1742553-1-keescook@chromium.org/ > v4: https://lore.kernel.org/lkml/20200629061840.4065483-1-keescook@chromium.org/ > v3: https://lore.kernel.org/lkml/20200624014940.1204448-1-keescook@chromium.org/ > v2: https://lore.kernel.org/lkml/20200622205815.2988115-1-keescook@chromium.org/ > v1: https://lore.kernel.org/lkml/20200228002244.15240-1-keescook@chromium.org/ > > A recent bug[1] was solved for builds linked with ld.lld, and tracking > it down took way longer than it needed to (a year). Ultimately, it > boiled down to differences between ld.bfd and ld.lld's handling of > orphan sections. Similar situation have continued to recur, and it's > clear the kernel build needs to be much more explicit about linker > sections. Similarly, the recent FGKASLR series brought up orphan section > handling too[2]. In all cases, it would have been nice if the linker was > running with --orphan-handling=warn so that surprise sections wouldn't > silently get mapped into the kernel image at locations up to the whim > of the linker's orphan handling logic. Instead, all desired sections > should be explicitly identified in the linker script (to be either kept, > discarded, or verified to be zero-sized) with any orphans throwing a > warning. The powerpc architecture has actually been doing this for some > time, so this series just extends that coverage to x86, arm, and arm64. > > This has gotten sucecssful build testing under the following matrix: > > compiler/linker: gcc+ld.bfd, clang+ld.lld > targets: defconfig, allmodconfig > architectures: x86, i386, arm64, arm > versions: -tip x86/boot > > All three architectures depend on the first several commits to > vmlinux.lds.h. x86 depends on Arvind's GOT series (in -tip x86/boot now). > arm64 depends on the efi/libstub patch. As such, I'd like to land this > series as a whole. Ingo has suggested he'd take it into -tip. > > Thanks! > > -Kees > > [1] https://github.com/ClangBuiltLinux/linux/issues/282 > [2] https://lore.kernel.org/lkml/202002242122.AA4D1B8@keescook/ > > Kees Cook (28): > vmlinux.lds.h: Create COMMON_DISCARDS > vmlinux.lds.h: Add .gnu.version* to COMMON_DISCARDS > vmlinux.lds.h: Avoid KASAN and KCSAN's unwanted sections > vmlinux.lds.h: Split ELF_DETAILS from STABS_DEBUG > vmlinux.lds.h: Add .symtab, .strtab, and .shstrtab to ELF_DETAILS > efi/libstub: Disable -mbranch-protection > arm64/mm: Remove needless section quotes > arm64/kernel: Remove needless Call Frame Information annotations > arm64/build: Remove .eh_frame* sections due to unwind tables > arm64/build: Use common DISCARDS in linker script > arm64/build: Add missing DWARF sections > arm64/build: Assert for unwanted sections > arm64/build: Warn on orphan section placement > arm/build: Refactor linker script headers > arm/build: Explicitly keep .ARM.attributes sections > arm/build: Add missing sections > arm/build: Assert for unwanted sections > arm/build: Warn on orphan section placement > arm/boot: Handle all sections explicitly > arm/boot: Warn on orphan section placement > x86/asm: Avoid generating unused kprobe sections > x86/build: Enforce an empty .got.plt section > x86/build: Assert for unwanted sections > x86/build: Warn on orphan section placement > x86/boot/compressed: Reorganize zero-size section asserts > x86/boot/compressed: Remove, discard, or assert for unwanted sections > x86/boot/compressed: Add missing debugging sections to output > x86/boot/compressed: Warn on orphan section placement > > Nick Desaulniers (1): > vmlinux.lds.h: add PGO and AutoFDO input sections > > arch/alpha/kernel/vmlinux.lds.S | 1 + > arch/arc/kernel/vmlinux.lds.S | 1 + > arch/arm/Makefile | 4 ++ > arch/arm/boot/compressed/Makefile | 2 + > arch/arm/boot/compressed/vmlinux.lds.S | 20 +++---- > .../arm/{kernel => include/asm}/vmlinux.lds.h | 30 ++++++++-- > arch/arm/kernel/vmlinux-xip.lds.S | 8 ++- > arch/arm/kernel/vmlinux.lds.S | 8 ++- > arch/arm64/Makefile | 9 ++- > arch/arm64/kernel/smccc-call.S | 2 - > arch/arm64/kernel/vmlinux.lds.S | 28 +++++++-- > arch/arm64/mm/mmu.c | 2 +- > arch/csky/kernel/vmlinux.lds.S | 1 + > arch/hexagon/kernel/vmlinux.lds.S | 1 + > arch/ia64/kernel/vmlinux.lds.S | 1 + > arch/mips/kernel/vmlinux.lds.S | 1 + > arch/nds32/kernel/vmlinux.lds.S | 1 + > arch/nios2/kernel/vmlinux.lds.S | 1 + > arch/openrisc/kernel/vmlinux.lds.S | 1 + > arch/parisc/boot/compressed/vmlinux.lds.S | 1 + > arch/parisc/kernel/vmlinux.lds.S | 1 + > arch/powerpc/kernel/vmlinux.lds.S | 2 +- > arch/riscv/kernel/vmlinux.lds.S | 1 + > arch/s390/kernel/vmlinux.lds.S | 1 + > arch/sh/kernel/vmlinux.lds.S | 1 + > arch/sparc/kernel/vmlinux.lds.S | 1 + > arch/um/kernel/dyn.lds.S | 2 +- > arch/um/kernel/uml.lds.S | 2 +- > arch/x86/Makefile | 4 ++ > arch/x86/boot/compressed/Makefile | 2 + > arch/x86/boot/compressed/vmlinux.lds.S | 58 +++++++++++++------ > arch/x86/include/asm/asm.h | 6 +- > arch/x86/kernel/vmlinux.lds.S | 39 ++++++++++++- > drivers/firmware/efi/libstub/Makefile | 9 ++- > include/asm-generic/vmlinux.lds.h | 49 +++++++++++++--- > 35 files changed, 241 insertions(+), 60 deletions(-) > rename arch/arm/{kernel => include/asm}/vmlinux.lds.h (84%) > > -- > 2.25.1 >
* Kees Cook <keescook@chromium.org> wrote: > On Fri, Aug 21, 2020 at 12:42:41PM -0700, Kees Cook wrote: > > Hi Ingo, > > > > Based on my testing, this is ready to go. I've reviewed the feedback on > > v5 and made a few small changes, noted below. > > If no one objects, I'll pop this into my tree for -next. I'd prefer it > go via -tip though! :) > > Thanks! I'll pick it up today, it all looks very good now! Thanks, Ingo
* Ingo Molnar <mingo@kernel.org> wrote: > > * Kees Cook <keescook@chromium.org> wrote: > > > On Fri, Aug 21, 2020 at 12:42:41PM -0700, Kees Cook wrote: > > > Hi Ingo, > > > > > > Based on my testing, this is ready to go. I've reviewed the feedback on > > > v5 and made a few small changes, noted below. > > > > If no one objects, I'll pop this into my tree for -next. I'd prefer it > > go via -tip though! :) > > > > Thanks! > > I'll pick it up today, it all looks very good now! One thing I found in testing is that it doesn't handler older LD versions well enough: ld: unrecognized option '--orphan-handling=warn' Could we just detect the availability of this flag, and emit a warning if it doesn't exist but otherwise not abort the build? This is with: GNU ld version 2.25-17.fc23 Thanks, Ingo
* Ingo Molnar <mingo@kernel.org> wrote: > > * Ingo Molnar <mingo@kernel.org> wrote: > > > > > * Kees Cook <keescook@chromium.org> wrote: > > > > > On Fri, Aug 21, 2020 at 12:42:41PM -0700, Kees Cook wrote: > > > > Hi Ingo, > > > > > > > > Based on my testing, this is ready to go. I've reviewed the feedback on > > > > v5 and made a few small changes, noted below. > > > > > > If no one objects, I'll pop this into my tree for -next. I'd prefer it > > > go via -tip though! :) > > > > > > Thanks! > > > > I'll pick it up today, it all looks very good now! > > One thing I found in testing is that it doesn't handler older LD > versions well enough: > > ld: unrecognized option '--orphan-handling=warn' > > Could we just detect the availability of this flag, and emit a warning > if it doesn't exist but otherwise not abort the build? > > This is with: > > GNU ld version 2.25-17.fc23 I've resolved this for now by not applying the 5 patches that add the actual orphan section warnings: arm64/build: Warn on orphan section placement arm/build: Warn on orphan section placement arm/boot: Warn on orphan section placement x86/build: Warn on orphan section placement x86/boot/compressed: Warn on orphan section placement The new asserts plus the actual fixes/enhancements are enough changes to test for now in any case. :-) Thanks, Ingo
On Tue, Sep 01, 2020 at 10:16:47AM +0200, Ingo Molnar wrote: > > * Ingo Molnar <mingo@kernel.org> wrote: > > > > > * Ingo Molnar <mingo@kernel.org> wrote: > > > > > > > > * Kees Cook <keescook@chromium.org> wrote: > > > > > > > On Fri, Aug 21, 2020 at 12:42:41PM -0700, Kees Cook wrote: > > > > > Hi Ingo, > > > > > > > > > > Based on my testing, this is ready to go. I've reviewed the feedback on > > > > > v5 and made a few small changes, noted below. > > > > > > > > If no one objects, I'll pop this into my tree for -next. I'd prefer it > > > > go via -tip though! :) > > > > > > > > Thanks! > > > > > > I'll pick it up today, it all looks very good now! > > > > One thing I found in testing is that it doesn't handler older LD > > versions well enough: > > > > ld: unrecognized option '--orphan-handling=warn' Oh! Uhm, yikes. Thanks for noticing this. > > Could we just detect the availability of this flag, and emit a warning > > if it doesn't exist but otherwise not abort the build? Yeah, I'll respin those patches. > > This is with: > > > > GNU ld version 2.25-17.fc23 (At best, this is from 2015 ... but yes, min binutils in 2.23.) > > I've resolved this for now by not applying the 5 patches that add the > actual orphan section warnings: > > arm64/build: Warn on orphan section placement > arm/build: Warn on orphan section placement > arm/boot: Warn on orphan section placement > x86/build: Warn on orphan section placement > x86/boot/compressed: Warn on orphan section placement > > The new asserts plus the actual fixes/enhancements are enough changes > to test for now in any case. :-) Yup! I'll respin the enabling patches. Thanks again!
On Tue, Sep 1, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote: > > On Tue, Sep 01, 2020 at 10:16:47AM +0200, Ingo Molnar wrote: > > > > * Ingo Molnar <mingo@kernel.org> wrote: > > > > > > > > * Ingo Molnar <mingo@kernel.org> wrote: > > > > > > > > > > > * Kees Cook <keescook@chromium.org> wrote: > > > > > > > > > On Fri, Aug 21, 2020 at 12:42:41PM -0700, Kees Cook wrote: > > > > > > Hi Ingo, > > > > > > > > > > > > Based on my testing, this is ready to go. I've reviewed the feedback on > > > > > > v5 and made a few small changes, noted below. > > > > > > > > > > If no one objects, I'll pop this into my tree for -next. I'd prefer it > > > > > go via -tip though! :) > > > > > > > > > > Thanks! > > > > > > > > I'll pick it up today, it all looks very good now! > > > > > > One thing I found in testing is that it doesn't handler older LD > > > versions well enough: > > > > > > ld: unrecognized option '--orphan-handling=warn' > > Oh! Uhm, yikes. Thanks for noticing this. > > > > Could we just detect the availability of this flag, and emit a warning > > > if it doesn't exist but otherwise not abort the build? > > Yeah, I'll respin those patches. > > > > This is with: > > > > > > GNU ld version 2.25-17.fc23 > > (At best, this is from 2015 ... but yes, min binutils in 2.23.) Ah, crap! Indeed arch/powerpc/Makefile wraps this in ld-option. Uh oh, the ppc vdso uses cc-ldoption which was removed! (I think by me; let me send patches) How is that not an error? Yes, guilty, officer. commit 055efab3120b ("kbuild: drop support for cc-ldoption"). Did I not know how to use grep, or? No, it is commit f2af201002a8 ("powerpc/build: vdso linker warning for orphan sections") that is wrong.
On Tue, Sep 01, 2020 at 11:02:02AM -0700, Nick Desaulniers wrote: > On Tue, Sep 1, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote: > > > > On Tue, Sep 01, 2020 at 10:16:47AM +0200, Ingo Molnar wrote: > > > > This is with: > > > > > > > > GNU ld version 2.25-17.fc23 > > > > (At best, this is from 2015 ... but yes, min binutils in 2.23.) > > Ah, crap! Indeed arch/powerpc/Makefile wraps this in ld-option. Yeah, I totally missed that too. :) > Uh oh, the ppc vdso uses cc-ldoption which was removed! (I think by > me; let me send patches) How is that not an error? Yes, guilty, > officer. > commit 055efab3120b ("kbuild: drop support for cc-ldoption"). > Did I not know how to use grep, or? No, it is > commit f2af201002a8 ("powerpc/build: vdso linker warning for orphan sections") > that is wrong. Eek, yeah, the vdso needs fixing; whoops. Lucky for my series, I only need ld-option! ;) (Doing test builds now...)
On Tue, Sep 1, 2020 at 4:18 PM Kees Cook <keescook@chromium.org> wrote: > > On Tue, Sep 01, 2020 at 11:02:02AM -0700, Nick Desaulniers wrote: > > Uh oh, the ppc vdso uses cc-ldoption which was removed! (I think by > > me; let me send patches) How is that not an error? Yes, guilty, > > officer. > > commit 055efab3120b ("kbuild: drop support for cc-ldoption"). > > Did I not know how to use grep, or? No, it is > > commit f2af201002a8 ("powerpc/build: vdso linker warning for orphan sections") > > that is wrong. > > Eek, yeah, the vdso needs fixing; whoops. Lucky for my series, I only need > ld-option! ;) > I didn't cc everyone here on that thread, but here's the series I sent for it: https://lore.kernel.org/lkml/20200901222523.1941988-1-ndesaulniers@google.com/T/#u .