mbox series

[v6,00/29] Warn on orphan section placement

Message ID 20200821194310.3089815-1-keescook@chromium.org (mailing list archive)
Headers show
Series Warn on orphan section placement | expand

Message

Kees Cook Aug. 21, 2020, 7:42 p.m. UTC
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.


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%)

Comments

Kees Cook Aug. 31, 2020, 7:41 p.m. UTC | #1
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
>
Ingo Molnar Sept. 1, 2020, 7:11 a.m. UTC | #2
* 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 Sept. 1, 2020, 7:59 a.m. UTC | #3
* 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 Sept. 1, 2020, 8:16 a.m. UTC | #4
* 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
Kees Cook Sept. 1, 2020, 3:17 p.m. UTC | #5
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!
Nick Desaulniers Sept. 1, 2020, 6:02 p.m. UTC | #6
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.
Kees Cook Sept. 1, 2020, 11:18 p.m. UTC | #7
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...)
Nick Desaulniers Sept. 1, 2020, 11:54 p.m. UTC | #8
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
.