| Message ID | 20200228002244.15240-1-keescook@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Enable orphan section warning | expand |
On Fri, Feb 28, 2020 at 1:22 AM Kees Cook <keescook@chromium.org> wrote: > > Hi! > > A recent bug 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. Similarly, the recent FGKASLR series brough up orphan > section handling too[2]. In both 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 or discarded) with any orphans throwing a warning. The > powerpc architecture actually already does this, so this series seeks > to extend this coverage to x86, arm64, and arm. > > This series depends on tip/x86/boot (where recent .eh_frame fixes[3] > landed), and has a minor conflict[4] with the ARM tree (related to > the earlier mentioned bug). As it uses refactorings in the asm-generic > linker script, and makes changes to kbuild, I think the cleanest place > for this series to land would also be through -tip. Once again (like > my READ_IMPLIES_EXEC series), I'm looking to get maintainer Acks so > this can go all together with the least disruption. Splitting it up by > architecture seems needlessly difficult. > > Thanks! > > -Kees > > [1] https://github.com/ClangBuiltLinux/linux/issues/282 > [2] https://lore.kernel.org/lkml/202002242122.AA4D1B8@keescook/ > [3] https://lore.kernel.org/lkml/158264960194.28353.10560165361470246192.tip-bot2@tip-bot2/ > [4] https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8959/1 > Hi Kees, is this an updated version of what you have in your kees/linux.git#linker/orphans/x86-arm Git branch? Especially, I saw a difference in [2] and "[PATCH 4/9] x86/boot: Warn on orphan section placement" [ arch/x86/boot/compressed/Makefile ] +KBUILD_LDFLAGS += --no-ld-generated-unwind-info Can you comment on why this KBUILD_LDFLAGS was added/needed? I like when people offer their work in a Git branch. Do you plan to do that? Thanks. Regards, - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=linker/orphans/x86-arm [2] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=linker/orphans/x86-arm&id=e43aa77956c40b9b6db0b37b3780423aa2e661ad > H.J. Lu (1): > Add RUNTIME_DISCARD_EXIT to generic DISCARDS > > Kees Cook (8): > scripts/link-vmlinux.sh: Delay orphan handling warnings until final > link > vmlinux.lds.h: Add .gnu.version* to DISCARDS > x86/build: Warn on orphan section placement > x86/boot: Warn on orphan section placement > arm64/build: Use common DISCARDS in linker script > arm64/build: Warn on orphan section placement > arm/build: Warn on orphan section placement > arm/boot: Warn on orphan section placement > > arch/arm/Makefile | 4 ++++ > arch/arm/boot/compressed/Makefile | 2 ++ > arch/arm/boot/compressed/vmlinux.lds.S | 17 ++++++-------- > .../arm/{kernel => include/asm}/vmlinux.lds.h | 22 ++++++++++++++----- > arch/arm/kernel/vmlinux-xip.lds.S | 5 ++--- > arch/arm/kernel/vmlinux.lds.S | 5 ++--- > arch/arm64/Makefile | 4 ++++ > arch/arm64/kernel/vmlinux.lds.S | 13 +++++------ > arch/x86/Makefile | 4 ++++ > arch/x86/boot/compressed/Makefile | 3 ++- > arch/x86/boot/compressed/vmlinux.lds.S | 13 +++++++++++ > arch/x86/kernel/vmlinux.lds.S | 7 ++++++ > include/asm-generic/vmlinux.lds.h | 11 ++++++++-- > scripts/link-vmlinux.sh | 6 +++++ > 14 files changed, 85 insertions(+), 31 deletions(-) > rename arch/arm/{kernel => include/asm}/vmlinux.lds.h (92%) > > -- > 2.20.1 > > -- > You received this message because you are subscribed to the Google Groups "Clang Built Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20200228002244.15240-1-keescook%40chromium.org.
On Fri, Feb 28, 2020 at 07:51:21AM +0100, Sedat Dilek wrote: > On Fri, Feb 28, 2020 at 1:22 AM Kees Cook <keescook@chromium.org> wrote: > > This series depends on tip/x86/boot (where recent .eh_frame fixes[3] > > landed), and has a minor conflict[4] with the ARM tree (related to > > the earlier mentioned bug). As it uses refactorings in the asm-generic > > linker script, and makes changes to kbuild, I think the cleanest place > > for this series to land would also be through -tip. Once again (like > > my READ_IMPLIES_EXEC series), I'm looking to get maintainer Acks so > > this can go all together with the least disruption. Splitting it up by > > architecture seems needlessly difficult. > > Hi Kees, > > is this an updated version of what you have in your > kees/linux.git#linker/orphans/x86-arm Git branch? Hi; yes indeed. > Especially, I saw a difference in [2] and "[PATCH 4/9] x86/boot: Warn > on orphan section placement" > > [ arch/x86/boot/compressed/Makefile ] > > +KBUILD_LDFLAGS += --no-ld-generated-unwind-info > > Can you comment on why this KBUILD_LDFLAGS was added/needed? It looks like the linker decided to add .eh_frame sections even when all the .o files lacked it. Adding this flag solved it (which I prefer over adding it to DISCARD). > I like when people offer their work in a Git branch. > Do you plan to do that? Since it was based on a -tip sub-branch I didn't push a copy, but since you asked here it is: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=orphans/tip/x86/boot And this email can serve as a "ping" to the arch maintainers too... does this all look okay to you? I think it'd be a nice improvement. :) Thanks! -Kees > Thanks. > > Regards, > - Sedat - > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=linker/orphans/x86-arm > [2] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=linker/orphans/x86-arm&id=e43aa77956c40b9b6db0b37b3780423aa2e661ad > > > > > H.J. Lu (1): > > Add RUNTIME_DISCARD_EXIT to generic DISCARDS > > > > Kees Cook (8): > > scripts/link-vmlinux.sh: Delay orphan handling warnings until final > > link > > vmlinux.lds.h: Add .gnu.version* to DISCARDS > > x86/build: Warn on orphan section placement > > x86/boot: Warn on orphan section placement > > arm64/build: Use common DISCARDS in linker script > > arm64/build: Warn on orphan section placement > > arm/build: Warn on orphan section placement > > arm/boot: Warn on orphan section placement > > > > arch/arm/Makefile | 4 ++++ > > arch/arm/boot/compressed/Makefile | 2 ++ > > arch/arm/boot/compressed/vmlinux.lds.S | 17 ++++++-------- > > .../arm/{kernel => include/asm}/vmlinux.lds.h | 22 ++++++++++++++----- > > arch/arm/kernel/vmlinux-xip.lds.S | 5 ++--- > > arch/arm/kernel/vmlinux.lds.S | 5 ++--- > > arch/arm64/Makefile | 4 ++++ > > arch/arm64/kernel/vmlinux.lds.S | 13 +++++------ > > arch/x86/Makefile | 4 ++++ > > arch/x86/boot/compressed/Makefile | 3 ++- > > arch/x86/boot/compressed/vmlinux.lds.S | 13 +++++++++++ > > arch/x86/kernel/vmlinux.lds.S | 7 ++++++ > > include/asm-generic/vmlinux.lds.h | 11 ++++++++-- > > scripts/link-vmlinux.sh | 6 +++++ > > 14 files changed, 85 insertions(+), 31 deletions(-) > > rename arch/arm/{kernel => include/asm}/vmlinux.lds.h (92%)
On Fri, Feb 28, 2020 at 1:22 AM Kees Cook <keescook@chromium.org> wrote: > > Hi! > > A recent bug 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. Similarly, the recent FGKASLR series brough up orphan > section handling too[2]. In both 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 or discarded) with any orphans throwing a warning. The > powerpc architecture actually already does this, so this series seeks > to extend this coverage to x86, arm64, and arm. > > This series depends on tip/x86/boot (where recent .eh_frame fixes[3] > landed), and has a minor conflict[4] with the ARM tree (related to > the earlier mentioned bug). As it uses refactorings in the asm-generic > linker script, and makes changes to kbuild, I think the cleanest place > for this series to land would also be through -tip. Once again (like > my READ_IMPLIES_EXEC series), I'm looking to get maintainer Acks so > this can go all together with the least disruption. Splitting it up by > architecture seems needlessly difficult. > > Thanks! > Hi Kees, what is the status of this patchset? Looks like it is not in tip or linux-next Git. Thanks. Regards, - Sedat - > -Kees > > [1] https://github.com/ClangBuiltLinux/linux/issues/282 > [2] https://lore.kernel.org/lkml/202002242122.AA4D1B8@keescook/ > [3] https://lore.kernel.org/lkml/158264960194.28353.10560165361470246192.tip-bot2@tip-bot2/ > [4] https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8959/1 > > H.J. Lu (1): > Add RUNTIME_DISCARD_EXIT to generic DISCARDS > > Kees Cook (8): > scripts/link-vmlinux.sh: Delay orphan handling warnings until final > link > vmlinux.lds.h: Add .gnu.version* to DISCARDS > x86/build: Warn on orphan section placement > x86/boot: Warn on orphan section placement > arm64/build: Use common DISCARDS in linker script > arm64/build: Warn on orphan section placement > arm/build: Warn on orphan section placement > arm/boot: Warn on orphan section placement > > arch/arm/Makefile | 4 ++++ > arch/arm/boot/compressed/Makefile | 2 ++ > arch/arm/boot/compressed/vmlinux.lds.S | 17 ++++++-------- > .../arm/{kernel => include/asm}/vmlinux.lds.h | 22 ++++++++++++++----- > arch/arm/kernel/vmlinux-xip.lds.S | 5 ++--- > arch/arm/kernel/vmlinux.lds.S | 5 ++--- > arch/arm64/Makefile | 4 ++++ > arch/arm64/kernel/vmlinux.lds.S | 13 +++++------ > arch/x86/Makefile | 4 ++++ > arch/x86/boot/compressed/Makefile | 3 ++- > arch/x86/boot/compressed/vmlinux.lds.S | 13 +++++++++++ > arch/x86/kernel/vmlinux.lds.S | 7 ++++++ > include/asm-generic/vmlinux.lds.h | 11 ++++++++-- > scripts/link-vmlinux.sh | 6 +++++ > 14 files changed, 85 insertions(+), 31 deletions(-) > rename arch/arm/{kernel => include/asm}/vmlinux.lds.h (92%) > > -- > 2.20.1 > > -- > You received this message because you are subscribed to the Google Groups "Clang Built Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20200228002244.15240-1-keescook%40chromium.org.
On Thu, Apr 02, 2020 at 06:20:57PM +0200, Sedat Dilek wrote: > On Fri, Feb 28, 2020 at 1:22 AM Kees Cook <keescook@chromium.org> wrote: > > > > Hi! > > > > A recent bug 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. Similarly, the recent FGKASLR series brough up orphan > > section handling too[2]. In both 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 or discarded) with any orphans throwing a warning. The > > powerpc architecture actually already does this, so this series seeks > > to extend this coverage to x86, arm64, and arm. > > > > This series depends on tip/x86/boot (where recent .eh_frame fixes[3] > > landed), and has a minor conflict[4] with the ARM tree (related to > > the earlier mentioned bug). As it uses refactorings in the asm-generic > > linker script, and makes changes to kbuild, I think the cleanest place > > for this series to land would also be through -tip. Once again (like > > my READ_IMPLIES_EXEC series), I'm looking to get maintainer Acks so > > this can go all together with the least disruption. Splitting it up by > > architecture seems needlessly difficult. > > > > Thanks! > > > > Hi Kees, > > what is the status of this patchset? > Looks like it is not in tip or linux-next Git. Based on the feedback, I have 3 TODO items: - track down and eliminate (or explain) the source of the .got.plt on arm64 - enable orphan warnings for _all_ architectures - refactor final link logic to perform the orphan warning in a clean way I'm working through these (and other work) still. I'm hoping to have another version up some time next week.
On Thu, Apr 2, 2020 at 7:26 PM Kees Cook <keescook@chromium.org> wrote: > > On Thu, Apr 02, 2020 at 06:20:57PM +0200, Sedat Dilek wrote: > > On Fri, Feb 28, 2020 at 1:22 AM Kees Cook <keescook@chromium.org> wrote: > > > > > > Hi! > > > > > > A recent bug 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. Similarly, the recent FGKASLR series brough up orphan > > > section handling too[2]. In both 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 or discarded) with any orphans throwing a warning. The > > > powerpc architecture actually already does this, so this series seeks > > > to extend this coverage to x86, arm64, and arm. > > > > > > This series depends on tip/x86/boot (where recent .eh_frame fixes[3] > > > landed), and has a minor conflict[4] with the ARM tree (related to > > > the earlier mentioned bug). As it uses refactorings in the asm-generic > > > linker script, and makes changes to kbuild, I think the cleanest place > > > for this series to land would also be through -tip. Once again (like > > > my READ_IMPLIES_EXEC series), I'm looking to get maintainer Acks so > > > this can go all together with the least disruption. Splitting it up by > > > architecture seems needlessly difficult. > > > > > > Thanks! > > > > > > > Hi Kees, > > > > what is the status of this patchset? > > Looks like it is not in tip or linux-next Git. > > Based on the feedback, I have 3 TODO items: > > - track down and eliminate (or explain) the source of the .got.plt on arm64 > - enable orphan warnings for _all_ architectures > - refactor final link logic to perform the orphan warning in a clean way > > I'm working through these (and other work) still. I'm hoping to have > another version up some time next week. > Please CC when possible with a pointer to a git-link. Thanks. - sed@ -
Hi! A recent bug 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. Similarly, the recent FGKASLR series brough up orphan section handling too[2]. In both 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 or discarded) with any orphans throwing a warning. The powerpc architecture actually already does this, so this series seeks to extend this coverage to x86, arm64, and arm. This series depends on tip/x86/boot (where recent .eh_frame fixes[3] landed), and has a minor conflict[4] with the ARM tree (related to the earlier mentioned bug). As it uses refactorings in the asm-generic linker script, and makes changes to kbuild, I think the cleanest place for this series to land would also be through -tip. Once again (like my READ_IMPLIES_EXEC series), I'm looking to get maintainer Acks so this can go all together with the least disruption. Splitting it up by architecture seems needlessly difficult. Thanks! -Kees [1] https://github.com/ClangBuiltLinux/linux/issues/282 [2] https://lore.kernel.org/lkml/202002242122.AA4D1B8@keescook/ [3] https://lore.kernel.org/lkml/158264960194.28353.10560165361470246192.tip-bot2@tip-bot2/ [4] https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8959/1 H.J. Lu (1): Add RUNTIME_DISCARD_EXIT to generic DISCARDS Kees Cook (8): scripts/link-vmlinux.sh: Delay orphan handling warnings until final link vmlinux.lds.h: Add .gnu.version* to DISCARDS x86/build: Warn on orphan section placement x86/boot: Warn on orphan section placement arm64/build: Use common DISCARDS in linker script arm64/build: Warn on orphan section placement arm/build: Warn on orphan section placement arm/boot: Warn on orphan section placement arch/arm/Makefile | 4 ++++ arch/arm/boot/compressed/Makefile | 2 ++ arch/arm/boot/compressed/vmlinux.lds.S | 17 ++++++-------- .../arm/{kernel => include/asm}/vmlinux.lds.h | 22 ++++++++++++++----- arch/arm/kernel/vmlinux-xip.lds.S | 5 ++--- arch/arm/kernel/vmlinux.lds.S | 5 ++--- arch/arm64/Makefile | 4 ++++ arch/arm64/kernel/vmlinux.lds.S | 13 +++++------ arch/x86/Makefile | 4 ++++ arch/x86/boot/compressed/Makefile | 3 ++- arch/x86/boot/compressed/vmlinux.lds.S | 13 +++++++++++ arch/x86/kernel/vmlinux.lds.S | 7 ++++++ include/asm-generic/vmlinux.lds.h | 11 ++++++++-- scripts/link-vmlinux.sh | 6 +++++ 14 files changed, 85 insertions(+), 31 deletions(-) rename arch/arm/{kernel => include/asm}/vmlinux.lds.h (92%)