All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sedat Dilek <sedat.dilek@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Borislav Petkov <bp@suse.de>, "H.J. Lu" <hjl.tools@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Peter Collingbourne <pcc@google.com>,
	James Morse <james.morse@arm.com>, Arnd Bergmann <arnd@arndb.de>,
	Masahiro Yamada <masahiroy@kernel.org>,
	x86@kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org,
	Clang-Built-Linux ML <clang-built-linux@googlegroups.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/9] Enable orphan section warning
Date: Sun, 5 Apr 2020 13:15:01 +0200	[thread overview]
Message-ID: <CA+icZUXi_iA7XkTEbrK7b6m673iG9qPKnDBE1V0JRywDLBc9jw@mail.gmail.com> (raw)
In-Reply-To: <202004021023.D3D8AA3BE@keescook>

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@ -

WARNING: multiple messages have this Message-ID (diff)
From: Sedat Dilek <sedat.dilek@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"H.J. Lu" <hjl.tools@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
	linux-kbuild@vger.kernel.org,
	Peter Collingbourne <pcc@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	x86@kernel.org, Russell King <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org,
	Clang-Built-Linux ML <clang-built-linux@googlegroups.com>,
	James Morse <james.morse@arm.com>,
	linux-arch@vger.kernel.org, Borislav Petkov <bp@suse.de>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/9] Enable orphan section warning
Date: Sun, 5 Apr 2020 13:15:01 +0200	[thread overview]
Message-ID: <CA+icZUXi_iA7XkTEbrK7b6m673iG9qPKnDBE1V0JRywDLBc9jw@mail.gmail.com> (raw)
In-Reply-To: <202004021023.D3D8AA3BE@keescook>

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@ -

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-04-05 11:14 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-28  0:22 [PATCH 0/9] Enable orphan section warning Kees Cook
2020-02-28  0:22 ` Kees Cook
2020-02-28  0:22 ` [PATCH 1/9] scripts/link-vmlinux.sh: Delay orphan handling warnings until final link Kees Cook
2020-02-28  0:22   ` Kees Cook
2020-03-20  2:47   ` Nicholas Piggin
2020-03-20  2:47     ` Nicholas Piggin
2020-03-20 18:24     ` Kees Cook
2020-03-20 18:24       ` Kees Cook
2020-03-22  9:16       ` Nicholas Piggin
2020-03-22  9:16         ` Nicholas Piggin
2020-03-22 16:00         ` Kees Cook
2020-03-22 16:00           ` Kees Cook
2020-02-28  0:22 ` [PATCH 2/9] vmlinux.lds.h: Add .gnu.version* to DISCARDS Kees Cook
2020-02-28  0:22   ` Kees Cook
2020-02-28  0:22 ` [PATCH 3/9] x86/build: Warn on orphan section placement Kees Cook
2020-02-28  0:22   ` Kees Cook
2020-02-28  0:22 ` [PATCH 4/9] x86/boot: " Kees Cook
2020-02-28  0:22   ` Kees Cook
2020-02-28  0:22 ` [PATCH 5/9] Add RUNTIME_DISCARD_EXIT to generic DISCARDS Kees Cook
2020-02-28  0:22   ` Kees Cook
2020-02-28  0:22 ` [PATCH 6/9] arm64/build: Use common DISCARDS in linker script Kees Cook
2020-02-28  0:22   ` Kees Cook
2020-03-17 21:52   ` Will Deacon
2020-03-17 21:52     ` Will Deacon
2020-02-28  0:22 ` [PATCH 7/9] arm64/build: Warn on orphan section placement Kees Cook
2020-02-28  0:22   ` Kees Cook
2020-03-17 21:56   ` Will Deacon
2020-03-17 21:56     ` Will Deacon
2020-03-17 23:01     ` Kees Cook
2020-03-17 23:01       ` Kees Cook
2020-03-17 23:10       ` Nick Desaulniers
2020-03-17 23:10         ` Nick Desaulniers
2020-02-28  0:22 ` [PATCH 8/9] arm/build: " Kees Cook
2020-02-28  0:22   ` Kees Cook
2020-02-28  0:22 ` [PATCH 9/9] arm/boot: " Kees Cook
2020-02-28  0:22   ` Kees Cook
2020-02-28  6:51 ` [PATCH 0/9] Enable orphan section warning Sedat Dilek
2020-02-28  6:51   ` Sedat Dilek
2020-03-03  4:32   ` Kees Cook
2020-03-03  4:32     ` Kees Cook
2020-04-02 16:20 ` Sedat Dilek
2020-04-02 16:20   ` Sedat Dilek
2020-04-02 17:26   ` Kees Cook
2020-04-02 17:26     ` Kees Cook
2020-04-05 11:15     ` Sedat Dilek [this message]
2020-04-05 11:15       ` Sedat Dilek
2020-02-28  0:23 Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+icZUXi_iA7XkTEbrK7b6m673iG9qPKnDBE1V0JRywDLBc9jw@mail.gmail.com \
    --to=sedat.dilek@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bp@suse.de \
    --cc=catalin.marinas@arm.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=hjl.tools@gmail.com \
    --cc=james.morse@arm.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=pcc@google.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.