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.
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
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
Created attachment 1310652 [details] libruby
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 (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 (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
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...
I would prefer the checksec tool to get fixed/updated for the new ppc64le ABI features.
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.
I am reassigning this to checksec for now. If there are problems updating checksec however, I will revisit the idea of patching readelf.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
I reported this upstream to move it forward.
@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?)
Hi Vit, I have added a comment as requested. Cheers Nick
(In reply to Nick Clifton from comment #12) Noticed and appreciated :)
So now the upstream report is closed since there was no feedback from our side :/ Any chance to fix this?
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
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
Fixed in: binutils-2.29-11.fc27
binutils-2.29-13.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1e994c659e
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
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.