find_aux_sym triggers a kernel heuristic

Josh Stone jistone at redhat.com
Mon Mar 10 21:37:46 UTC 2014


On 03/10/2014 02:23 PM, Mark Wielaard wrote:
> On Fri, 2014-03-07 at 17:39 -0800, Josh Stone wrote:
>> The gist is that I have an ET_EXEC binary, /usr/bin/ls.  When I call
>> dwfl_module_getsymtab -> find_symtab -> find_aux_sym -> open_elf, the
>> following heuristic is triggered:
>>
>> libdwfl/dwfl_module_getdwarf.c
>> 134│   mod->e_type = ehdr->e_type;
>> 135│
>> 136│   /* Relocatable Linux kernels are ET_EXEC but act like ET_DYN.  */
>> 137│   if (mod->e_type == ET_EXEC && file->vaddr != mod->low_addr)
>> 138├>    mod->e_type = ET_DYN;
>>
>> Here file->vaddr = 0x400020 and mod->low_addr = 0x400000, but this
>> certainly is not a kernel, and should not be treated as ET_DYN.
> 
> Right, this check doesn't make sense for a debug or aux file. Thanks for
> finding this.
>  
>> Maybe this only needs to add a check that file == &mod->main
> 
> Yes, I think that would be the correct thing to do. Both find_dw and
> find_symtab call __libdwfl_getelf first. So the main ELF file will
> always be loaded through open_elf first. After mod->e_type has been set
> it should not be set or changed again by either debug of aux file
> opening.

Ok.  I attached my simple patch which still passes the testsuite, and
also fixes my issue -- let me know how it works for you.

>> , but I
>> wonder if this heuristic is even needed at all, because report_kernel()
>> forcibly sets ET_DYN itself.
> 
> There is also dwfl_linux_kernel_report_offline which uses
> report_kernel_archive which might report a kernel through
> dwfl_report_offline which won't force the mod->e_type.

Ok.  FWIW, I even tried removing that block from open_elf altogether,
and it passed all tests, so it seems we could use more coverage here.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: open_elf-guard-e_type.patch
Type: text/x-patch
Size: 1011 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/elfutils-devel/attachments/20140310/6eaa8c59/attachment.bin>


More information about the elfutils-devel mailing list