linux-kernel - Re: [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-prev] [day] [month] [year] [list]

Date:   Thu, 17 May 2018 17:37:40 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Laura Abbott <labbott@...hat.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Mark Wielaard <mjw@...oraproject.org>,
        "H . J . Lu" <hjl.tools@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        X86 ML <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nick Clifton <nickc@...hat.com>,
        Cary Coutant <ccoutant@...il.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [RFCv2 PATCH 0/3] Salted build ids via linker sections

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