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

From: Masahiro Yamada
Date: Thu May 17 2018 - 03:41:43 EST


2018-05-15 6:02 GMT+09:00 Laura Abbott <labbott@xxxxxxxxxx>:
> On 05/06/2018 11:28 PM, Masahiro Yamada wrote:
>>
>> 2018-03-30 3:01 GMT+09:00 Laura Abbott <labbott@xxxxxxxxxx>:
>>>
>>> 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.
>>> ""
>>
>>
>>
>> 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.

Okay.
I left some comments in v2
about improvement, and cause of
the sporadic build failures.

Will wait for v3.

--
Best Regards
Masahiro Yamada