[PATCH] D67078: [llvm-readelf] - Allow dumping the dynamic symbols when there is no program headers.

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 3 01:29:44 PDT 2019


MaskRay added inline comments.


================
Comment at: test/tools/llvm-readobj/dyn-symbols.test:185
+      - Tag:   DT_SYMTAB
+        Value: 0
+      - Tag:   DT_NULL
----------------
grimar wrote:
> MaskRay wrote:
> > The test is different from https://reviews.llvm.org/D62179#1652778
> > 
> > In https://reviews.llvm.org/D62179#1652778, there is no program headers (corrupted phdr), so toMappedAddr returns a nullptr. Here, DT_SYMTAB is 0. When the information from DT_SYMTAB and .dynsym conflict, we probably should let DT_DYNTAB win...
> > The test is different from https://reviews.llvm.org/D62179#1652778
> 
> I think not. Here is the same YAML but with the program headers:
> 
> ```
> --- !ELF
> FileHeader:
>   Class:   ELFCLASS64
>   Data:    ELFDATA2LSB
>   Type:    ET_DYN
>   Machine: EM_X86_64
> Sections:
>   - Name:    .dynamic
>     Type:    SHT_DYNAMIC
>     Entries:
>       - Tag:   DT_SYMTAB
>         Value: 0
>       - Tag:   DT_NULL
>         Value: 0
> DynamicSymbols:
>   - Name: foo
> ProgramHeaders:
>   - Type: PT_LOAD
>     Flags: [ PF_R ]
>     VAddr: 0x0000
>     PAddr: 0x0000
>     Align: 8
>     Sections:
>       - Section: .dynsym
> ```
> 
> The 0 value for DT_SYMTAB is valid. I just removed the `ProgramHeaders`.
> 
> > When the information from DT_SYMTAB and .dynsym conflict, we probably should let DT_DYNTAB win...
> 
> I do not understand why. Particulary I do not understand why we should take .dynsym size from the section headers table
> (it is the only source it seems), but its address from another place.
> The much simpler logic is to try to take everything from section header at first and fallback to DT_SYMTAB. This is what this patch does.
> 
> If we have different results, then I guess it would be correct to report a warning, but I am not sure why DT_SYMTAB should win.
> Doesn't it mean we have a broken object? In this case why should we make any assumptions about which place is correct and which is not?
There are two approaches to locate the dynamic symbol table:

* program header -> PT_DYNAMIC -> DT_SYMTAB
* section header -> .dynsym

The first approach is used by the final consumer of an executable/shared object: ld.so or some other interpreter/emulator. They locate the dynamic table (from a program header), parse it, and use DT_SYMTAB to resolve symbol lookups. They ignore the section header. Prioritizing the section header can potentially be cheated by a malicious binary.

>   // Information in the section header has priority over the information
>  // in a PT_DYNAMIC header.

So, I think we should probably prioritize the information in PT_DYNAMIC.


In this case, the program header does not exist. I think it is fine to ignore DT_SYMTAB in the first approach.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67078/new/

https://reviews.llvm.org/D67078





More information about the llvm-commits mailing list