ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
# REQUIRES: x86
|
|
|
|
|
|
|
|
|
|
# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t
|
2016-11-17 01:14:11 +08:00
|
|
|
|
2017-10-31 06:08:11 +08:00
|
|
|
# RUN: ld.lld --build-id %t -o %t2
|
2019-05-01 13:49:01 +08:00
|
|
|
# RUN: llvm-readobj -S %t2 | FileCheck -check-prefix=ALIGN %s
|
2017-10-31 06:08:11 +08:00
|
|
|
|
2016-11-17 01:14:11 +08:00
|
|
|
# RUN: ld.lld --build-id %t -o %t2 -threads
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=DEFAULT %s
|
2018-02-08 03:22:42 +08:00
|
|
|
# RUN: ld.lld --build-id=fast %t -o %t2 -threads
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=DEFAULT %s
|
2016-11-17 01:14:11 +08:00
|
|
|
# RUN: ld.lld --build-id %t -o %t2 -no-threads
|
2016-04-08 06:49:21 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=DEFAULT %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
|
|
|
|
# RUN: ld.lld --build-id=md5 %t -o %t2 -threads
|
2016-04-08 06:49:21 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=MD5 %s
|
2016-11-17 01:14:11 +08:00
|
|
|
# RUN: ld.lld --build-id=md5 %t -o %t2 -no-threads
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=MD5 %s
|
|
|
|
|
|
|
|
|
|
# RUN: ld.lld --build-id=sha1 %t -o %t2 -threads
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=SHA1 %s
|
|
|
|
|
# RUN: ld.lld --build-id=sha1 %t -o %t2 -no-threads
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=SHA1 %s
|
|
|
|
|
|
|
|
|
|
# RUN: ld.lld --build-id=tree %t -o %t2 -threads
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=SHA1 %s
|
|
|
|
|
# RUN: ld.lld --build-id=tree %t -o %t2 -no-threads
|
2016-04-08 07:51:56 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=SHA1 %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
2016-08-26 17:55:37 +08:00
|
|
|
# RUN: ld.lld --build-id=uuid %t -o %t2
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=UUID %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
2016-05-14 05:55:56 +08:00
|
|
|
# RUN: ld.lld --build-id=0x12345678 %t -o %t2
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=HEX %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
# RUN: ld.lld %t -o %t2
|
2016-04-08 06:49:21 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=NONE %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
2016-05-04 04:55:47 +08:00
|
|
|
# RUN: ld.lld --build-id=md5 --build-id=none %t -o %t2
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=NONE %s
|
2017-05-24 05:16:48 +08:00
|
|
|
# RUN: ld.lld --build-id --build-id=none %t -o %t2
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=NONE %s
|
|
|
|
|
# RUN: ld.lld --build-id=none --build-id %t -o %t2
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=DEFAULT %s
|
ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
|
2016-04-27 10:58:27 +08:00
|
|
|
.globl _start
|
ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
_start:
|
|
|
|
|
nop
|
|
|
|
|
|
2016-03-13 09:54:48 +08:00
|
|
|
.section .note.test, "a", @note
|
|
|
|
|
.quad 42
|
|
|
|
|
|
2017-10-31 06:08:11 +08:00
|
|
|
# ALIGN: Name: .note.gnu.build-id
|
|
|
|
|
# ALIGN-NEXT: Type: SHT_NOTE
|
|
|
|
|
# ALIGN-NEXT: Flags [
|
|
|
|
|
# ALIGN-NEXT: SHF_ALLOC
|
|
|
|
|
# ALIGN-NEXT: ]
|
|
|
|
|
# ALIGN-NEXT: Address:
|
|
|
|
|
# ALIGN-NEXT: Offset: [[_:0x[0-9A-Z]*(0|4|8|C)$]]
|
|
|
|
|
# ALIGN-NEXT: Size:
|
|
|
|
|
# ALIGN-NEXT: Link:
|
|
|
|
|
# ALIGN-NEXT: Info:
|
|
|
|
|
# ALIGN-NEXT: AddressAlignment: 4
|
|
|
|
|
|
2016-11-01 17:49:24 +08:00
|
|
|
# DEFAULT: Contents of section .note.test:
|
2016-04-08 06:49:21 +08:00
|
|
|
# DEFAULT: Contents of section .note.gnu.build-id:
|
|
|
|
|
# DEFAULT-NEXT: 04000000 08000000 03000000 474e5500 ............GNU.
|
[ELF] Add -z separate-code and pad the last page of last PF_X PT_LOAD with traps only if -z separate-code is specified
This patch
1) adds -z separate-code and -z noseparate-code (default).
2) changes the condition that the last page of last PF_X PT_LOAD is
padded with trap instructions.
Current condition (after D33630): if there is no `SECTIONS` commands.
After this change: if -z separate-code is specified.
-z separate-code was introduced to ld.bfd in 2018, to place the text
segment in its own pages. There is no overlap in pages between an
executable segment and a non-executable segment:
1) RX cannot load initial contents from R or RW(or non-SHF_ALLOC).
2) R and RW(or non-SHF_ALLOC) cannot load initial contents from RX.
lld's current status:
- Between R and RX: in `Writer<ELFT>::fixSectionAlignments()`, the start of a
segment is always aligned to maxPageSize, so the initial contents loaded by R
and RX do not overlap. I plan to allow overlaps in D64906 if -z noseparate-code
is in effect.
- Between RX and RW(or non-SHF_ALLOC if RW doesn't exist):
we currently unconditionally pad the last page to commonPageSize
(defaults to 4096 on all targets we support).
This patch will make it effective only if -z separate-code is specified.
-z separate-code is a dubious feature that intends to reduce the number
of ROP gadgets (which is actually ineffective because attackers can find
plenty of gadgets in the text segment, no need to find gadgets in
non-code regions).
With the overlapping PT_LOAD technique D64906, -z noseparate-code
removes two more alignments at segment boundaries than -z separate-code.
This saves at most defaultCommonPageSize*2 bytes, which are significant
on targets with large defaultCommonPageSize (AArch64/MIPS/PPC: 65536).
Issues/feedback on alignment at segment boundaries to help understand
the implication:
* binutils PR24490 (the situation on ld.bfd is worse because they have
two R-- on both sides of R-E so more alignments.)
* In binutils, the 2018-02-27 commit "ld: Add --enable-separate-code" made -z separate-code the default on Linux.
https://github.com/richfelker/musl-cross-make/commit/d969dea983a2cc54a1e0308a0cdeb6c3307e4bfa
In musl-cross-make, binutils is configured with --disable-separate-code
to address size regressions caused by -z separate-code. (lld actually has the same
issue, which I plan to fix in a future patch. The ld.bfd x86 status is
worse because they default to max-page-size=0x200000).
* https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237676 people want
smaller code size. This patch will remove one alignment boundary.
* Stef O'Rear: I'm opposed to any kind of page alignment at the
text/rodata line (having a partial page of text aliased as rodata and
vice versa has no demonstrable harm, and I actually care about small
systems).
So, make -z noseparate-code the default.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D64903
llvm-svn: 367537
2019-08-01 17:58:25 +08:00
|
|
|
# DEFAULT-NEXT: 605e19a6 30469e00
|
ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
|
2016-04-08 06:49:21 +08:00
|
|
|
# MD5: Contents of section .note.gnu.build-id:
|
|
|
|
|
# MD5-NEXT: 04000000 10000000 03000000 474e5500 ............GNU.
|
[ELF] Add -z separate-code and pad the last page of last PF_X PT_LOAD with traps only if -z separate-code is specified
This patch
1) adds -z separate-code and -z noseparate-code (default).
2) changes the condition that the last page of last PF_X PT_LOAD is
padded with trap instructions.
Current condition (after D33630): if there is no `SECTIONS` commands.
After this change: if -z separate-code is specified.
-z separate-code was introduced to ld.bfd in 2018, to place the text
segment in its own pages. There is no overlap in pages between an
executable segment and a non-executable segment:
1) RX cannot load initial contents from R or RW(or non-SHF_ALLOC).
2) R and RW(or non-SHF_ALLOC) cannot load initial contents from RX.
lld's current status:
- Between R and RX: in `Writer<ELFT>::fixSectionAlignments()`, the start of a
segment is always aligned to maxPageSize, so the initial contents loaded by R
and RX do not overlap. I plan to allow overlaps in D64906 if -z noseparate-code
is in effect.
- Between RX and RW(or non-SHF_ALLOC if RW doesn't exist):
we currently unconditionally pad the last page to commonPageSize
(defaults to 4096 on all targets we support).
This patch will make it effective only if -z separate-code is specified.
-z separate-code is a dubious feature that intends to reduce the number
of ROP gadgets (which is actually ineffective because attackers can find
plenty of gadgets in the text segment, no need to find gadgets in
non-code regions).
With the overlapping PT_LOAD technique D64906, -z noseparate-code
removes two more alignments at segment boundaries than -z separate-code.
This saves at most defaultCommonPageSize*2 bytes, which are significant
on targets with large defaultCommonPageSize (AArch64/MIPS/PPC: 65536).
Issues/feedback on alignment at segment boundaries to help understand
the implication:
* binutils PR24490 (the situation on ld.bfd is worse because they have
two R-- on both sides of R-E so more alignments.)
* In binutils, the 2018-02-27 commit "ld: Add --enable-separate-code" made -z separate-code the default on Linux.
https://github.com/richfelker/musl-cross-make/commit/d969dea983a2cc54a1e0308a0cdeb6c3307e4bfa
In musl-cross-make, binutils is configured with --disable-separate-code
to address size regressions caused by -z separate-code. (lld actually has the same
issue, which I plan to fix in a future patch. The ld.bfd x86 status is
worse because they default to max-page-size=0x200000).
* https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237676 people want
smaller code size. This patch will remove one alignment boundary.
* Stef O'Rear: I'm opposed to any kind of page alignment at the
text/rodata line (having a partial page of text aliased as rodata and
vice versa has no demonstrable harm, and I actually care about small
systems).
So, make -z noseparate-code the default.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D64903
llvm-svn: 367537
2019-08-01 17:58:25 +08:00
|
|
|
# MD5-NEXT: adbf65c5 42b4a428 184fd7c9 099cdc29
|
2016-04-08 06:49:21 +08:00
|
|
|
|
2016-04-08 07:51:56 +08:00
|
|
|
# SHA1: Contents of section .note.gnu.build-id:
|
|
|
|
|
# SHA1-NEXT: 04000000 14000000 03000000 474e5500 ............GNU.
|
[ELF] Add -z separate-code and pad the last page of last PF_X PT_LOAD with traps only if -z separate-code is specified
This patch
1) adds -z separate-code and -z noseparate-code (default).
2) changes the condition that the last page of last PF_X PT_LOAD is
padded with trap instructions.
Current condition (after D33630): if there is no `SECTIONS` commands.
After this change: if -z separate-code is specified.
-z separate-code was introduced to ld.bfd in 2018, to place the text
segment in its own pages. There is no overlap in pages between an
executable segment and a non-executable segment:
1) RX cannot load initial contents from R or RW(or non-SHF_ALLOC).
2) R and RW(or non-SHF_ALLOC) cannot load initial contents from RX.
lld's current status:
- Between R and RX: in `Writer<ELFT>::fixSectionAlignments()`, the start of a
segment is always aligned to maxPageSize, so the initial contents loaded by R
and RX do not overlap. I plan to allow overlaps in D64906 if -z noseparate-code
is in effect.
- Between RX and RW(or non-SHF_ALLOC if RW doesn't exist):
we currently unconditionally pad the last page to commonPageSize
(defaults to 4096 on all targets we support).
This patch will make it effective only if -z separate-code is specified.
-z separate-code is a dubious feature that intends to reduce the number
of ROP gadgets (which is actually ineffective because attackers can find
plenty of gadgets in the text segment, no need to find gadgets in
non-code regions).
With the overlapping PT_LOAD technique D64906, -z noseparate-code
removes two more alignments at segment boundaries than -z separate-code.
This saves at most defaultCommonPageSize*2 bytes, which are significant
on targets with large defaultCommonPageSize (AArch64/MIPS/PPC: 65536).
Issues/feedback on alignment at segment boundaries to help understand
the implication:
* binutils PR24490 (the situation on ld.bfd is worse because they have
two R-- on both sides of R-E so more alignments.)
* In binutils, the 2018-02-27 commit "ld: Add --enable-separate-code" made -z separate-code the default on Linux.
https://github.com/richfelker/musl-cross-make/commit/d969dea983a2cc54a1e0308a0cdeb6c3307e4bfa
In musl-cross-make, binutils is configured with --disable-separate-code
to address size regressions caused by -z separate-code. (lld actually has the same
issue, which I plan to fix in a future patch. The ld.bfd x86 status is
worse because they default to max-page-size=0x200000).
* https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237676 people want
smaller code size. This patch will remove one alignment boundary.
* Stef O'Rear: I'm opposed to any kind of page alignment at the
text/rodata line (having a partial page of text aliased as rodata and
vice versa has no demonstrable harm, and I actually care about small
systems).
So, make -z noseparate-code the default.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D64903
llvm-svn: 367537
2019-08-01 17:58:25 +08:00
|
|
|
# SHA1-NEXT: fe148fd4 1add2878 6b298b61 5880148b
|
2016-04-08 07:51:56 +08:00
|
|
|
|
2016-08-26 17:55:37 +08:00
|
|
|
# UUID: Contents of section .note.gnu.build-id:
|
|
|
|
|
# UUID-NEXT: 04000000 10000000 03000000 474e5500 ............GNU.
|
|
|
|
|
|
2016-05-14 05:55:56 +08:00
|
|
|
# HEX: Contents of section .note.gnu.build-id:
|
|
|
|
|
# HEX-NEXT: 04000000 04000000 03000000 474e5500 ............GNU.
|
|
|
|
|
# HEX-NEXT: 12345678
|
|
|
|
|
|
2016-04-08 06:49:21 +08:00
|
|
|
# NONE-NOT: Contents of section .note.gnu.build-id:
|