lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 7 Jan 2021 10:55:55 -0800 From: Fangrui Song <maskray@...gle.com> To: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, x86@...nel.org Cc: linux-kernel@...r.kernel.org, clang-built-linux@...glegroups.com, Fangrui Song <maskray@...gle.com>, Arnd Bergmann <arnd@...db.de>, Nick Desaulniers <ndesaulniers@...gle.com>, Nathan Chancellor <natechancellor@...il.com> Subject: [PATCH v2] x86: Treat R_386_PLT32 as R_386_PC32 This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32"), but for i386. As far as Linux kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types with the requirement that the symbol address is significant. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types without the address significance requirement. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@...` with newer (2018) GNU as/LLVM integrated assembler. On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT, but R_386_PLT32 is arguably preferable for -fno-pic code as well: this can avoid a "canonical PLT entry" (st_shndx=0, st_value!=0) if the symbol turns out to be defined externally. clang-12 -fno-pic (since https://github.com/llvm/llvm-project/commit/961f31d8ad14c66829991522d73e14b5a96ff6d4) can emit R_386_PLT32 for compiler produced symbols (if we drop -ffreestanding for CONFIG_X86_32, library call optimization can produce newer declarations) and future GCC -fno-pic may emit R_386_PLT32 as well if an option like -fno-direct-access-external-data is adopted to avoid canonical PLT entry/copy relocations. Link: https://github.com/ClangBuiltLinux/linux/issues/1210 Link: https://github.com/llvm/llvm-project/commit/961f31d8ad14c66829991522d73e14b5a96ff6d4 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 Reported-by: Arnd Bergmann <arnd@...db.de> Signed-off-by: Fangrui Song <maskray@...gle.com> Reviewed-by: Nick Desaulniers <ndesaulniers@...gle.com> Reviewed-by: Nathan Chancellor <natechancellor@...il.com> Tested-by: Nick Desaulniers <ndesaulniers@...gle.com> Tested-by: Nathan Chancellor <natechancellor@...il.com> --- Change in v2: * Improve commit message --- arch/x86/kernel/module.c | 1 + arch/x86/tools/relocs.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c index 34b153cbd4ac..5e9a34b5bd74 100644 --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -114,6 +114,7 @@ int apply_relocate(Elf32_Shdr *sechdrs, *location += sym->st_value; break; case R_386_PC32: + case R_386_PLT32: /* Add the value, subtract its position */ *location += sym->st_value - (uint32_t)location; break; diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index ce7188cbdae5..717e48ca28b6 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -867,6 +867,7 @@ static int do_reloc32(struct section *sec, Elf_Rel *rel, Elf_Sym *sym, case R_386_PC32: case R_386_PC16: case R_386_PC8: + case R_386_PLT32: /* * NONE can be ignored and PC relative relocations don't * need to be adjusted. @@ -910,6 +911,7 @@ static int do_reloc_real(struct section *sec, Elf_Rel *rel, Elf_Sym *sym, case R_386_PC32: case R_386_PC16: case R_386_PC8: + case R_386_PLT32: /* * NONE can be ignored and PC relative relocations don't * need to be adjusted. -- 2.29.2.729.g45daf8777d-goog
Powered by blists - more mailing lists