- Jul 04, 2017
-
-
Vivek Das Mohapatra authored
-
- Jun 28, 2017
-
-
Vivek Das Mohapatra authored
Not encountered this bug in practice but it is potentially there and waiting for us.
-
- May 24, 2017
-
-
Vivek Das Mohapatra authored
When munging the ELF data structures from the capsule-export code path via dl_iterate_phdr, we get the dynamic section size as a callback arg so we can double-check we haven't ended up outside the memory region we expect to be working on. Unfortunately when using link_map traversal to do the same sort of thing to install wrapper functions inside the capsule we don't have this information. We were using SIZE_MAX on ELFCLASS64 to pass a "big enough" size parameter but this calculation does not work on ELFCLASS32. Rather than go out of our way to produce a bogus-but-big-enough value we now pass 0 for the size and have the called functions know that they can't do the double-check if passed a size of 0. The last entry in the dyn section should have a D_TAG of DT_NULL anyway so we'll only crash off the end of the dynamic section if the linker is broken or malicious (which is probably not worth defending against, all things considered).
-
Vivek Das Mohapatra authored
The code path that installs wrappers inside the capsule is the same as the one that scribbles capsule functions out into the rest of the application - however if we don't want to turn on noisy debug in the ELF handling paths all the time - so we cheat and turn it on around the ELF munging call from the wrap function only if DEBUG_WRAPPERS is already in the flags.
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
This was a bug in our constraint checking for DSO types. It couldn't actually trigger for x86-64/64-bit DSOs as they are the only ones which are ELFCLASS64, but once we were testing 32 bit binaries it bit us as we were unable to distinguish i386 from x32.
-
Vivek Das Mohapatra authored
Dump out the class (ELFCLASS32 vs ELFCLASS64) and the machine (eg EM_386 vs EM_X86_64) of candidate DSOs. This matters when the target file tree is multi-arch, anc can contaim different classes and machines. x86 hardware typically has 3: ELFCLASS32/EM_386 - old school i[3456]86 binary ELFCLASS64/EM_X86_64 - straightforward x86-64 binary ELFCLASS32/EM_X86_64 - x32 (32 bit word size using x86-64 registers) But we don't want to open any that don't match the category we actually are.
-
Vivek Das Mohapatra authored
-
- May 23, 2017
-
-
Vivek Das Mohapatra authored
Define and use some per-word-size printf format macros so our debug functions can be -Wall -Werror clean on both models.
-
- May 19, 2017
-
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
- May 17, 2017
-
-
Vivek Das Mohapatra authored
We used to set the elf class (32 vs 64) and machine (eg EM_X86_64) from the first DSO we found in the path, but that was only ever coincidentally corect - if we had found a foreign arch (eg i386 or x32 from an x86_64 binary) then our whole link chain would have been pulled from the wrong architacture. Instead we should pick a DSO which has _already been successfully loaded_ and use that to pick only matching DSOs.
-
Vivek Das Mohapatra authored
-
- May 16, 2017
-
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
- May 12, 2017
-
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
If a path handed to us was absolute all we need do is trasnpose it to the capsule prefix and look for it there - it makes no sense to do the usual LD_LIBRARY_PATH; /lib/:/usr/lib; ld.so.cache searches for an absolute path.
-
Vivek Das Mohapatra authored
-
Vivek Das Mohapatra authored
-
- May 09, 2017
-
-
Vivek Das Mohapatra authored
The generated shim libraries (libz and libGL are included as examples) provide the same symbols as the target library but do not expose the symbols from their dependencies to other objects that link to them. They are also capable of using a filesystem tree starting somwhere other than / to get the dependencies for the target. Included are tools to help generate said proxy libraries with minimal manual intervention.
-