Bug 1687774
| Summary: | ld -z shstk sometimes sets IBT property even if -z ibt is not passed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Paolo Bonzini <pbonzini> |
| Component: | binutils | Assignee: | Nick Clifton <nickc> |
| binutils sub component: | system-version | QA Contact: | Miloš Prchlík <mprchlik> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | unspecified | ||
| Priority: | unspecified | CC: | fweimer, law, mcermak, mprchlik, ohudlick, pbonzini |
| Version: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | binutils-2.30-53.el8 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-11-05 21:29:37 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1682589 | ||
| Bug Blocks: | |||
(In reply to Paolo Bonzini from comment #0) Hi Paolo, > as --64 -o g.o g.s > gcc -o g g.o -Wl,-z,shstk The issue here is that g.o does not contain any notes of any kind. In particular it does not contain any GNU Property notes indicating which ABI features are enabled. So when you link g.o together with other files which do have IBT enabled, the linker sees no reason not to leave the IBT note intact. I have asked H.J.Lu what he thinks should happen in this case. (He is the author of this linker feature). My gut feeling is that the linker should treat object files with executable code sections and no GNU Property notes as if they did not have IBT enabled. Cheers Nick > My gut feeling is that the
> linker should treat object files with executable code sections and
> no GNU Property notes as if they did not have IBT enabled.
I agree on this. It should be possible to add the note by adding "-z ibt" and/or "-z shstk" to the linker command line. However, the note should never deduce any bits from object files, unless they are present in all object files. The linker behaves correctly as far as I can see if you do not pass any of these "-z" options.
A related question is whether the compiler should add the note if you add "-mibt" and/or "-mshstk" to the compiler command line (or some other option to the same effect). This would be nice because then you do not need to add -z at all to the linker command line; the linker would deduce the properties automatically from the object files. Right now I am "emulating" this behavior, by adding the note with -include.
(In reply to Paolo Bonzini from comment #2) Hi Paolo, > It should be possible to add the note by adding "-z ibt" > and/or "-z shstk" to the linker command line. This is already supported. > A related question is whether the compiler should add the note if you add > "-mibt" and/or "-mshstk" to the compiler command line (or some other option > to the same effect). I think that this is also done. The option (for gcc at least) is -fcf-protection and this should set the appropriate bits in the note for the object file produced. So - is there actually a problem to be solved here ? Cheers Nick Paolo - ping ? Can I close this BZ ? I think the upstream ld fix should be backported, shouldn't it? The problem is that if somebody links with "-Wl,-z,shstk" they would get the IBT bit set incorrectly. Hi Paolo, Doh - my brain needs a reboot. You are right of course, the patch does need to be backported. Except that I had already done this a couple of months ago. But I forgot to update this BZ. *sigh*. Fixed in binutils-2.30-53.el8 Cheers Nick Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3514 |
Reproducer cat > f.s <<\EOF .text .global _start _start: xor %edi, %edi mov $60, %eax syscall EOF cat > g.s <<\EOF .text .global main main: xor %edi, %edi mov $60, %eax syscall EOF cat > Makefile <<\EOF all: f g f: f.o; ld -o $@ $< -z shstk g: g.o; gcc -o $@ $< -Wl,-z,shstk f.o: f.s g.o: g.s .s.o:; as --64 -o $@ $< .PHONY: all EOF Now: $ make as --64 -o f.o f.s ld -o f f.o -z shstk as --64 -o g.o g.s gcc -o g g.o -Wl,-z,shstk $ readelf -n f # correct Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: x86 feature: SHSTK $ readelf -n g # wrong Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: x86 feature: IBT, SHSTK and indeed running "g" on a machine with CET fails with a segv at the beginning of "main" (it works if you add the endbr64 hint). More information: - the minimal ld command line that causes the bug and still allows "g" to build is /usr/bin/ld --no-add-needed \ -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o g \ /usr/lib64/crt1.o /usr/lib64/crti.o g.o -z shstk \ -L/lib64 -lc - the minimal ld command line that causes the bug (but does not build a runnable executable) is /usr/bin/ld --no-add-needed -r -o h \ /usr/lib64/crt1.o /usr/lib64/crti.o g.o -z shstk