|Summary:||/usr/bin/strip generates garbage from valid ELF executables|
|Product:||[Retired] Red Hat Linux||Reporter:||John Reiser <jreiser>|
|Component:||binutils||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-10-07 13:40:47 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description John Reiser 2003-01-12 01:48:11 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 Description of problem: After applying /usr/bin/strip, executable ELF files that the kernel used to run, will not run anymore. In some cases I see "Illegal instruction", in other cases I see "bash: <a.elf>: cannot execute binary file". One broad case that fails is any ELF executable with e_shoff, e_shentsize, e_shnum, and e_shstrndx all zero. Such a file has an empty "linking view". This is no problem for executing, because execve() uses only the "execution view" [e_phnum, e_phoff, e_phentsize, e_entry], and totally ignores the "linking view". However, if the "linking view" is empty, then the output of 'strip' is just 92 bytes of headers, with no PT_LOAD at all; the file has been totally eviscerated. Trying to run it gets "cannot execute binary file". Instead, 'strip' should detect an empty "linking view", give a warning message, and leave the file alone. Another case that fails is an ELF executable with a second PT_LOAD having 0==.p_memsz, and that is not placed "next" after the first PT_LOAD. Such a PT_LOAD is useful for setting the value of brk(0). 'strip' changes p_vaddr to 0, and p_offset to "next", and also sets p_align to 4, even though the original value was 0x1000. Typically this destroys the relationship (0xfff & p_offset) == (0xfff & p_vaddr) which is required by execve(). Trying to run the result gets "Illegal instruction". 'strip' must preserve PT_LOAD.p_align and everything that it implies in conjunction with p_offset, p_vaddr, p_paddr. Version-Release number of selected component (if applicable): binutils-188.8.131.52.2-2 How reproducible: Always Steps to Reproduce: Using the date.upx.no_shdr and date.upx.shdr ELF executables that are attached to this bugreport: 1../a.elf # normal execution 2./usr/bin/strip ./a.elf # apply 'strip' 3../a.elf # try to execute the result of stripping Actual Results: $ ./date.upx.shdr.strip Illegal instruction $ ./date.upx.no_shdr.strip bash: ./date.upx.no_shdr.strip: cannot execute binary file Expected Results: $ ./date.upx.shdr Sat Jan 11 17:09:06 PST 2003 $ ./date.upx.no_shdr Sat Jan 11 17:09:09 PST 2003 Additional info:
Comment 1 John Reiser 2003-01-12 01:50:21 UTC
Created attachment 89309 [details] ELF executable with empty "linking view" /bin/date compressed by UPX (http://upx.sourceforge.net)
Comment 2 John Reiser 2003-01-12 01:51:46 UTC
Created attachment 89310 [details] result of stripping date.upx.no_shdr 92-bytes of headers, and nothing else; 'strip' gutted the file
Comment 3 John Reiser 2003-01-12 01:54:16 UTC
Created attachment 89311 [details] ELF executable with non-empty, compatible, linking view Output from a test version of UPX that supplies a linking view for compressed output executables.
Comment 4 John Reiser 2003-01-12 01:56:25 UTC
Created attachment 89312 [details] result of stripping date.upx.shdr The second PT_LOAD has been scrambled: p_align changed from 0x1000 to 4; p_offset changed to inhibit mmap().
Comment 5 John Reiser 2003-01-12 03:39:29 UTC
Why would 'strip' be applied to output from UPX? rpmbuild does it by default when building a binary package .rpm, and it's not obvious how to turn it off.
Comment 6 Miloslav Trmac 2004-02-05 07:47:01 UTC
*** Bug 76780 has been marked as a duplicate of this bug. ***
Comment 7 Jakub Jelinek 2004-10-07 13:40:47 UTC
binutils-184.108.40.206.2-8 issues warnings: strip date.upx.no_shdr BFD: date.upx.no_shdr: warning: Empty loadable segment detected, is this intentional ? BFD: date.upx.no_shdr: warning: Empty loadable segment detected, is this intentional ? strip: there are no sections to be copied! but doesn't change the binary.