RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1687774 - ld -z shstk sometimes sets IBT property even if -z ibt is not passed
Summary: ld -z shstk sometimes sets IBT property even if -z ibt is not passed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: binutils
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Nick Clifton
QA Contact: Miloš Prchlík
URL:
Whiteboard:
Depends On: 1682589
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-12 10:57 UTC by Paolo Bonzini
Modified: 2021-09-17 14:30 UTC (History)
6 users (show)

Fixed In Version: binutils-2.30-53.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 21:29:37 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:3514 0 None None None 2019-11-05 21:30:03 UTC
Sourceware 24322 0 None None None 2019-06-04 15:01:45 UTC

Description Paolo Bonzini 2019-03-12 10:57:04 UTC 
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
Comment 1 Nick Clifton 2019-03-12 13:34:21 UTC 
(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
Comment 2 Paolo Bonzini 2019-03-12 17:18:43 UTC 
> 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.
Comment 3 Nick Clifton 2019-04-29 13:08:41 UTC 
(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
Comment 4 Nick Clifton 2019-05-20 09:09:03 UTC 
Paolo - ping ?  Can I close this BZ ?
Comment 5 Paolo Bonzini 2019-05-20 09:20:29 UTC 
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.
Comment 6 Nick Clifton 2019-05-20 10:51:28 UTC 
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
Comment 11 errata-xmlrpc 2019-11-05 21:29:37 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.