Bug#328850: klibc binaries
I took a longer look at this, and I don't think we'll be able to properly
detect klibc binaries without an additional collection.
The binaries *are* statically linked from an ELF perspective in that they
don't have a dynamic section. I'm not sure exactly how the klibc magic
works, but they are detectable with readelf -l:
Elf file type is EXEC (Executable file)
Entry point 0x8048540
There are 5 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000a0 0x000a0 R E 0x4
INTERP 0x0000d4 0x080480d4 0x080480d4 0x0002a 0x0002a R 0x1
[Requesting program interpreter: /lib/klibc-zol8wN9pEqndsie3MhJUi0Im1cM.so]
LOAD 0x000000 0x08048000 0x08048000 0x0079c 0x0079c R E 0x1000
LOAD 0x0007a0 0x080497a0 0x080497a0 0x00000 0x0104c RW 0x1000
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .text .rodata
03 .bss
04
The program interpreter of /lib/klibc-STUFF.so is the giveaway, and
binaries with that INTERP section should be excluded from the statically
linked tag.
The problem is that objdump doesn't give that information:
cat: file format elf32-i386
Program Header:
PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
filesz 0x000000a0 memsz 0x000000a0 flags r-x
INTERP off 0x000000d4 vaddr 0x080480d4 paddr 0x080480d4 align 2**0
filesz 0x0000002a memsz 0x0000002a flags r--
LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
filesz 0x0000079c memsz 0x0000079c flags r-x
LOAD off 0x000007a0 vaddr 0x080497a0 paddr 0x080497a0 align 2**12
filesz 0x00000000 memsz 0x0000104c flags rw-
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rwx
It shows that there is an INTERP section, but doesn't show the value.
Since we don't currently have a readelf collection, we don't currently
have a way of detecting this.
readelf could *maybe* replace objdump and produce the same information,
but that would be a huge change and not one that I think would be a
worthwhile investment of effort. So this would be a separate collection
run (or an additional run of readelf -l in the existing run, which is
probably the easiest way of doing it).
I see that readelf has been in binutils for a good approximation of
forever, so that doesn't mean a new dependency. I'm taking a look at
what would be involved now.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: