[PATCH] D66426: [lld] Enable a watermark of loadable sections to be generated and placed in a note section

Chris Jackson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 14 06:26:28 PST 2020


chrisjackson added a comment.

In D66426#1814738 <https://reviews.llvm.org/D66426#1814738>, @MaskRay wrote:

> Apologies for the late reply.
>
> http://lists.llvm.org/pipermail/llvm-dev/2019-November/137108.html does not evoke many responses. I take the lack of responses on the RFC and questions from @JonChesterfield and @ruiu as people are still doubting whether this feature will be generic enough to benefit the community, rather than a feature used in a very specific scenario, which can be easily replaced by another tool.


While current applicability of this feature does appear to be limited due to the lack of responses, I don't think the proposed feature is alone in its limited userbase. For example, I'm not sure how widespread the use of ELF partitioning is, which is much more intrusive (To be clear, I'm not suggesting partitioning should not be part of lld). The feature must be part of the linker as an external tool does not prevent a modification post-link (see @edd's earlier comment), thus defeating the purpose of the watermark.

It was my understanding that I had the code owner's blessing for the watermarking feature but of course this may have changed.

> I have also asked some other folks but haven't receive positive reaction yet. I concur with what @ruiu said. I feel this just raises the bar of an arm race, which may not be necessary in the first place if the process can be improved (why can the build system modify contents after linking and before a binary manipulation tool like llvm-objcopy?).

There cannot be an arms race as this is not a security feature. I think perhaps this feature is best thought of as build-id for PT_LOAD segments. It provides a tool for detecting build systems that act in this questionable manner. Why the build systems behave this way would be determined and corrected afterwards. Would a change in name to something like 'loadable-build-id' cause less confusion?

> I think this feature, as it stands, is not quite justified as a linker feature. Adding to llvm-objcopy is probably fine but I hope we can aim for something bigger.
> The statement "compliant with the system ABI" is pretty vague. Its defined meaning here is: "if we are byte identical, then we are ABI compliant." This is obviously too strong and does not reflect the real fact. If we want to make sure external symbols (part of ABI) do not change, we can use something like interface shared objects. Fedora is doing something more generic. https://fedoraproject.org/wiki/Toolchain/Watermark I wish if we want to add an LLVM watermark, we can make it more generally useful.

While this is a very strong statement, it is true. We don't think that the watermark feature is a perfect ABI compliance checking utility (indeed perhaps referring to the ABI was a mistake on my part), but it does enforce the requirements @edd highlighted.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66426/new/

https://reviews.llvm.org/D66426





More information about the llvm-commits mailing list