summaryrefslogtreecommitdiff
path: root/arch/powerpc/include/asm/elf.h
AgeCommit message (Collapse)AuthorFilesLines
2015-04-14mm: fold arch_randomize_brk into ARCH_HAS_ELF_RANDOMIZEKees Cook1-4/+0
The arch_randomize_brk() function is used on several architectures, even those that don't support ET_DYN ASLR. To avoid bulky extern/#define tricks, consolidate the support under CONFIG_ARCH_HAS_ELF_RANDOMIZE for the architectures that support it, while still handling CONFIG_COMPAT_BRK. Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Hector Marco-Gisbert <hecmargi@upv.es> Cc: Russell King <linux@arm.linux.org.uk> Reviewed-by: Ingo Molnar <mingo@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: "David A. Long" <dave.long@linaro.org> Cc: Andrey Ryabinin <a.ryabinin@samsung.com> Cc: Arun Chandran <achandran@mvista.com> Cc: Yann Droneaud <ydroneaud@opteya.com> Cc: Min-Hua Chen <orca.chen@gmail.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Alex Smith <alex@alex-smith.me.uk> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Vineeth Vijayan <vvijayan@mvista.com> Cc: Jeff Bailey <jeffbailey@google.com> Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Behan Webster <behanw@converseincode.com> Cc: Ismael Ripoll <iripoll@upv.es> Cc: Jan-Simon Mller <dl9pf@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-17powerpc: Use generic PIE randomizationVineeth Vijayan1-2/+1
Back in 2009 we merged 501cb16d3cfd "Randomise PIEs", which added support for randomizing PIE (Position Independent Executable) binaries. That commit added randomize_et_dyn(), which correctly randomized the addresses, but failed to honor PF_RANDOMIZE. That means it was not possible to disable PIE randomization via the personality flag, or /proc/sys/kernel/randomize_va_space. Since then there has been generic support for PIE randomization added to binfmt_elf.c, selectable via ARCH_BINFMT_ELF_RANDOMIZE_PIE. Enabling that allows us to drop randomize_et_dyn(), which means we start honoring PF_RANDOMIZE correctly. It also causes a fairly major change to how we layout PIE binaries. Currently we will place the binary at 512MB-520MB for 32 bit binaries, or 512MB-1.5GB for 64 bit binaries, eg: $ cat /proc/$$/maps 4e550000-4e580000 r-xp 00000000 08:02 129813 /bin/dash 4e580000-4e590000 rw-p 00020000 08:02 129813 /bin/dash 10014110000-10014140000 rw-p 00000000 00:00 0 [heap] 3fffaa3f0000-3fffaa5a0000 r-xp 00000000 08:02 921 /lib/powerpc64le-linux-gnu/libc-2.19.so 3fffaa5a0000-3fffaa5b0000 rw-p 001a0000 08:02 921 /lib/powerpc64le-linux-gnu/libc-2.19.so 3fffaa5c0000-3fffaa5d0000 rw-p 00000000 00:00 0 3fffaa5d0000-3fffaa5f0000 r-xp 00000000 00:00 0 [vdso] 3fffaa5f0000-3fffaa620000 r-xp 00000000 08:02 1246 /lib/powerpc64le-linux-gnu/ld-2.19.so 3fffaa620000-3fffaa630000 rw-p 00020000 08:02 1246 /lib/powerpc64le-linux-gnu/ld-2.19.so 3ffffc340000-3ffffc370000 rw-p 00000000 00:00 0 [stack] With this commit applied we don't do any special randomisation for the binary, and instead rely on mmap randomisation. This means the binary ends up at high addresses, eg: $ cat /proc/$$/maps 3fff99820000-3fff999d0000 r-xp 00000000 08:02 921 /lib/powerpc64le-linux-gnu/libc-2.19.so 3fff999d0000-3fff999e0000 rw-p 001a0000 08:02 921 /lib/powerpc64le-linux-gnu/libc-2.19.so 3fff999f0000-3fff99a00000 rw-p 00000000 00:00 0 3fff99a00000-3fff99a20000 r-xp 00000000 00:00 0 [vdso] 3fff99a20000-3fff99a50000 r-xp 00000000 08:02 1246 /lib/powerpc64le-linux-gnu/ld-2.19.so 3fff99a50000-3fff99a60000 rw-p 00020000 08:02 1246 /lib/powerpc64le-linux-gnu/ld-2.19.so 3fff99a60000-3fff99a90000 r-xp 00000000 08:02 129813 /bin/dash 3fff99a90000-3fff99aa0000 rw-p 00020000 08:02 129813 /bin/dash 3fffc3de0000-3fffc3e10000 rw-p 00000000 00:00 0 [stack] 3fffc55e0000-3fffc5610000 rw-p 00000000 00:00 0 [heap] Although this should be OK, it's possible it might break badly written binaries that make assumptions about the address space layout. Signed-off-by: Vineeth Vijayan <vvijayan@mvista.com> [mpe: Rewrite changelog] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-05-20powerpc: Clear ELF personality flag if ELFv2 is not requested.Jeff Bailey1-0/+2
powerpc: Clear ELF personality flag if ELFv2 is not requested. The POWER kernel uses a personality flag to determine whether it should be setting up function descriptors or not (per the updated ABI). This flag wasn't being cleared on a new process but instead was being inherited. The visible effect was that an ELFv2 binary could not execve to an ELFv1 binary. Signed-off-by: Jeff Bailey <jeffbailey@google.com> arch/powerpc/include/asm/elf.h | 2 ++ 1 file changed, 2 insertions(+) Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Set eflags correctly for ELF ABIv2 core dumps.Rusty Russell1-0/+2
We leave it at zero (though it could be 1) for old tasks. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Add TIF_ELF2ABI flag.Rusty Russell1-0/+2
Little endian ppc64 is getting an exciting new ABI. This is reflected by the bottom two bits of e_flags in the ELF header: 0 == legacy binaries (v1 ABI) 1 == binaries using the old ABI (compiled with a new toolchain) 2 == binaries using the new ABI. We store this in a thread flag, because we need to set it in core dumps and for signal delivery. Our chief concern is that it doesn't use function descriptors. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-04-26powerpc: Add HWCAP2 aux entryMichael Neuling1-0/+1
We are currently out of free bits in AT_HWCAP. With POWER8, we have several hardware features that we need to advertise. Tested on POWER and x86. Signed-off-by: Michael Neuling <michael@neuling.org> Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-02-26default SET_PERSONALITY() in linux/elf.hAl Viro1-2/+0
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-10-09UAPI: (Scripted) Disintegrate arch/powerpc/include/asmDavid Howells1-305/+6
Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
2011-07-21treewide: fix potentially dangerous trailing ';' in #defined values/expressionsPhil Carmody1-2/+2
All these are instances of #define NAME value; or #define NAME(params_opt) value; These of course fail to build when used in contexts like if(foo $OP NAME) while(bar $OP NAME) and may silently generate the wrong code in contexts such as foo = NAME + 1; /* foo = value; + 1; */ bar = NAME - 1; /* bar = value; - 1; */ baz = NAME & quux; /* baz = value; & quux; */ Reported on comp.lang.c, Message-ID: <ab0d55fe-25e5-482b-811e-c475aa6065c3@c29g2000yqd.googlegroups.com> Initial analysis of the dangers provided by Keith Thompson in that thread. There are many more instances of more complicated macros having unnecessary trailing semicolons, but this pile seems to be all of the cases of simple values suffering from the problem. (Thus things that are likely to be found in one of the contexts above, more complicated ones aren't.) Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-09-02powerpc: Use is_32bit_task() helper to test 32-bit binaryDenis Kirjanov1-1/+1
This patch removes all explicit tests for the TIF_32BIT flag Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2010-02-01powerpc: TIF_ABI_PENDING bit removalAndreas Schwab1-6/+2
Here are the powerpc bits to remove TIF_ABI_PENDING now that set_personality() is called at the appropriate place in exec. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-12-16elf: kill USE_ELF_CORE_DUMPChristoph Hellwig1-1/+0
Currently all architectures but microblaze unconditionally define USE_ELF_CORE_DUMP. The microblaze omission seems like an error to me, so let's kill this ifdef and make sure we are the same everywhere. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: <linux-arch@vger.kernel.org> Cc: Michal Simek <michal.simek@petalogix.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-21powerpc: Fix up elf_read_implies_exec() usageKumar Gala1-2/+2
We believe if a toolchain supports PT_GNU_STACK that it sets the proper PHDR permissions. Therefor elf_read_implies_exec() should only be true if we don't see PT_GNU_STACK set. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-04-28powerpc: ppc32 needs elf_read_implies_exec()Kumar Gala1-0/+1
On ppc64 we implemented elf_read_implies_exec() for 32-bit binaries because old toolchains had bugs where they didn't mark program segments executable that needed to be. For some reason we didn't do this on ppc32 builds. This hadn't been an issue until commit 8d30c14c ("powerpc/mm: Rework I$/D$ coherency (v3)"), which had as a side effect that we are now enforcing execute permissions to some extent on 32-bit 4xx and Book E processors. This fixes it by defining elf_read_implies_exec on 32-bit to turn on the read-implies-exec behaviour on programs that are sufficiently old that they don't have a PT_GNU_STACK program header. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-22powerpc/32: Don't clobber personality flags on execAndreas Schwab1-1/+2
Now that ppc32 implements address randomization it also wants to inherit personality flags like ADDR_NO_RANDOMIZE across exec, for things like `setarch ppc -R' to work. But the ppc32 version of SET_PERSONALITY forcefully sets PER_LINUX, clearing all personality flags. So be careful about preserving the flags. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-02-23powerpc: Randomise PIEsAnton Blanchard1-1/+2
Randomise ELF_ET_DYN_BASE, which is used when loading position independent executables. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-02-23powerpc: Randomise the brk regionAnton Blanchard1-0/+3
Randomize the heap. before: tundro2:~ # sleep 1 & cat /proc/${!}/maps | grep heap 10017000-10118000 rw-p 10017000 00:00 0 [heap] 10017000-10118000 rw-p 10017000 00:00 0 [heap] 10017000-10118000 rw-p 10017000 00:00 0 [heap] 10017000-10118000 rw-p 10017000 00:00 0 [heap] 10017000-10118000 rw-p 10017000 00:00 0 [heap] after tundro2:~ # sleep 1 & cat /proc/${!}/maps | grep heap 19419000-1951a000 rw-p 19419000 00:00 0 [heap] 325ff000-32700000 rw-p 325ff000 00:00 0 [heap] 1a97c000-1aa7d000 rw-p 1a97c000 00:00 0 [heap] 1cc60000-1cd61000 rw-p 1cc60000 00:00 0 [heap] 1afa9000-1b0aa000 rw-p 1afa9000 00:00 0 [heap] Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-02-23powerpc: More stack randomisation for 64bit binariesAnton Blanchard1-0/+5
At the moment we randomise the stack by 8MB on 32bit and 64bit tasks. Since we have a lot more address space to play with on 64bit, lets do what x86 does and increase that randomisation to 1GB: before: # for i in seq `1 10` ; do sleep 1 & cat /proc/${!}/maps | grep stack; done fffffebc000-fffffed1000 rw-p ffffffeb000 00:00 0 [stack] ffffff5a000-ffffff6f000 rw-p ffffffeb000 00:00 0 [stack] fffffdb2000-fffffdc7000 rw-p ffffffeb000 00:00 0 [stack] fffffd3e000-fffffd53000 rw-p ffffffeb000 00:00 0 [stack] fffffad9000-fffffaee000 rw-p ffffffeb000 00:00 0 [stack] after: # for i in seq `1 10` ; do sleep 1 & cat /proc/${!}/maps | grep stack; done ffff5c27000-ffff5c3c000 rw-p ffffffeb000 00:00 0 [stack] fffebe5e000-fffebe73000 rw-p ffffffeb000 00:00 0 [stack] fffcb298000-fffcb2ad000 rw-p ffffffeb000 00:00 0 [stack] fffc719d000-fffc71b2000 rw-p ffffffeb000 00:00 0 [stack] fffe01af000-fffe01c4000 rw-p ffffffeb000 00:00 0 [stack] Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-02-23powerpc: Fix warnings from make headers_checkKumar Gala1-1/+2
include/asm/bootx.h:12: include of <linux/types.h> is preferred over <asm/types.h> include/asm/bootx.h:57: found __[us]{8,16,32,64} type without #include <linux/types.h> include/asm/elf.h:5: include of <linux/types.h> is preferred over <asm/types.h> include/asm/kvm.h:23: include of <linux/types.h> is preferred over <asm/types.h> include/asm/kvm.h:26: found __[us]{8,16,32,64} type without #include <linux/types.h> include/asm/ps3fb.h:33: found __[us]{8,16,32,64} type without #include <linux/types.h> include/asm/spu_info.h:27: found __[us]{8,16,32,64} type without #include <linux/types.h> include/asm/swab.h:11: include of <linux/types.h> is preferred over <asm/types.h> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-12-25[S390] arch_setup_additional_pages argumentsMartin Schwidefsky1-1/+1
arch_setup_additional_pages currently gets two arguments, the binary format descripton and an indication if the process uses an executable stack or not. The second argument is not used by anybody, it could be removed without replacement. What actually does make sense is to pass an indication if the process uses the elf interpreter or not. The glibc code will not use anything from the vdso if the process does not use the dynamic linker, so for statically linked binaries the architecture backend can choose not to map the vdso. Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-10-16[PATCH] remove unused ibcs2/PER_SVR4 in SET_PERSONALITYMartin Schwidefsky1-2/+2
The SET_PERSONALITY macro is always called with a second argument of 0. Remove the ibcs argument and the various tests to set the PER_SVR4 personality. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-09-17Fix compile failure with non modular buildsJames Bottomley1-0/+7
Commit deac93df26b20cf8438339b5935b5f5643bc30c9 ("lib: Correct printk %pF to work on all architectures") broke the non modular builds by moving an essential function into modules.c. Fix this by moving it out again and into asm/sections.h as an inline. To do this, the definition of struct ppc64_opd_entry has been lifted out of modules.c and put in asm/elf.h where it belongs. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-04powerpc: Move include files to arch/powerpc/include/asmStephen Rothwell1-0/+424
from include/asm-powerpc. This is the result of a mkdir arch/powerpc/include/asm git mv include/asm-powerpc/* arch/powerpc/include/asm Followed by a few documentation/comment fixups and a couple of places where <asm-powepc/...> was being used explicitly. Of the latter only one was outside the arch code and it is a driver only built for powerpc. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 03:53:30 +0000