linux-kernel - [RFCv2 PATCH 0/3] Salted build ids via linker sections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180329180112.11055-1-labbott@redhat.com>
Date:   Thu, 29 Mar 2018 11:01:09 -0700
From:   Laura Abbott <labbott@...hat.com>
To:     Andy Lutomirski <luto@...nel.org>, mjw@...oraproject.org,
        "H . J . Lu" <hjl.tools@...il.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Laura Abbott <labbott@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        X86 ML <x86@...nel.org>, linux-kernel@...r.kernel.org,
        Nick Clifton <nickc@...hat.com>,
        Cary Coutant <ccoutant@...il.com>, linux-kbuild@...r.kernel.org
Subject: [RFCv2 PATCH 0/3] Salted build ids via linker sections

Hi,

This is v2 of my proposal to allow unique build-ids in the kernel. from
last time:

""
In Fedora, the debug information is packaged separately (foo-debuginfo) and
can be installed separately. There's been a long standing issue where only one
version of a debuginfo info package can be installed at a time. Mark Wielaard
made an effort for Fedora 27 to allow parallel installation of debuginfo (see
https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo for
more details)

Part of the requirement to allow this to work is that build ids are
unique between builds. The existing upstream rpm implementation ensures
this by re-calculating the build-id using the version and release as a
seed. This doesn't work 100% for the kernel because of the vDSO which is
its own binary and doesn't get updated. After poking holes in a few of my
ideas, there was a discussion with some people from the binutils team about
adding --build-id-salt to let ld do the calculation debugedit is doing. There
was a counter proposal made about adding some extra information via a .comment
which will affect the build id calculation but just get stripped out.
""

This v2 cleans up the naming to be consistent and also switches to a
config option vs. an environment variable. I've seen some sporadic
failures about missing the generated header so I think I'm still missing
a dependency somewhere. I'm still mostly looking for feedback whether
this would be acceptable for merging or if we should just persue a
--build-id-salt in binutils.

Thanks,
Laura

Laura Abbott (3):
  kbuild: Introduce build-salt generated header
  kbuild: Link with generated build-salt header
  x86/vdso: Add build salt to the vDSO

 Makefile                              | 13 +++++++++++--
 arch/x86/entry/vdso/vdso-layout.lds.S |  3 +++
 init/Kconfig                          |  8 ++++++++
 scripts/.gitignore                    |  1 +
 scripts/Makefile                      |  2 +-
 scripts/build-salt.lds.S              |  5 +++++
 scripts/gensalt                       | 21 +++++++++++++++++++++
 scripts/link-vmlinux.sh               |  3 ++-
 8 files changed, 52 insertions(+), 4 deletions(-)
 create mode 100644 scripts/build-salt.lds.S
 create mode 100755 scripts/gensalt

-- 
2.16.2