Hide Forgot
To verify the distribution-wide fix for bug 1631730, it would be great if we could enhance annobin to detect if the entry point starts with the right instruction. A bad binary looks like this: $ readelf -hW usr/lib/openmpi/bin/ompi_info | grep Entry Entry point address: 0x19d5 $ objdump -d --reloc usr/lib/openmpi/bin/ompi_info | grep -E '^\s+19d5:' 19d5: 31 ed xor %ebp,%ebp And a good binary: $ readelf -hW usr/lib/openmpi/bin/ompi_info | grep Entry Entry point address: 0x19e0 $ objdump -d --reloc usr/lib/openmpi/bin/ompi_info | grep -E '^\s+19e0:' 19e0: f3 0f 1e fb endbr32 So all you have to do is look up the entry point address and check that the four bytes there are 0xf3 0x0f 0x1e 0xfb (ENBR32, for i686), or 0xf3 0x0f 0x1e 0xfa (ENDBR64, for x86-64). I think this would really help with verification of bug 1631730. Thanks.
Hi Florian, I have updated the annobin sources with the check you have requested. I have not, however, checked these new sources into RHEL or Fedora, as I do not have any x86 or x86_64 binaries with the correct ENDBR instructions in order to test the new code. (Is there an easy way to obtain such binaries). Also, since QE are now using annocheck as part of the rpmdiff suite, I did not want to risk failing lots of new builds until the updates to glibc, and other languages start-up code, have been put in place. You can download the new sources from the annobin git repository, or from the my Fedora web-page: https://nickc.fedorapeople.org/annobin-8.62.tar.xz Would you mind trying it out and letting me know if it does what you want ? Cheers Nick
(In reply to Nick Clifton from comment #1) > I have updated the annobin sources with the check you have requested. > > I have not, however, checked these new sources into RHEL or Fedora, > as I do not have any x86 or x86_64 binaries with the correct ENDBR > instructions in order to test the new code. (Is there an easy way > to obtain such binaries). For i686, any RHEL 8 binary built after 2018-09-27 should have the correct instruction there. For x86-64, all binaries built for Beta should have that instruction. If you meant to write *incorrect* binaries, then openmpi-3.1.2-5.el8 will have such invalid i686 binaries. For x86-64, you would have to go back much further and look at builds for Alpha.
Hi Florian, Thanks. I have now tested the new version with ENDBR type binaries and it works, so I have checked the change in. Unfortunately I have just discovered a problem. The new annocheck will FAIL shared libraries because the instruction at their entry address is not ENDBR. Is this wrong ? (ie should shared objects also have ENDBR as their entry instruction ?) If not, then how can we distinguish between a shared library and a dynamic executable ? Cheers Nick
(In reply to Nick Clifton from comment #3) > Unfortunately I have just discovered a problem. The new annocheck > will FAIL shared libraries because the instruction at their entry > address is not ENDBR. Is this wrong ? (ie should shared objects > also have ENDBR as their entry instruction ?) If not, then how > can we distinguish between a shared library and a dynamic executable ? Yes, this is wrong. I didn't expect shared objects to have an entry point address. I think it just points to the start of the .text segment, and there is no expectation that this code is ever executed directly because the entry point is effectively ignored for shared objects. (DT_INIT and DT_INITARRAY point to different places.) I think a reasonable approximation would be to disable this check for binaries which do not have a program interpreter.
Hi Florian, Good idea. I have now added that check. Please try out annobin-8.63. Cheers Nick
Reproduced with annobin-8.61-1.el8. Verified with annobin-8.64-1.el8. Annocheck now reports either "FAIL: Entry point instruction is not ENDBR32." (and prints out the bytes at the entry point address), or "PASS: Entry point instruction is ENDBR.". Tested with regular build openmpi-3.1.2-5.el8.i686 (which does have this problem) versus a custom scratchbuild openmpi-3.1.2-5.mcermak.el8.i686 [1] (which doesn't). Thanks for implementing! ------- [1] https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=19352909