prelink performance gains

Robert Relyea rrelyea at redhat.com
Fri Oct 18 20:58:20 UTC 2013


On 10/17/2013 06:48 AM, Jan Kratochvil wrote:
> On Thu, 17 Oct 2013 00:16:35 +0200, Robert Relyea wrote:
>> prelink throws rocks at a lot of packages that have to check the
>> integrity of the shared libraries they are using. It provides no real
>> useful way of assisting in those tasks,
> It provides 'prelink -y' only for exactly that purpose.
> There is a bug in -y; but it does not work in some (rare) cases.
>   https://bugzilla.redhat.com/show_bug.cgi?id=666143
> Workaround of that bug is one line of code, it just has not been accepted yet.
>
>
>
> I do not know the FIPS prelink issues to be able to talk more about it.
>
>
>> 2. FIPS isn't the only place you need to do sofware integrity checks.
>> (see rpm).
> rpm uses prelink -y so it already works in most cases and the rare cases can
> be fixed in prelink.  The problem is its maintainer Jakub has more significant
> work to do nowadays.

I use it as well, but it causes all sorts of problems (particularly in
selinux restricted apps) because it's really unfriendly for a library to
exec a random program and open a pipe. One of the things that would have
to be done would be either 1) provide a library call that can supply the
unlinked data, or 2) provide infrastructure in prelink that can reliably
update the integrity check files in a way that doesn't race the changed
libraries (and in a way that makes sure only prelink changed the
libraries, not someone else).

Both of these are easy to get wrong.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4521 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131018/56296ac3/attachment-0001.p7s>


More information about the devel mailing list