Process recieves incomplete vdso

[fctorial]

I've written a program that runs on zircon. It triggers a page fault when it tries to read the passed in vdso beyond 9 4k pages of memory (36864 bytes):

https://gist.github.com/fctorial/24fa72964de6f861c40096a5d2bc07ce

This is the output of this program:

https://gist.github.com/fctorial/2bfb175c9a12b623583f2bc172e30d44

The offset of section headers (166896) plus the size of section headers adds up to the size of libzircon.so.debug.

What could be causing this issue?

[fctorial]

This process is being created by userboot.

[Marco Vanotti]

Hi fctorial,

If I recall correctly, the section headers is removed from the elf that gets loaded into userspace. What's the value of e_shnum? It should be zero.

When your program crashes, you can see where the vdso gets loaded. In my computer, the size is 0x9000 bytes, which matches your experience.

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "zircon-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zircon-dev+...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/zircon-dev/c9f7a28f-18b4-4ae6-9f20-9e38b5a9126an%40fuchsia.dev.

[Roland McGrath]

ELF sections are a development-time concept that does not exist at runtime when loading an ELF file such as an executable or shared library.

What you're doing with the vDSO is equivalent to what this C++ program does on its main executable:

#include <elf.h>                                                                
#include <link.h>                                                              
#include <inttypes.h>                                                          
#include <stdio.h>                                                              
                                                                               
extern "C" ElfW(Ehdr) __ehdr_start;                                            
                                                                               
int main(void) {                                                                
  printf("shoff %#" PRIx64 ", shnum %#" PRIu16 "\n",                            
         __ehdr_start.e_shoff, __ehdr_start.e_shnum);                          
  const ElfW(Shdr)* shdrs = reinterpret_cast<const ElfW(Shdr)*>(                
      reinterpret_cast<const char*>(&__ehdr_start) + __ehdr_start.e_shoff);    
  for (unsigned int i = 0; i < __ehdr_start.e_shnum; ++i) {                    
    printf("[%u] sh_type = %#x\n", i, shdrs[i].sh_type);                        
  }                                                                            
} 

If you build that e.g. on Linux with `g++ -g -o foo foo.cc` and run `./foo` you'll see that e_shoff and e_shnum are set (consistent with that `readelf -WS foo` shows you).

However, the `sh_type` values it prints out don't match up with the actual sections in the file `foo`.

That's because the section table is not part of the runtime image, even though the ELF file header that points to it is.  

If you look at `readelf -Wl foo` you'll see the program headers, and specifically the LOAD segments.  That shows the regions of the file on disk that actually map to the runtime image.  The rest of the file, such as the section table and the debugging information, are part of the file but not part of the runtime image.  If you want to look at the section table or the debugging information, you need to look at the file `foo`, not the runtime memory of a process running `foo`.

In the case of the vDSO, there is no original file that you see anywhere on disk in the running system.  You can see the runtime memory image in your memory, but that's all you get.  If you want to look at the vDSO's development-time details like its debugging information, you can find the original file in the Fuchsia build (easiest way is by build ID lookup) but it will never exist anywhere as a file on a Fuchsia device.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/zircon-dev/CAO7cxQVZJpvpwjaOfwtgPWubw3B%3D%2BhJZbzxAvwzboy%3D2ZEg2gA%40mail.gmail.com.

[fctorial]

This makes sense. I was trying to parse the vdso by reading the symbol table (locating it via section table). It worked for libzircon.so but failed for vdso. What is the intended way of locating the functions in the vdso?

[fctorial]

Never mind. It can be done with program headers. Thanks.

[Roland McGrath]

Usually programs just rely on the dynamic linker to do this, e.g. with `dlsym(RTLD_NEXT, "_zx_foobar")` or `void* ptr = dlopen("libzircon.so", RTLD_NOW)` followed by `dlsym(ptr, "_zx_foobar")`.  But indeed if you are doing it from scratch (and what the dynamic linker is doing under the covers) is using the ELF file header (e_phoff/e_phnum) to find the program headers and using PT_DYNAMIC to find the dynamic symbol table and other such things in memory.