Change Details

Due to issues like https://reviews.llvm.org/D70570 (with more details @ https://reviews.llvm.org/D38554 ), clang's support for freestanding / static model / "EABI" code is still slightly lacking on ppc32. As such, I'm investigating building powerpc* kernel modules as PIC (enforced secure-plt on powerpc32) * Add elf_cpu_parse_dynamic() to allow MD code to do its own DYNAMIC parsing. Add stubs to all link_elf.c platforms. * Implement jump table relocation for ppc32 secure-plt LD_BIND_NOW style and add a check to ensure it is only loading secure-plt modules (using elf_cpu_parse_dynamic()) * Build kernel modules -fPIC on powerpc*. * Poison the powerpc32 runtime resolver to ensure any attempts to call it cause an appropriate panic instead of a branch-to-zero. Todo: * ~~Figure out why dtrace is broken again.~~ Was due to CTF type bloat, again. * Use elf_cpu_parse_dynamic() to make ppc64 module loading more robust? * Document rationale behind this change * ~~ELFv1 (gcc4) testing.~~ ELFv1 works with -fPIC (and doesn't generate PLT slots.)

Due to issues like https://reviews.llvm.org/D70570 (with more details @ https://reviews.llvm.org/D38554 ), clang's support for freestanding / static model / "EABI" code is still slightly lacking on ppc32. As such, I'm investigating building powerpc* kernel modules as PIC (enforced secure-plt on powerpc32) * Add elf_cpu_parse_dynamic() to allow MD code to do its own DYNAMIC parsing. Add stubs to all link_elf.c platforms. * Implement jump table relocation for ppc32 secure-plt LD_BIND_NOW style and add a check to ensure it is only loading secure-plt modules (using elf_cpu_parse_dynamic()) * Build kernel modules -fPIC on powerpc*. * Poison the powerpc32 runtime resolver to ensure any attempts to call it cause an appropriate panic instead of a branch-to-zero. Todo: * ~~Figure out why dtrace is broken again.~~ Was due to CTF type bloat, again. * Use elf_cpu_parse_dynamic() to make ppc64 module loading more robust? * Document rationale behind this change * ~~ELFv1 (gcc4) testing.~~ ELFv1 works with -fPIC (and doesn't generate PLT slots.) * add kib or jhb to reviewers list after this summary is cleaned up Contra indications: * Using PIC kernel modules crashes GCC4 when compiling module<->module linker sets. (accf_http, etc.)

Due to issues like https://reviews.llvm.org/D70570 (with more details @ https://reviews.llvm.org/D38554 ), clang's support for freestanding / static model / "EABI" code is still slightly lacking on ppc32. As such, I'm investigating building powerpc* kernel modules as PIC (enforced secure-plt on powerpc32) * Add elf_cpu_parse_dynamic() to allow MD code to do its own DYNAMIC parsing. Add stubs to all link_elf.c platforms. * Implement jump table relocation for ppc32 secure-plt LD_BIND_NOW style and add a check to ensure it is only loading secure-plt modules (using elf_cpu_parse_dynamic()) * Build kernel modules -fPIC on powerpc*. * Poison the powerpc32 runtime resolver to ensure any attempts to call it cause an appropriate panic instead of a branch-to-zero. Todo: * ~~Figure out why dtrace is broken again.~~ Was due to CTF type bloat, again. * Use elf_cpu_parse_dynamic() to make ppc64 module loading more robust? * Document rationale behind this change * ~~ELFv1 (gcc4) testing.~~ ELFv1 works with -fPIC (and doesn't generate PLT slots.) * add kib or jhb to reviewers list after this summary is cleaned up Contra indications: * Using PIC kernel modules crashes GCC4 when compiling module<->module linker sets. (accf_http, etc.)