On 2/24/11 10:41 PM, Jeff Johnson wrote:
>
> On Feb 24, 2011, at 11:14 PM, Mark Hatle wrote:
>
>> I'm trying to validate prelinked binaries and I'm getting a somewhat strange
>> result:
>>
>> ........ /bin
>> S.?..... /bin/bash
>> ........ /bin/bashbug
>>
>> The macro setting being used is:
>>
>> %__prelink_undo_cmd /usr/sbin/prelink prelink -y library
>>
>> I'm not sure what the '?' indicates, but I suspect it's some type of a
>> failure
>> to get the information from the prelinker.
>>
>
> Hmmm ... I'm pretty sure prelink affects only libraries, not executables.
> It has been years ...
Prelink affects any ELF executable. But it doesn't do much good on executables
unless the libraries are already prelinked... All the prelinker does is
predefine the ELF relocations so that ld.so doesn't need to compute them at load
time. (ld.so does however still have a check the relocations are valid, if
they're not then it falls back to the old way of computing them all at load
time.)
>> I have a strong suspicion the problem is actually on the prelink side -- but
>> I'm
>> not sure how to debug what RPM is doing that is ending up with the '?'.
>>
>
>> So first question -- what does the '?' indicate? Second, is there any
>> debugging
>> available that can help me understand what type of output the prelinker may
>> be
>> sending back to RPM so I can diagnose what may be wrong there?
>>
>
> ? == indeterminate like 700 root.root read by non-root.
I'm wondering if the pipe closed early (i.e. prelink didn't actually return any
data..)
> rpm is just trying to verify a digest on plaintext.
>
> Usually its just the content as plaintext.
>
> But prelink alters the content, so the digest has to be run off a pipe
> to prelink undo.
>
> prelink has builtin sha1/md5 options: try those.
I have run those, and I'm getting the results that I believe are correct. This
is why I'm not sure whats going wrong -- but I still suspect it's on the prelink
side of thins.
> And you can use /usr/bin/{md5sum.sha1sum,sha256sum} with prelink undo
> to duplicate exactly what rpm should be doing.
>
> Extract the digest and compare with the manual results.
>
> I hope you're not putting prelinked content in a *.rpm. That has
> a really obscure failure mode because rpmbuild assumes unprelinked
> plaintext which prelink undo tries to restore. If the content
> was already prelinked, then the digest will never match.
Nope, the prelinker is run after the filesystem is constructed...
--Mark
> But that doesn't sound like your problem, and its libraries, not executables,
> affected by prelink I'm almost certain (run readelf -a to tell whether
> prelinked
> or not. compare with the check implemented).
>
> hth
>
> 73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
