kernel.git/arch/x86/tools, branch linux-3.18.y

x86: Treat R_X86_64_PLT32 as R_X86_64_PC32

2018-03-18T10:15:44Z

commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream. On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu Signed-off-by: Linus Torvalds Cc: Matthias Kaehlcke Signed-off-by: Greg Kroah-Hartman

x86/tools: Fix gcc-7 warning in relocs.c

2017-09-02T05:05:46Z

commit 7ebb916782949621ff6819acf373a06902df7679 upstream. gcc-7 warns: In file included from arch/x86/tools/relocs_64.c:17:0: arch/x86/tools/relocs.c: In function ‘process_64’: arch/x86/tools/relocs.c:953:2: warning: argument 1 null where non-null expected [-Wnonnull] qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from arch/x86/tools/relocs.h:6:0, from arch/x86/tools/relocs_64.c:1: /usr/include/stdlib.h:741:13: note: in a call to function ‘qsort’ declared here extern void qsort This happens because relocs16 is not used for ELF_BITS == 64, so there is no point in trying to sort it. Make the sort_relocs(&relocs16) call 32bit only. Signed-off-by: Markus Trippelsdorf Link: http://lkml.kernel.org/r/20161215124513.GA289@x4 Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

x86-64: Handle PC-relative relocations on per-CPU data

2017-09-02T05:05:46Z

commit 6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba upstream. This is in preparation of using RIP-relative addressing in many of the per-CPU accesses. Signed-off-by: Jan Beulich Link: http://lkml.kernel.org/r/5458A15A0200007800044A9A@mail.emea.novell.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

x86, build: replace Perl script with Shell script

2015-02-06T06:36:00Z

commit d69911a68c865b152a067feaa45e98e6bb0f655b upstream. Commit e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd") added Perl to the required build environment. This reimplements in shell the Perl script used to find the size of the kernel with bss and brk added. Signed-off-by: Kees Cook Reported-by: Rob Landley Acked-by: Rob Landley Cc: Anca Emanuel Cc: Fengguang Wu Cc: Junjie Mao Cc: Kees Cook Cc: Thomas Gleixner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86, kaslr: Handle Gold linker for finding bss/brk

2014-11-18T17:32:24Z

When building with the Gold linker, the .bss and .brk areas of vmlinux are shown as consecutive instead of having the same file offset. Allow for either state, as long as things add up correctly. Fixes: e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd") Reported-by: Markus Trippelsdorf Signed-off-by: Kees Cook Cc: Junjie Mao Link: http://lkml.kernel.org/r/20141118001604.GA25045@www.outflux.net Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner

x86, kaslr: Prevent .bss from overlaping initrd

2014-11-01T21:20:50Z

When choosing a random address, the current implementation does not take into account the reversed space for .bss and .brk sections. Thus the relocated kernel may overlap other components in memory. Here is an example of the overlap from a x86_64 kernel in qemu (the ranges of physical addresses are presented): Physical Address 0x0fe00000 --+--------------------+ <-- randomized base / | relocated kernel | vmlinux.bin | (from vmlinux.bin) | 0x1336d000 (an ELF file) +--------------------+-- \ | | \ 0x1376d870 --+--------------------+ | | relocs table | | 0x13c1c2a8 +--------------------+ .bss and .brk | | | 0x13ce6000 +--------------------+ | | | / 0x13f77000 | initrd |-- | | 0x13fef374 +--------------------+ The initrd image will then be overwritten by the memset during early initialization: [ 1.655204] Unpacking initramfs... [ 1.662831] Initramfs unpacking failed: junk in compressed archive This patch prevents the above situation by requiring a larger space when looking for a random kernel base, so that existing logic can effectively avoids the overlap. [kees: switched to perl to avoid hex translation pain in mawk vs gawk] [kees: calculated overlap without relocs table] Fixes: 82fa9637a2 ("x86, kaslr: Select random position from e820 maps") Reported-by: Fengguang Wu Signed-off-by: Junjie Mao Signed-off-by: Kees Cook Cc: Josh Triplett Cc: Matt Fleming Cc: Ard Biesheuvel Cc: Vivek Goyal Cc: Andi Kleen Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1414762838-13067-1-git-send-email-eternal.n08@gmail.com Signed-off-by: Thomas Gleixner

x86/relocs: Make per_cpu_load_addr static

2014-09-24T13:17:47Z

per_cpu_load_addr is only used for 64-bit relocations, but is declared in both configurations of relocs.c - with different types. This has undefined behaviour in general. GNU ld is documented to use the larger size in this case, but other tools may differ and some warn about this. References: https://bugs.debian.org/748577 Reported-by: Michael Tautschnig Signed-off-by: Ben Hutchings Cc: 748577@bugs.debian.org Cc: Linus Torvalds Link: http://lkml.kernel.org/r/1411561812.3659.23.camel@decadent.org.uk Signed-off-by: Ingo Molnar

x86/build: Supress "Nothing to be done for ..." messages

2014-04-14T09:44:36Z

When we build an already built kernel again, arch/x86/syscalls/Makefile and arch/x86/tools/Makefile emits "Nothing to be done for ..." messages. Here is the command log: $ make defconfig [ snip ] $ make [ snip ] $ make make[1]: Nothing to be done for `all'. <----- make[1]: Nothing to be done for `relocs'. <----- CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h Besides not emitting those, "all" and "relocs" should be added to PHONY as well. Signed-off-by: Masahiro Yamada Acked-by: Peter Foley Acked-by: Michal Marek Link: http://lkml.kernel.org/r/1397093742-11144-1-git-send-email-yamada.m@jp.panasonic.com Signed-off-by: Ingo Molnar

x86, vdso: Make vsyscall_gtod_data handling x86 generic

2014-03-18T19:51:52Z

This patch move the vsyscall_gtod_data handling out of vsyscall_64.c into an additonal file vsyscall_gtod.c to make the functionality available for x86 32 bit kernel. It also adds a new vsyscall_32.c which setup the VVAR page. Reviewed-by: Andy Lutomirski Signed-off-by: Stefani Seibold Link: http://lkml.kernel.org/r/1395094933-14252-2-git-send-email-stefani@seibold.net Signed-off-by: H. Peter Anvin

Merge commit 'f4bcd8ccddb02833340652e9f46f5127828eb79d' into x86/build

2014-01-29T17:07:00Z

Bring in upstream merge of x86/kaslr for future patches. Signed-off-by: H. Peter Anvin