Re: [RFCv2 PATCH 0/3] Salted build ids via linker sections

From: Laura Abbott
Date: Mon May 14 2018 - 17:02:26 EST

On 05/06/2018 11:28 PM, Masahiro Yamada wrote:
2018-03-30 3:01 GMT+09:00 Laura Abbott <labbott@xxxxxxxxxx>:

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

I think you already know '--build-id=uuid' linker option.

Doesn't this solve your problem?

The disadvantage of this option is,
we will lose reproducible building because --build-id=uuid
adds every time random salt.

The advantage is, the implementation is even simpler,
and easier to migrate to --build-id-salt once it is supported
in the future.

It could, theoretically. The reproducibility is nice though and
I'd like to keep the kernel close to matching what other packages
do though.


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.


There is no dependency between 'prepare' and 'scripts'
in the top Makefile.
Therefore, Kbuild can run them simultaneously,
which would cause a race in parallel building.

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.


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/ | 3 +++
init/Kconfig | 8 ++++++++
scripts/.gitignore | 1 +
scripts/Makefile | 2 +-
scripts/ | 5 +++++
scripts/gensalt | 21 +++++++++++++++++++++
scripts/ | 3 ++-
8 files changed, 52 insertions(+), 4 deletions(-)
create mode 100644 scripts/
create mode 100755 scripts/gensalt


To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at