[lsb-bugs] [Bug 2402] appchk fails on binaries linked with relro option

[bugzilla-daemon at linux-foundation.org]

http://bugs.linuxbase.org/show_bug.cgi?id=2402





--- Comment #9 from Denis Silakov <silakov at ispras.ru>  2009-05-12 05:53:27 ---
Created an attachment (id=1508)
 --> (http://bugs.linuxbase.org/attachment.cgi?id=1508)
Update patch for elfchk/proghdr.c

Well, I digged more deeply in this and I think I found the root of the problem
- LSB elfchk actually doesn't treat PT_GNU_RELRO correctly. First, sections in
this segment should be allowed to have 'SHF_ALLOC|SHF_EXECINSTR' attributes
only (no SHF_WRITE). Second, '.got.plt' section may partially intersect with
PT_GNU_RELRO, even not being part of this segment - this feature is known to
upstream and allowed:

"The PT_GNU_RELRO segment may contain the first a few bytes in the .got.plt
section even if the whole .got.plt section isn't in the PT_GNU_RELRO segment. 
We won't change the size of the PT_GNU_RELRO segment."
(http://sourceware.org/ml/binutils/2007-09/msg00208.html).

During my experiments, I found no problems in launching binaries with 'illegal'
(from appchk point of view) section mapping on old systems (e.g. RHEL 4), so
this shouldn't cause problems for LSB applications. Thus, I suggest to fix
elfchk in two places:

1) allow sections in the PT_GNU_RELRO segment to have 'SHF_ALLOC|SHF_EXECINSTR'
attributes (this is an improvement for my previous patch that allowed this for
all sections);
2) skip 'section<->segment' mapping check if for PT_GNU_RELRO vs .got.plt.

The patch attached should implement this.

I'm not sure if we should mention this specific of PT_GNU_RELRO somewhere in
the spec. In any case, I think it makes sense to apply this patch right now,
since currently appchk declines all binaries built in many modern distros (with
default build flags), while there doesn't seem to be any actual problems with
them.


-- 
Configure bugmail: http://bugs.linuxbase.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.