Bug 1479302 - binutils 2.29 breaks build of ruby on PPC64LE
Summary: binutils 2.29 breaks build of ruby on PPC64LE
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: checksec
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Björn 'besser82' Esser
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-08 10:36 UTC by Vít Ondruch
Modified: 2018-03-13 23:18 UTC (History)
6 users (show)

Fixed In Version: binutils-2.29-11.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-13 23:18:02 UTC


Attachments (Terms of Use)
libruby (4.14 MB, application/x-gzip)
2017-08-08 14:45 UTC, Dan Horák
no flags Details


Links
System ID Priority Status Summary Last Updated
Github slimm609 checksec.sh issues 53 None None None 2017-08-25 12:26:58 UTC

Description Vít Ondruch 2017-08-08 10:36:09 UTC
Builds of Ruby fails on Rawhide recently:

https://koji.fedoraproject.org/koji/buildinfo?buildID=950944

And this is where it fails:

https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_694

When I tried to do scratch build with the "checkspec", to get the difference, this was the output:

~~~
+ checksec -f libruby.so.2.4.1
WARNING: 'openssl' not found! It's required for most checks.
WARNING: Not all necessary commands found. Some tests might not work!
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH	FORTIFY	Fortified Fortifiable  FILE
Full RELRO      Canary found      NX enabled    DSO             No RPATH   No RUNPATH   No	0		0	libruby.so.2.4.1
+ checksec -f libruby.so.2.4.1
+ grep 'Full RELRO.*Canary found.*NX enabled.*DSO.*No RPATH.*No RUNPATH.*Yes.*\d*.*\d*.*libruby.so.2.4.1'
~~~

Apparently, the "FORTIFY" used to be "Yes" on all platforms, while it "No" for PPC64LE. It seems the build passes with binutils 2.28.

Comment 1 Dan Horák 2017-08-08 10:40:13 UTC
Yup, I did a check with a local rebuild in up-to-date rawhide and the checksec failed when ruby was built with binutils-2.29-5.fc27, but passed with binutils-2.28-14.fc27

FWIW the checksec tool is a script heavily using readelf

Comment 2 Nick Clifton 2017-08-08 14:36:40 UTC
Hi Vít,

(In reply to Vít Ondruch from comment #0)

> + checksec -f libruby.so.2.4.1

Please could you upload the failing libruby.so.2.4.1 binary so that I can examine it ?

Cheers
  Nick

Comment 3 Dan Horák 2017-08-08 14:45:04 UTC
Created attachment 1310652 [details]
libruby

Comment 4 Nick Clifton 2017-08-08 15:29:43 UTC
Right, well I have found the cause, but not a solution.  The 2.29 linker for PowerPC is setting some extra symbol information, in order to help optimise run-time performance.  (This is related to BZ 14756316, but it is not exactly the same problem).

So, when libruby is built with the 2.28 linker the readelf command run by checksec would see output something like this:

  138: 0000000000000000  0 FUNC GLOBAL DEFAULT  UND __memmove_chk@GLIBC_2.17 (2)
 
But when it is built with the 2.29 linker the readelf output looks like this:

  257: 0000000000000000  0 FUNC GLOBAL DEFAULT [<localentry>: 8]   UND __memmove_chk@GLIBC_2.17 (2)
 
(This is true regardless of which version of readelf is used).

The problem is that checksec uses an awk script to extract the names of symbols, based upon the field in which they appear, and this field is hardcoded to be field number 8.  This works for the 2.28 linked libruby, but not the 2.29 libruby.  So the checksec script thinks that no *_chk functions are accessed by the library, and hence that it has not been fortified.

Now I do not think that the linker is wrong in adding this extra information.  In fact I think that it may be a requirement of the new ABI that IBM are creating.  So I would suggest that the real fix is to update checksec to cope with the new information.  Maybe by searching for a symbol name suffixed by an @ symbol for example, instead of replying upon field numbers.

I have not changed the component field of this BZ yet however as I want to see if there are any other suggestions.

Cheers
  Nick

Comment 5 Nick Clifton 2017-08-08 15:34:26 UTC
Addendum: It occurs to me that one thing I could do is to patch readelf so that this "extra" information is printed at the end of the line, rather than in the middle.  That way checksec's awk scanner would resume working.  Of course this might potentially break other tools that rely upon the latest format of the output...

Comment 6 Dan Horák 2017-08-08 16:46:10 UTC
I would prefer the checksec tool to get fixed/updated for the new ppc64le ABI features.

Comment 7 Vít Ondruch 2017-08-09 08:33:45 UTC
The good news is that this is false positive and the lib is fortified, so the check can be temporary disabled if needed ...

(In reply to Nick Clifton from comment #5)
> It occurs to me that one thing I could do is to patch readelf so
> that this "extra" information is printed at the end of the line, rather than
> in the middle.

This sounds reasonable to me, since it would fix the checksec in one sweep (although potentially breaking other stuff I don't care ATM ;) ). The other iteration could be updating to new ABI.

Comment 8 Nick Clifton 2017-08-09 13:54:58 UTC
I am reassigning this to checksec for now.  If there are problems updating checksec however, I will revisit the idea of patching readelf.

Comment 9 Jan Kurik 2017-08-15 06:37:05 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 10 Vít Ondruch 2017-08-25 12:26:59 UTC
I reported this upstream to move it forward.

Comment 11 Vít Ondruch 2017-08-25 15:46:51 UTC
@Nick, would you mind to answer the upstream ticket:

https://github.com/slimm609/checksec.sh/issues/53#issuecomment-324917224

I don't have readily available PPC64LE at my hand and together with Dan, we were not able to provide answer (what is the required combination of binutils, glibc and what else to actually reproduce this?)

Comment 12 Nick Clifton 2017-08-29 12:44:35 UTC
Hi Vit,

  I have added a comment as requested.

Cheers
  Nick

Comment 13 Vít Ondruch 2017-08-30 08:40:18 UTC
(In reply to Nick Clifton from comment #12)
Noticed and appreciated :)

Comment 14 Vít Ondruch 2017-12-12 15:52:59 UTC
So now the upstream report is closed since there was no feedback from our side :/ Any chance to fix this?

Comment 15 Nick Clifton 2017-12-12 17:03:44 UTC
Hi Vit,

  OK, please try: binutils-2.29.1-9.fc28

  This is only for rawhide at the moment as I am not 100% sure that it will
  work.  (Plus I do not really like what the patch does).  If it does work
  for you however then I will backport it to F27.

Cheers
  Nick

Comment 16 Vít Ondruch 2017-12-13 09:41:40 UTC
The build [1] is not finished yet, but it is past the checksec test already, so it seems you patch fixed the issue.

I also linked the patch you applied to binutils to the checksec upstream issue, if it helps them to understand the issue better.

Thx.


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=23664013

Comment 17 Nick Clifton 2017-12-15 12:38:57 UTC
Fixed in: binutils-2.29-11.fc27

Comment 18 Fedora Update System 2018-03-08 14:21:16 UTC
binutils-2.29-13.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1e994c659e

Comment 19 Fedora Update System 2018-03-08 16:24:41 UTC
binutils-2.29-13.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1e994c659e

Comment 20 Fedora Update System 2018-03-13 23:18:02 UTC
binutils-2.29-13.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.