2019-05-19 12:08:20 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* linux/fs/binfmt_elf.c
|
|
|
|
*
|
|
|
|
* These are the functions used to load ELF format executables as used
|
|
|
|
* on SVr4 machines. Information on the format may be found in the book
|
|
|
|
* "UNIX SYSTEM V RELEASE 4 Programmers Guide: Ansi C and Programming Support
|
|
|
|
* Tools".
|
|
|
|
*
|
|
|
|
* Copyright 1993, 1994: Eric Youngdale (ericy@cais.com).
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/fs.h>
|
fs/binfmt_elf: use PT_LOAD p_align values for suitable start address
Patch series "Selecting Load Addresses According to p_align", v3.
The current ELF loading mechancism provides page-aligned mappings. This
can lead to the program being loaded in a way unsuitable for file-backed,
transparent huge pages when handling PIE executables.
While specifying -z,max-page-size=0x200000 to the linker will generate
suitably aligned segments for huge pages on x86_64, the executable needs
to be loaded at a suitably aligned address as well. This alignment
requires the binary's cooperation, as distinct segments need to be
appropriately paddded to be eligible for THP.
For binaries built with increased alignment, this limits the number of
bits usable for ASLR, but provides some randomization over using fixed
load addresses/non-PIE binaries.
This patch (of 2):
The current ELF loading mechancism provides page-aligned mappings. This
can lead to the program being loaded in a way unsuitable for file-backed,
transparent huge pages when handling PIE executables.
For binaries built with increased alignment, this limits the number of
bits usable for ASLR, but provides some randomization over using fixed
load addresses/non-PIE binaries.
Tested by verifying program with -Wl,-z,max-page-size=0x200000 loading.
[akpm@linux-foundation.org: fix max() warning]
[ckennelly@google.com: augment comment]
Link: https://lkml.kernel.org/r/20200821233848.3904680-2-ckennelly@google.com
Signed-off-by: Chris Kennelly <ckennelly@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Hugh Dickens <hughd@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Fangrui Song <maskray@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: https://lkml.kernel.org/r/20200820170541.1132271-1-ckennelly@google.com
Link: https://lkml.kernel.org/r/20200820170541.1132271-2-ckennelly@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:12:32 +00:00
|
|
|
#include <linux/log2.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/mman.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/signal.h>
|
|
|
|
#include <linux/binfmts.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/personality.h>
|
|
|
|
#include <linux/elfcore.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/highuid.h>
|
|
|
|
#include <linux/compiler.h>
|
|
|
|
#include <linux/highmem.h>
|
2020-04-07 03:03:51 +00:00
|
|
|
#include <linux/hugetlb.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/pagemap.h>
|
2012-10-05 00:15:36 +00:00
|
|
|
#include <linux/vmalloc.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/security.h>
|
|
|
|
#include <linux/random.h>
|
2006-06-23 09:05:35 +00:00
|
|
|
#include <linux/elf.h>
|
2015-04-14 22:48:07 +00:00
|
|
|
#include <linux/elf-randomize.h>
|
2007-05-08 07:28:59 +00:00
|
|
|
#include <linux/utsname.h>
|
2010-03-05 21:44:06 +00:00
|
|
|
#include <linux/coredump.h>
|
2012-11-13 13:20:55 +00:00
|
|
|
#include <linux/sched.h>
|
2017-02-08 17:51:30 +00:00
|
|
|
#include <linux/sched/coredump.h>
|
2017-02-08 17:51:37 +00:00
|
|
|
#include <linux/sched/task_stack.h>
|
2017-02-05 10:48:36 +00:00
|
|
|
#include <linux/sched/cputime.h>
|
2020-03-16 16:50:44 +00:00
|
|
|
#include <linux/sizes.h>
|
|
|
|
#include <linux/types.h>
|
2017-02-02 16:54:15 +00:00
|
|
|
#include <linux/cred.h>
|
2015-10-05 22:33:36 +00:00
|
|
|
#include <linux/dax.h>
|
2016-12-24 19:46:01 +00:00
|
|
|
#include <linux/uaccess.h>
|
2022-11-22 20:39:04 +00:00
|
|
|
#include <linux/rseq.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <asm/param.h>
|
|
|
|
#include <asm/page.h>
|
|
|
|
|
2020-03-16 16:50:44 +00:00
|
|
|
#ifndef ELF_COMPAT
|
|
|
|
#define ELF_COMPAT 0
|
|
|
|
#endif
|
|
|
|
|
2012-10-05 00:15:36 +00:00
|
|
|
#ifndef user_long_t
|
|
|
|
#define user_long_t long
|
|
|
|
#endif
|
2012-10-05 00:15:35 +00:00
|
|
|
#ifndef user_siginfo_t
|
|
|
|
#define user_siginfo_t siginfo_t
|
|
|
|
#endif
|
|
|
|
|
2017-08-16 20:05:13 +00:00
|
|
|
/* That's for binfmt_elf_fdpic to deal with */
|
|
|
|
#ifndef elf_check_fdpic
|
|
|
|
#define elf_check_fdpic(ex) false
|
|
|
|
#endif
|
|
|
|
|
2012-10-21 02:00:48 +00:00
|
|
|
static int load_elf_binary(struct linux_binprm *bprm);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-04-03 21:48:27 +00:00
|
|
|
#ifdef CONFIG_USELIB
|
|
|
|
static int load_elf_library(struct file *);
|
|
|
|
#else
|
|
|
|
#define load_elf_library NULL
|
|
|
|
#endif
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* If we don't support core dumping, then supply a NULL so we
|
|
|
|
* don't even try.
|
|
|
|
*/
|
2009-12-16 00:47:37 +00:00
|
|
|
#ifdef CONFIG_ELF_CORE
|
2009-12-17 23:27:16 +00:00
|
|
|
static int elf_core_dump(struct coredump_params *cprm);
|
2005-04-16 22:20:36 +00:00
|
|
|
#else
|
|
|
|
#define elf_core_dump NULL
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if ELF_EXEC_PAGESIZE > PAGE_SIZE
|
2006-06-23 09:05:35 +00:00
|
|
|
#define ELF_MIN_ALIGN ELF_EXEC_PAGESIZE
|
2005-04-16 22:20:36 +00:00
|
|
|
#else
|
2006-06-23 09:05:35 +00:00
|
|
|
#define ELF_MIN_ALIGN PAGE_SIZE
|
2005-04-16 22:20:36 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef ELF_CORE_EFLAGS
|
|
|
|
#define ELF_CORE_EFLAGS 0
|
|
|
|
#endif
|
|
|
|
|
2021-10-03 12:11:24 +00:00
|
|
|
#define ELF_PAGESTART(_v) ((_v) & ~(int)(ELF_MIN_ALIGN-1))
|
2005-04-16 22:20:36 +00:00
|
|
|
#define ELF_PAGEOFFSET(_v) ((_v) & (ELF_MIN_ALIGN-1))
|
|
|
|
#define ELF_PAGEALIGN(_v) (((_v) + ELF_MIN_ALIGN - 1) & ~(ELF_MIN_ALIGN - 1))
|
|
|
|
|
|
|
|
static struct linux_binfmt elf_format = {
|
2011-01-13 01:00:02 +00:00
|
|
|
.module = THIS_MODULE,
|
|
|
|
.load_binary = load_elf_binary,
|
|
|
|
.load_shlib = load_elf_library,
|
2022-02-13 19:25:20 +00:00
|
|
|
#ifdef CONFIG_COREDUMP
|
2011-01-13 01:00:02 +00:00
|
|
|
.core_dump = elf_core_dump,
|
|
|
|
.min_coredump = ELF_EXEC_PAGESIZE,
|
2022-02-13 19:25:20 +00:00
|
|
|
#endif
|
2005-04-16 22:20:36 +00:00
|
|
|
};
|
|
|
|
|
2020-01-31 06:17:01 +00:00
|
|
|
#define BAD_ADDR(x) (unlikely((unsigned long)(x) >= TASK_SIZE))
|
2005-04-16 22:20:36 +00:00
|
|
|
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
static int set_brk(unsigned long start, unsigned long end, int prot)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
start = ELF_PAGEALIGN(start);
|
|
|
|
end = ELF_PAGEALIGN(end);
|
|
|
|
if (end > start) {
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
/*
|
|
|
|
* Map the last of the bss segment.
|
|
|
|
* If the header is requesting these pages to be
|
|
|
|
* executable, honour that (ppc32 needs this).
|
|
|
|
*/
|
|
|
|
int error = vm_brk_flags(start, end - start,
|
|
|
|
prot & PROT_EXEC ? VM_EXEC : 0);
|
2016-05-27 22:57:31 +00:00
|
|
|
if (error)
|
|
|
|
return error;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
current->mm->start_brk = current->mm->brk = end;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We need to explicitly zero any fractional pages
|
|
|
|
after the data section (i.e. bss). This would
|
|
|
|
contain the junk from the file that should not
|
2006-06-23 09:05:35 +00:00
|
|
|
be in memory
|
|
|
|
*/
|
2005-04-16 22:20:36 +00:00
|
|
|
static int padzero(unsigned long elf_bss)
|
|
|
|
{
|
|
|
|
unsigned long nbyte;
|
|
|
|
|
|
|
|
nbyte = ELF_PAGEOFFSET(elf_bss);
|
|
|
|
if (nbyte) {
|
|
|
|
nbyte = ELF_MIN_ALIGN - nbyte;
|
|
|
|
if (clear_user((void __user *) elf_bss, nbyte))
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-02-03 16:05:15 +00:00
|
|
|
/* Let's use some macros to make this stack manipulation a little clearer */
|
2005-04-16 22:20:36 +00:00
|
|
|
#ifdef CONFIG_STACK_GROWSUP
|
|
|
|
#define STACK_ADD(sp, items) ((elf_addr_t __user *)(sp) + (items))
|
|
|
|
#define STACK_ROUND(sp, items) \
|
|
|
|
((15 + (unsigned long) ((sp) + (items))) &~ 15UL)
|
2006-06-23 09:05:35 +00:00
|
|
|
#define STACK_ALLOC(sp, len) ({ \
|
|
|
|
elf_addr_t __user *old_sp = (elf_addr_t __user *)sp; sp += len; \
|
|
|
|
old_sp; })
|
2005-04-16 22:20:36 +00:00
|
|
|
#else
|
|
|
|
#define STACK_ADD(sp, items) ((elf_addr_t __user *)(sp) - (items))
|
|
|
|
#define STACK_ROUND(sp, items) \
|
|
|
|
(((unsigned long) (sp - items)) &~ 15UL)
|
2021-11-09 02:33:40 +00:00
|
|
|
#define STACK_ALLOC(sp, len) (sp -= len)
|
2005-04-16 22:20:36 +00:00
|
|
|
#endif
|
|
|
|
|
ELF loader support for auxvec base platform string
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+". This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-07-21 18:48:46 +00:00
|
|
|
#ifndef ELF_BASE_PLATFORM
|
|
|
|
/*
|
|
|
|
* AT_BASE_PLATFORM indicates the "real" hardware/microarchitecture.
|
|
|
|
* If the arch defines ELF_BASE_PLATFORM (in asm/elf.h), the value
|
|
|
|
* will be copied to the user stack in the same manner as AT_PLATFORM.
|
|
|
|
*/
|
|
|
|
#define ELF_BASE_PLATFORM NULL
|
|
|
|
#endif
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
static int
|
2020-01-31 06:16:55 +00:00
|
|
|
create_elf_tables(struct linux_binprm *bprm, const struct elfhdr *exec,
|
2022-01-27 12:40:16 +00:00
|
|
|
unsigned long interp_load_addr,
|
|
|
|
unsigned long e_entry, unsigned long phdr_addr)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2020-01-31 06:16:58 +00:00
|
|
|
struct mm_struct *mm = current->mm;
|
2005-04-16 22:20:36 +00:00
|
|
|
unsigned long p = bprm->p;
|
|
|
|
int argc = bprm->argc;
|
|
|
|
int envc = bprm->envc;
|
|
|
|
elf_addr_t __user *sp;
|
|
|
|
elf_addr_t __user *u_platform;
|
ELF loader support for auxvec base platform string
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+". This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-07-21 18:48:46 +00:00
|
|
|
elf_addr_t __user *u_base_platform;
|
2009-01-08 02:08:52 +00:00
|
|
|
elf_addr_t __user *u_rand_bytes;
|
2005-04-16 22:20:36 +00:00
|
|
|
const char *k_platform = ELF_PLATFORM;
|
ELF loader support for auxvec base platform string
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+". This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-07-21 18:48:46 +00:00
|
|
|
const char *k_base_platform = ELF_BASE_PLATFORM;
|
2009-01-08 02:08:52 +00:00
|
|
|
unsigned char k_rand_bytes[16];
|
2005-04-16 22:20:36 +00:00
|
|
|
int items;
|
|
|
|
elf_addr_t *elf_info;
|
2020-01-28 13:25:39 +00:00
|
|
|
elf_addr_t flags = 0;
|
2020-01-31 06:16:50 +00:00
|
|
|
int ei_index;
|
2008-11-13 23:39:18 +00:00
|
|
|
const struct cred *cred = current_cred();
|
2007-07-19 08:48:16 +00:00
|
|
|
struct vm_area_struct *vma;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-10-17 06:30:24 +00:00
|
|
|
/*
|
|
|
|
* In some cases (e.g. Hyper-Threading), we want to avoid L1
|
|
|
|
* evictions by the processes running on the same package. One
|
|
|
|
* thing we can do is to shuffle the initial stack for them.
|
|
|
|
*/
|
|
|
|
|
|
|
|
p = arch_align_stack(p);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* If this architecture has a platform capability string, copy it
|
|
|
|
* to userspace. In some cases (Sparc), this info is impossible
|
|
|
|
* for userspace to get any other way, in others (i386) it is
|
|
|
|
* merely difficult.
|
|
|
|
*/
|
|
|
|
u_platform = NULL;
|
|
|
|
if (k_platform) {
|
|
|
|
size_t len = strlen(k_platform) + 1;
|
|
|
|
|
|
|
|
u_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
|
2020-02-19 14:23:34 +00:00
|
|
|
if (copy_to_user(u_platform, k_platform, len))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
ELF loader support for auxvec base platform string
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+". This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-07-21 18:48:46 +00:00
|
|
|
/*
|
|
|
|
* If this architecture has a "base" platform capability
|
|
|
|
* string, copy it to userspace.
|
|
|
|
*/
|
|
|
|
u_base_platform = NULL;
|
|
|
|
if (k_base_platform) {
|
|
|
|
size_t len = strlen(k_base_platform) + 1;
|
|
|
|
|
|
|
|
u_base_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
|
2020-02-19 14:23:34 +00:00
|
|
|
if (copy_to_user(u_base_platform, k_base_platform, len))
|
ELF loader support for auxvec base platform string
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+". This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-07-21 18:48:46 +00:00
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
2009-01-08 02:08:52 +00:00
|
|
|
/*
|
|
|
|
* Generate 16 random bytes for userspace PRNG seeding.
|
|
|
|
*/
|
|
|
|
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));
|
|
|
|
u_rand_bytes = (elf_addr_t __user *)
|
|
|
|
STACK_ALLOC(p, sizeof(k_rand_bytes));
|
2020-02-19 14:23:34 +00:00
|
|
|
if (copy_to_user(u_rand_bytes, k_rand_bytes, sizeof(k_rand_bytes)))
|
2009-01-08 02:08:52 +00:00
|
|
|
return -EFAULT;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Create the ELF interpreter info */
|
2020-01-31 06:16:58 +00:00
|
|
|
elf_info = (elf_addr_t *)mm->saved_auxv;
|
2007-10-17 06:30:12 +00:00
|
|
|
/* update AT_VECTOR_SIZE_BASE if the number of NEW_AUX_ENT() changes */
|
2005-04-16 22:20:36 +00:00
|
|
|
#define NEW_AUX_ENT(id, val) \
|
2006-06-23 09:05:35 +00:00
|
|
|
do { \
|
2020-01-31 06:16:50 +00:00
|
|
|
*elf_info++ = id; \
|
|
|
|
*elf_info++ = val; \
|
2006-06-23 09:05:35 +00:00
|
|
|
} while (0)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
#ifdef ARCH_DLINFO
|
2022-10-18 07:14:20 +00:00
|
|
|
/*
|
2005-04-16 22:20:36 +00:00
|
|
|
* ARCH_DLINFO must come first so PPC can do its special alignment of
|
|
|
|
* AUXV.
|
2007-10-17 06:30:12 +00:00
|
|
|
* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT() in
|
|
|
|
* ARCH_DLINFO changes
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
ARCH_DLINFO;
|
|
|
|
#endif
|
|
|
|
NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
|
|
|
|
NEW_AUX_ENT(AT_PAGESZ, ELF_EXEC_PAGESIZE);
|
|
|
|
NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
|
2022-01-27 12:40:16 +00:00
|
|
|
NEW_AUX_ENT(AT_PHDR, phdr_addr);
|
2006-06-23 09:05:35 +00:00
|
|
|
NEW_AUX_ENT(AT_PHENT, sizeof(struct elf_phdr));
|
2005-04-16 22:20:36 +00:00
|
|
|
NEW_AUX_ENT(AT_PHNUM, exec->e_phnum);
|
|
|
|
NEW_AUX_ENT(AT_BASE, interp_load_addr);
|
2020-01-28 13:25:39 +00:00
|
|
|
if (bprm->interp_flags & BINPRM_FLAGS_PRESERVE_ARGV0)
|
|
|
|
flags |= AT_FLAGS_PRESERVE_ARGV0;
|
|
|
|
NEW_AUX_ENT(AT_FLAGS, flags);
|
2020-01-31 06:16:55 +00:00
|
|
|
NEW_AUX_ENT(AT_ENTRY, e_entry);
|
2012-02-08 02:36:10 +00:00
|
|
|
NEW_AUX_ENT(AT_UID, from_kuid_munged(cred->user_ns, cred->uid));
|
|
|
|
NEW_AUX_ENT(AT_EUID, from_kuid_munged(cred->user_ns, cred->euid));
|
|
|
|
NEW_AUX_ENT(AT_GID, from_kgid_munged(cred->user_ns, cred->gid));
|
|
|
|
NEW_AUX_ENT(AT_EGID, from_kgid_munged(cred->user_ns, cred->egid));
|
binfmt: Introduce secureexec flag
The bprm_secureexec hook can be moved earlier. Right now, it is called
during create_elf_tables(), via load_binary(), via search_binary_handler(),
via exec_binprm(). Nearly all (see exception below) state used by
bprm_secureexec is created during the bprm_set_creds hook, called from
prepare_binprm().
For all LSMs (except commoncaps described next), only the first execution
of bprm_set_creds takes any effect (they all check bprm->called_set_creds
which prepare_binprm() sets after the first call to the bprm_set_creds
hook). However, all these LSMs also only do anything with bprm_secureexec
when they detected a secure state during their first run of bprm_set_creds.
Therefore, it is functionally identical to move the detection into
bprm_set_creds, since the results from secureexec here only need to be
based on the first call to the LSM's bprm_set_creds hook.
The single exception is that the commoncaps secureexec hook also examines
euid/uid and egid/gid differences which are controlled by bprm_fill_uid(),
via prepare_binprm(), which can be called multiple times (e.g.
binfmt_script, binfmt_misc), and may clear the euid/egid for the final
load (i.e. the script interpreter). However, while commoncaps specifically
ignores bprm->cred_prepared, and runs its bprm_set_creds hook each time
prepare_binprm() may get called, it needs to base the secureexec decision
on the final call to bprm_set_creds. As a result, it will need special
handling.
To begin this refactoring, this adds the secureexec flag to the bprm
struct, and calls the secureexec hook during setup_new_exec(). This is
safe since all the cred work is finished (and past the point of no return).
This explicit call will be removed in later patches once the hook has been
removed.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: John Johansen <john.johansen@canonical.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
2017-07-18 22:25:22 +00:00
|
|
|
NEW_AUX_ENT(AT_SECURE, bprm->secureexec);
|
2009-01-08 02:08:52 +00:00
|
|
|
NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
|
2013-04-17 17:33:11 +00:00
|
|
|
#ifdef ELF_HWCAP2
|
|
|
|
NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
|
|
|
|
#endif
|
execve filename: document and export via auxiliary vector
The Linux kernel puts the filename argument of execve() into the new
address space. Many developers are surprised to learn this. Those who
know and could use it, object "But it's not documented."
Those who want to use it dislike the expression
(char *)(1+ strlen(env[-1+ n_env]) + env[-1+ n_env])
because it requires locating the last original environment variable,
and assumes that the filename follows the characters.
This patch documents the insertion of the filename, and makes it easier
to find by adding a new tag AT_EXECFN in the ElfXX_auxv_t; see <elf.h>.
In many cases readlink("/proc/self/exe",) gives the same answer. But if
all the original pages get unmapped, then the kernel erases the symlink
for /proc/self/exe. This can happen when a program decompressor does a
good job of cleaning up after uncompressing directly to memory, so that
the address space of the target program looks the same as if compression
had never happened. One example is http://upx.sourceforge.net .
One notable use of the underlying concept (what path containED the
executable) is glibc expanding $ORIGIN in DT_RUNPATH. In practice for
the near term, it may be a good idea for user-mode code to use both
/proc/self/exe and AT_EXECFN as fall-back methods for each other.
/proc/self/exe can fail due to unmapping, AT_EXECFN can fail because it
won't be present on non-new systems. The auxvec or {AT_EXECFN}.d_val
also can get overwritten, although in nearly all cases this would be the
result of a bug.
The runtime cost is one NEW_AUX_ENT using two words of stack space. The
underlying value is maintained already as bprm->exec; setup_arg_pages()
in fs/exec.c slides it for stack_shift, etc.
Signed-off-by: John Reiser <jreiser@BitWagon.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Ulrich Drepper <drepper@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-21 21:21:32 +00:00
|
|
|
NEW_AUX_ENT(AT_EXECFN, bprm->exec);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (k_platform) {
|
2006-06-23 09:05:35 +00:00
|
|
|
NEW_AUX_ENT(AT_PLATFORM,
|
2006-06-23 09:05:35 +00:00
|
|
|
(elf_addr_t)(unsigned long)u_platform);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
ELF loader support for auxvec base platform string
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+". This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-07-21 18:48:46 +00:00
|
|
|
if (k_base_platform) {
|
|
|
|
NEW_AUX_ENT(AT_BASE_PLATFORM,
|
|
|
|
(elf_addr_t)(unsigned long)u_base_platform);
|
|
|
|
}
|
2020-05-14 20:17:40 +00:00
|
|
|
if (bprm->have_execfd) {
|
|
|
|
NEW_AUX_ENT(AT_EXECFD, bprm->execfd);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2022-11-22 20:39:04 +00:00
|
|
|
#ifdef CONFIG_RSEQ
|
|
|
|
NEW_AUX_ENT(AT_RSEQ_FEATURE_SIZE, offsetof(struct rseq, end));
|
|
|
|
NEW_AUX_ENT(AT_RSEQ_ALIGN, __alignof__(struct rseq));
|
|
|
|
#endif
|
2005-04-16 22:20:36 +00:00
|
|
|
#undef NEW_AUX_ENT
|
|
|
|
/* AT_NULL is zero; clear the rest too */
|
2020-01-31 06:16:58 +00:00
|
|
|
memset(elf_info, 0, (char *)mm->saved_auxv +
|
|
|
|
sizeof(mm->saved_auxv) - (char *)elf_info);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* And advance past the AT_NULL entry. */
|
2020-01-31 06:16:50 +00:00
|
|
|
elf_info += 2;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2020-01-31 06:16:58 +00:00
|
|
|
ei_index = elf_info - (elf_addr_t *)mm->saved_auxv;
|
2005-04-16 22:20:36 +00:00
|
|
|
sp = STACK_ADD(p, ei_index);
|
|
|
|
|
2008-02-08 12:21:54 +00:00
|
|
|
items = (argc + 1) + (envc + 1) + 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
bprm->p = STACK_ROUND(sp, items);
|
|
|
|
|
|
|
|
/* Point sp at the lowest address on the stack */
|
|
|
|
#ifdef CONFIG_STACK_GROWSUP
|
|
|
|
sp = (elf_addr_t __user *)bprm->p - items - ei_index;
|
2006-06-23 09:05:35 +00:00
|
|
|
bprm->exec = (unsigned long)sp; /* XXX: PARISC HACK */
|
2005-04-16 22:20:36 +00:00
|
|
|
#else
|
|
|
|
sp = (elf_addr_t __user *)bprm->p;
|
|
|
|
#endif
|
|
|
|
|
2007-07-19 08:48:16 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Grow the stack manually; some architectures have a limit on how
|
|
|
|
* far ahead a user-space access may be in order to grow the stack.
|
|
|
|
*/
|
2020-10-17 23:14:15 +00:00
|
|
|
if (mmap_read_lock_killable(mm))
|
|
|
|
return -EINTR;
|
2020-01-31 06:16:58 +00:00
|
|
|
vma = find_extend_vma(mm, bprm->p);
|
2020-10-17 23:14:15 +00:00
|
|
|
mmap_read_unlock(mm);
|
2007-07-19 08:48:16 +00:00
|
|
|
if (!vma)
|
|
|
|
return -EFAULT;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Now, let's put argc (and argv, envp if appropriate) on the stack */
|
2020-02-19 14:23:34 +00:00
|
|
|
if (put_user(argc, sp++))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EFAULT;
|
|
|
|
|
2017-07-10 22:52:54 +00:00
|
|
|
/* Populate list of argv pointers back to argv strings. */
|
2020-01-31 06:16:58 +00:00
|
|
|
p = mm->arg_end = mm->arg_start;
|
2005-04-16 22:20:36 +00:00
|
|
|
while (argc-- > 0) {
|
|
|
|
size_t len;
|
2020-02-19 14:23:34 +00:00
|
|
|
if (put_user((elf_addr_t)p, sp++))
|
2006-12-07 04:36:35 +00:00
|
|
|
return -EFAULT;
|
2007-07-19 08:48:16 +00:00
|
|
|
len = strnlen_user((void __user *)p, MAX_ARG_STRLEN);
|
|
|
|
if (!len || len > MAX_ARG_STRLEN)
|
2008-05-08 13:52:33 +00:00
|
|
|
return -EINVAL;
|
2005-04-16 22:20:36 +00:00
|
|
|
p += len;
|
|
|
|
}
|
2020-02-19 14:23:34 +00:00
|
|
|
if (put_user(0, sp++))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EFAULT;
|
2020-01-31 06:16:58 +00:00
|
|
|
mm->arg_end = p;
|
2017-07-10 22:52:54 +00:00
|
|
|
|
|
|
|
/* Populate list of envp pointers back to envp strings. */
|
2020-01-31 06:16:58 +00:00
|
|
|
mm->env_end = mm->env_start = p;
|
2005-04-16 22:20:36 +00:00
|
|
|
while (envc-- > 0) {
|
|
|
|
size_t len;
|
2020-02-19 14:23:34 +00:00
|
|
|
if (put_user((elf_addr_t)p, sp++))
|
2006-12-07 04:36:35 +00:00
|
|
|
return -EFAULT;
|
2007-07-19 08:48:16 +00:00
|
|
|
len = strnlen_user((void __user *)p, MAX_ARG_STRLEN);
|
|
|
|
if (!len || len > MAX_ARG_STRLEN)
|
2008-05-08 13:52:33 +00:00
|
|
|
return -EINVAL;
|
2005-04-16 22:20:36 +00:00
|
|
|
p += len;
|
|
|
|
}
|
2020-02-19 14:23:34 +00:00
|
|
|
if (put_user(0, sp++))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EFAULT;
|
2020-01-31 06:16:58 +00:00
|
|
|
mm->env_end = p;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Put the elf_info on the stack in the right place. */
|
2020-01-31 06:16:58 +00:00
|
|
|
if (copy_to_user(sp, mm->saved_auxv, ei_index * sizeof(elf_addr_t)))
|
2005-04-16 22:20:36 +00:00
|
|
|
return -EFAULT;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long elf_map(struct file *filep, unsigned long addr,
|
2019-03-08 00:29:03 +00:00
|
|
|
const struct elf_phdr *eppnt, int prot, int type,
|
2008-01-30 12:31:07 +00:00
|
|
|
unsigned long total_size)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
unsigned long map_addr;
|
2008-01-30 12:31:07 +00:00
|
|
|
unsigned long size = eppnt->p_filesz + ELF_PAGEOFFSET(eppnt->p_vaddr);
|
|
|
|
unsigned long off = eppnt->p_offset - ELF_PAGEOFFSET(eppnt->p_vaddr);
|
|
|
|
addr = ELF_PAGESTART(addr);
|
|
|
|
size = ELF_PAGEALIGN(size);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-01-08 09:03:35 +00:00
|
|
|
/* mmap() will return -EINVAL if given a zero size, but a
|
|
|
|
* segment with zero filesize is perfectly valid */
|
2008-01-30 12:31:07 +00:00
|
|
|
if (!size)
|
|
|
|
return addr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* total_size is the size of the ELF (interpreter) image.
|
|
|
|
* The _first_ mmap needs to know the full size, otherwise
|
|
|
|
* randomization might put this image into an overlapping
|
|
|
|
* position with the ELF binary image. (since size < total_size)
|
|
|
|
* So we first map the 'big' image - and unmap the remainder at
|
|
|
|
* the end. (which unmap is needed for ELF images with holes.)
|
|
|
|
*/
|
|
|
|
if (total_size) {
|
|
|
|
total_size = ELF_PAGEALIGN(total_size);
|
2012-05-30 05:49:38 +00:00
|
|
|
map_addr = vm_mmap(filep, addr, total_size, prot, type, off);
|
2008-01-30 12:31:07 +00:00
|
|
|
if (!BAD_ADDR(map_addr))
|
2012-05-30 05:49:38 +00:00
|
|
|
vm_munmap(map_addr+size, total_size-size);
|
2008-01-30 12:31:07 +00:00
|
|
|
} else
|
2012-05-30 05:49:38 +00:00
|
|
|
map_addr = vm_mmap(filep, addr, size, prot, type, off);
|
2008-01-30 12:31:07 +00:00
|
|
|
|
2018-04-20 21:56:13 +00:00
|
|
|
if ((type & MAP_FIXED_NOREPLACE) &&
|
|
|
|
PTR_ERR((void *)map_addr) == -EEXIST)
|
|
|
|
pr_info("%d (%s): Uhuuh, elf segment at %px requested but the memory is mapped already\n",
|
|
|
|
task_pid_nr(current), current->comm, (void *)addr);
|
2018-04-10 23:36:01 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return(map_addr);
|
|
|
|
}
|
|
|
|
|
2021-10-03 12:11:24 +00:00
|
|
|
static unsigned long total_mapping_size(const struct elf_phdr *phdr, int nr)
|
2008-01-30 12:31:07 +00:00
|
|
|
{
|
2021-10-03 12:11:24 +00:00
|
|
|
elf_addr_t min_addr = -1;
|
|
|
|
elf_addr_t max_addr = 0;
|
|
|
|
bool pt_load = false;
|
|
|
|
int i;
|
2008-01-30 12:31:07 +00:00
|
|
|
|
|
|
|
for (i = 0; i < nr; i++) {
|
2021-10-03 12:11:24 +00:00
|
|
|
if (phdr[i].p_type == PT_LOAD) {
|
|
|
|
min_addr = min(min_addr, ELF_PAGESTART(phdr[i].p_vaddr));
|
|
|
|
max_addr = max(max_addr, phdr[i].p_vaddr + phdr[i].p_memsz);
|
|
|
|
pt_load = true;
|
2008-01-30 12:31:07 +00:00
|
|
|
}
|
|
|
|
}
|
2021-10-03 12:11:24 +00:00
|
|
|
return pt_load ? (max_addr - min_addr) : 0;
|
2008-01-30 12:31:07 +00:00
|
|
|
}
|
|
|
|
|
2019-12-05 00:52:25 +00:00
|
|
|
static int elf_read(struct file *file, void *buf, size_t len, loff_t pos)
|
|
|
|
{
|
|
|
|
ssize_t rv;
|
|
|
|
|
|
|
|
rv = kernel_read(file, buf, len, &pos);
|
|
|
|
if (unlikely(rv != len)) {
|
|
|
|
return (rv < 0) ? rv : -EIO;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
fs/binfmt_elf: use PT_LOAD p_align values for suitable start address
Patch series "Selecting Load Addresses According to p_align", v3.
The current ELF loading mechancism provides page-aligned mappings. This
can lead to the program being loaded in a way unsuitable for file-backed,
transparent huge pages when handling PIE executables.
While specifying -z,max-page-size=0x200000 to the linker will generate
suitably aligned segments for huge pages on x86_64, the executable needs
to be loaded at a suitably aligned address as well. This alignment
requires the binary's cooperation, as distinct segments need to be
appropriately paddded to be eligible for THP.
For binaries built with increased alignment, this limits the number of
bits usable for ASLR, but provides some randomization over using fixed
load addresses/non-PIE binaries.
This patch (of 2):
The current ELF loading mechancism provides page-aligned mappings. This
can lead to the program being loaded in a way unsuitable for file-backed,
transparent huge pages when handling PIE executables.
For binaries built with increased alignment, this limits the number of
bits usable for ASLR, but provides some randomization over using fixed
load addresses/non-PIE binaries.
Tested by verifying program with -Wl,-z,max-page-size=0x200000 loading.
[akpm@linux-foundation.org: fix max() warning]
[ckennelly@google.com: augment comment]
Link: https://lkml.kernel.org/r/20200821233848.3904680-2-ckennelly@google.com
Signed-off-by: Chris Kennelly <ckennelly@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Hugh Dickens <hughd@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Fangrui Song <maskray@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: https://lkml.kernel.org/r/20200820170541.1132271-1-ckennelly@google.com
Link: https://lkml.kernel.org/r/20200820170541.1132271-2-ckennelly@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:12:32 +00:00
|
|
|
static unsigned long maximum_alignment(struct elf_phdr *cmds, int nr)
|
|
|
|
{
|
|
|
|
unsigned long alignment = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < nr; i++) {
|
|
|
|
if (cmds[i].p_type == PT_LOAD) {
|
|
|
|
unsigned long p_align = cmds[i].p_align;
|
|
|
|
|
|
|
|
/* skip non-power of two alignments as invalid */
|
|
|
|
if (!is_power_of_2(p_align))
|
|
|
|
continue;
|
|
|
|
alignment = max(alignment, p_align);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ensure we align to at least one page */
|
|
|
|
return ELF_PAGEALIGN(alignment);
|
|
|
|
}
|
|
|
|
|
2014-09-11 07:30:14 +00:00
|
|
|
/**
|
|
|
|
* load_elf_phdrs() - load ELF program headers
|
|
|
|
* @elf_ex: ELF header of the binary whose program headers should be loaded
|
|
|
|
* @elf_file: the opened ELF binary file
|
|
|
|
*
|
|
|
|
* Loads ELF program headers from the binary file elf_file, which has the ELF
|
|
|
|
* header pointed to by elf_ex, into a newly allocated array. The caller is
|
2022-10-19 07:43:01 +00:00
|
|
|
* responsible for freeing the allocated data. Returns NULL upon failure.
|
2014-09-11 07:30:14 +00:00
|
|
|
*/
|
2019-03-08 00:29:03 +00:00
|
|
|
static struct elf_phdr *load_elf_phdrs(const struct elfhdr *elf_ex,
|
2014-09-11 07:30:14 +00:00
|
|
|
struct file *elf_file)
|
|
|
|
{
|
|
|
|
struct elf_phdr *elf_phdata = NULL;
|
2022-10-19 07:52:16 +00:00
|
|
|
int retval = -1;
|
2019-03-08 00:28:56 +00:00
|
|
|
unsigned int size;
|
2014-09-11 07:30:14 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the size of this structure has changed, then punt, since
|
|
|
|
* we will be doing the wrong thing.
|
|
|
|
*/
|
|
|
|
if (elf_ex->e_phentsize != sizeof(struct elf_phdr))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* Sanity check the number of program headers... */
|
|
|
|
/* ...and their total size. */
|
|
|
|
size = sizeof(struct elf_phdr) * elf_ex->e_phnum;
|
2019-03-08 00:28:56 +00:00
|
|
|
if (size == 0 || size > 65536 || size > ELF_MIN_ALIGN)
|
2014-09-11 07:30:14 +00:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
elf_phdata = kmalloc(size, GFP_KERNEL);
|
|
|
|
if (!elf_phdata)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* Read in the program headers */
|
2019-12-05 00:52:25 +00:00
|
|
|
retval = elf_read(elf_file, elf_phdata, size, elf_ex->e_phoff);
|
2014-09-11 07:30:14 +00:00
|
|
|
|
|
|
|
out:
|
2022-10-19 07:52:16 +00:00
|
|
|
if (retval) {
|
2014-09-11 07:30:14 +00:00
|
|
|
kfree(elf_phdata);
|
|
|
|
elf_phdata = NULL;
|
|
|
|
}
|
|
|
|
return elf_phdata;
|
|
|
|
}
|
2008-01-30 12:31:07 +00:00
|
|
|
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
#ifndef CONFIG_ARCH_BINFMT_ELF_STATE
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct arch_elf_state - arch-specific ELF loading state
|
|
|
|
*
|
|
|
|
* This structure is used to preserve architecture specific data during
|
|
|
|
* the loading of an ELF file, throughout the checking of architecture
|
|
|
|
* specific ELF headers & through to the point where the ELF load is
|
|
|
|
* known to be proceeding (ie. SET_PERSONALITY).
|
|
|
|
*
|
|
|
|
* This implementation is a dummy for architectures which require no
|
|
|
|
* specific state.
|
|
|
|
*/
|
|
|
|
struct arch_elf_state {
|
|
|
|
};
|
|
|
|
|
|
|
|
#define INIT_ARCH_ELF_STATE {}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* arch_elf_pt_proc() - check a PT_LOPROC..PT_HIPROC ELF program header
|
|
|
|
* @ehdr: The main ELF header
|
|
|
|
* @phdr: The program header to check
|
|
|
|
* @elf: The open ELF file
|
|
|
|
* @is_interp: True if the phdr is from the interpreter of the ELF being
|
|
|
|
* loaded, else false.
|
|
|
|
* @state: Architecture-specific state preserved throughout the process
|
|
|
|
* of loading the ELF.
|
|
|
|
*
|
|
|
|
* Inspects the program header phdr to validate its correctness and/or
|
|
|
|
* suitability for the system. Called once per ELF program header in the
|
|
|
|
* range PT_LOPROC to PT_HIPROC, for both the ELF being loaded and its
|
|
|
|
* interpreter.
|
|
|
|
*
|
|
|
|
* Return: Zero to proceed with the ELF load, non-zero to fail the ELF load
|
|
|
|
* with that return code.
|
|
|
|
*/
|
|
|
|
static inline int arch_elf_pt_proc(struct elfhdr *ehdr,
|
|
|
|
struct elf_phdr *phdr,
|
|
|
|
struct file *elf, bool is_interp,
|
|
|
|
struct arch_elf_state *state)
|
|
|
|
{
|
|
|
|
/* Dummy implementation, always proceed */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2015-10-26 15:47:57 +00:00
|
|
|
* arch_check_elf() - check an ELF executable
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
* @ehdr: The main ELF header
|
|
|
|
* @has_interp: True if the ELF has an interpreter, else false.
|
2015-11-13 00:47:48 +00:00
|
|
|
* @interp_ehdr: The interpreter's ELF header
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
* @state: Architecture-specific state preserved throughout the process
|
|
|
|
* of loading the ELF.
|
|
|
|
*
|
|
|
|
* Provides a final opportunity for architecture code to reject the loading
|
|
|
|
* of the ELF & cause an exec syscall to return an error. This is called after
|
|
|
|
* all program headers to be checked by arch_elf_pt_proc have been.
|
|
|
|
*
|
|
|
|
* Return: Zero to proceed with the ELF load, non-zero to fail the ELF load
|
|
|
|
* with that return code.
|
|
|
|
*/
|
|
|
|
static inline int arch_check_elf(struct elfhdr *ehdr, bool has_interp,
|
2015-11-13 00:47:48 +00:00
|
|
|
struct elfhdr *interp_ehdr,
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
struct arch_elf_state *state)
|
|
|
|
{
|
|
|
|
/* Dummy implementation, always proceed */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* !CONFIG_ARCH_BINFMT_ELF_STATE */
|
2008-01-30 12:31:07 +00:00
|
|
|
|
2020-03-16 16:50:46 +00:00
|
|
|
static inline int make_prot(u32 p_flags, struct arch_elf_state *arch_state,
|
|
|
|
bool has_interp, bool is_interp)
|
2019-05-14 22:43:51 +00:00
|
|
|
{
|
|
|
|
int prot = 0;
|
|
|
|
|
|
|
|
if (p_flags & PF_R)
|
|
|
|
prot |= PROT_READ;
|
|
|
|
if (p_flags & PF_W)
|
|
|
|
prot |= PROT_WRITE;
|
|
|
|
if (p_flags & PF_X)
|
|
|
|
prot |= PROT_EXEC;
|
2020-03-16 16:50:46 +00:00
|
|
|
|
|
|
|
return arch_elf_adjust_prot(prot, arch_state, has_interp, is_interp);
|
2019-05-14 22:43:51 +00:00
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* This is much more generalized than the library routine read function,
|
|
|
|
so we keep this separate. Technically the library read function
|
|
|
|
is only provided so that we can read a.out libraries that have
|
|
|
|
an ELF header */
|
|
|
|
|
2006-06-23 09:05:35 +00:00
|
|
|
static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex,
|
2019-12-05 00:52:22 +00:00
|
|
|
struct file *interpreter,
|
2020-03-16 16:50:46 +00:00
|
|
|
unsigned long no_base, struct elf_phdr *interp_elf_phdata,
|
|
|
|
struct arch_elf_state *arch_state)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct elf_phdr *eppnt;
|
|
|
|
unsigned long load_addr = 0;
|
|
|
|
int load_addr_set = 0;
|
|
|
|
unsigned long last_bss = 0, elf_bss = 0;
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
int bss_prot = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
unsigned long error = ~0UL;
|
2008-01-30 12:31:07 +00:00
|
|
|
unsigned long total_size;
|
2014-09-11 07:30:14 +00:00
|
|
|
int i;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* First of all, some simple consistency checks */
|
|
|
|
if (interp_elf_ex->e_type != ET_EXEC &&
|
|
|
|
interp_elf_ex->e_type != ET_DYN)
|
|
|
|
goto out;
|
2017-08-16 20:05:13 +00:00
|
|
|
if (!elf_check_arch(interp_elf_ex) ||
|
|
|
|
elf_check_fdpic(interp_elf_ex))
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out;
|
2013-09-22 20:27:52 +00:00
|
|
|
if (!interpreter->f_op->mmap)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out;
|
|
|
|
|
2014-09-11 07:30:15 +00:00
|
|
|
total_size = total_mapping_size(interp_elf_phdata,
|
|
|
|
interp_elf_ex->e_phnum);
|
2008-01-30 12:31:07 +00:00
|
|
|
if (!total_size) {
|
|
|
|
error = -EINVAL;
|
2014-09-11 07:30:15 +00:00
|
|
|
goto out;
|
2008-01-30 12:31:07 +00:00
|
|
|
}
|
|
|
|
|
2014-09-11 07:30:15 +00:00
|
|
|
eppnt = interp_elf_phdata;
|
2006-06-23 09:05:35 +00:00
|
|
|
for (i = 0; i < interp_elf_ex->e_phnum; i++, eppnt++) {
|
|
|
|
if (eppnt->p_type == PT_LOAD) {
|
binfmt: remove in-tree usage of MAP_DENYWRITE
At exec time when we mmap the new executable via MAP_DENYWRITE we have it
opened via do_open_execat() and already deny_write_access()'ed the file
successfully. Once exec completes, we allow_write_acces(); however,
we set mm->exe_file in begin_new_exec() via set_mm_exe_file() and
also deny_write_access() as long as mm->exe_file remains set. We'll
effectively deny write access to our executable via mm->exe_file
until mm->exe_file is changed -- when the process is removed, on new
exec, or via sys_prctl(PR_SET_MM_MAP/EXE_FILE).
Let's remove all usage of MAP_DENYWRITE, it's no longer necessary for
mm->exe_file.
In case of an elf interpreter, we'll now only deny write access to the file
during exec. This is somewhat okay, because the interpreter behaves
(and sometime is) a shared library; all shared libraries, especially the
ones loaded directly in user space like via dlopen() won't ever be mapped
via MAP_DENYWRITE, because we ignore that from user space completely;
these shared libraries can always be modified while mapped and executed.
Let's only special-case the main executable, denying write access while
being executed by a process. This can be considered a minor user space
visible change.
While this is a cleanup, it also fixes part of a problem reported with
VM_DENYWRITE on overlayfs, as VM_DENYWRITE is effectively unused with
this patch and will be removed next:
"Overlayfs did not honor positive i_writecount on realfile for
VM_DENYWRITE mappings." [1]
[1] https://lore.kernel.org/r/YNHXzBgzRrZu1MrD@miu.piliscsaba.redhat.com/
Reported-by: Chengguang Xu <cgxu519@mykernel.net>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2021-04-23 07:42:41 +00:00
|
|
|
int elf_type = MAP_PRIVATE;
|
2020-03-16 16:50:46 +00:00
|
|
|
int elf_prot = make_prot(eppnt->p_flags, arch_state,
|
|
|
|
true, true);
|
2006-06-23 09:05:35 +00:00
|
|
|
unsigned long vaddr = 0;
|
|
|
|
unsigned long k, map_addr;
|
|
|
|
|
|
|
|
vaddr = eppnt->p_vaddr;
|
|
|
|
if (interp_elf_ex->e_type == ET_EXEC || load_addr_set)
|
2021-09-28 12:56:57 +00:00
|
|
|
elf_type |= MAP_FIXED;
|
2008-01-30 12:31:07 +00:00
|
|
|
else if (no_base && interp_elf_ex->e_type == ET_DYN)
|
|
|
|
load_addr = -vaddr;
|
2006-06-23 09:05:35 +00:00
|
|
|
|
|
|
|
map_addr = elf_map(interpreter, load_addr + vaddr,
|
x86: PIE executable randomization, checkpatch fixes
#39: FILE: arch/ia64/ia32/binfmt_elf32.c:229:
+elf32_map (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int prot, int type, unsigned long unused)
WARNING: no space between function name and open parenthesis '('
#39: FILE: arch/ia64/ia32/binfmt_elf32.c:229:
+elf32_map (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int prot, int type, unsigned long unused)
WARNING: line over 80 characters
#67: FILE: arch/x86/kernel/sys_x86_64.c:80:
+ new_begin = randomize_range(*begin, *begin + 0x02000000, 0);
ERROR: use tabs not spaces
#110: FILE: arch/x86/kernel/sys_x86_64.c:185:
+ ^I mm->cached_hole_size = 0;$
ERROR: use tabs not spaces
#111: FILE: arch/x86/kernel/sys_x86_64.c:186:
+ ^I^Imm->free_area_cache = mm->mmap_base;$
ERROR: use tabs not spaces
#112: FILE: arch/x86/kernel/sys_x86_64.c:187:
+ ^I}$
ERROR: use tabs not spaces
#141: FILE: arch/x86/kernel/sys_x86_64.c:216:
+ ^I^I/* remember the largest hole we saw so far */$
ERROR: use tabs not spaces
#142: FILE: arch/x86/kernel/sys_x86_64.c:217:
+ ^I^Iif (addr + mm->cached_hole_size < vma->vm_start)$
ERROR: use tabs not spaces
#143: FILE: arch/x86/kernel/sys_x86_64.c:218:
+ ^I^I mm->cached_hole_size = vma->vm_start - addr;$
ERROR: use tabs not spaces
#157: FILE: arch/x86/kernel/sys_x86_64.c:232:
+ ^Imm->free_area_cache = TASK_UNMAPPED_BASE;$
ERROR: need a space before the open parenthesis '('
#291: FILE: arch/x86/mm/mmap_64.c:101:
+ } else if(mmap_is_legacy()) {
WARNING: braces {} are not necessary for single statement blocks
#302: FILE: arch/x86/mm/mmap_64.c:112:
+ if (current->flags & PF_RANDOMIZE) {
+ mm->mmap_base += ((long)rnd) << PAGE_SHIFT;
+ }
WARNING: line over 80 characters
#314: FILE: fs/binfmt_elf.c:48:
+static unsigned long elf_map (struct file *, unsigned long, struct elf_phdr *, int, int, unsigned long);
WARNING: no space between function name and open parenthesis '('
#314: FILE: fs/binfmt_elf.c:48:
+static unsigned long elf_map (struct file *, unsigned long, struct elf_phdr *, int, int, unsigned long);
WARNING: line over 80 characters
#429: FILE: fs/binfmt_elf.c:438:
+ eppnt, elf_prot, elf_type, total_size);
ERROR: need space after that ',' (ctx:VxV)
#480: FILE: fs/binfmt_elf.c:939:
+ elf_prot, elf_flags,0);
^
total: 9 errors, 7 warnings, 461 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 12:31:07 +00:00
|
|
|
eppnt, elf_prot, elf_type, total_size);
|
2008-01-30 12:31:07 +00:00
|
|
|
total_size = 0;
|
2006-06-23 09:05:35 +00:00
|
|
|
error = map_addr;
|
|
|
|
if (BAD_ADDR(map_addr))
|
2014-09-11 07:30:15 +00:00
|
|
|
goto out;
|
2006-06-23 09:05:35 +00:00
|
|
|
|
|
|
|
if (!load_addr_set &&
|
|
|
|
interp_elf_ex->e_type == ET_DYN) {
|
|
|
|
load_addr = map_addr - ELF_PAGESTART(vaddr);
|
|
|
|
load_addr_set = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to see if the section's size will overflow the
|
|
|
|
* allowed task size. Note that p_filesz must always be
|
|
|
|
* <= p_memsize so it's only necessary to check p_memsz.
|
|
|
|
*/
|
|
|
|
k = load_addr + eppnt->p_vaddr;
|
[PATCH] binfmt_elf: fix checks for bad address
Fix check for bad address; use macro instead of open-coding two checks.
Taken from RHEL4 kernel update.
From: Ernie Petrides <petrides@redhat.com>
For background, the BAD_ADDR() macro should return TRUE if the address is
TASK_SIZE, because that's the lowest address that is *not* valid for
user-space mappings. The macro was correct in binfmt_aout.c but was wrong
for the "equal to" case in binfmt_elf.c. There were two in-line validations
of user-space addresses in binfmt_elf.c, which have been appropriately
converted to use the corrected BAD_ADDR() macro in the patch you posted
yesterday. Note that the size checks against TASK_SIZE are okay as coded.
The additional changes that I propose are below. These are in the error
paths for bad ELF entry addresses once load_elf_binary() has already
committed to exec'ing the new image (following the tearing down of the
task's original address space).
The 1st hunk deals with the interp-side of the outer "if". There were two
problems here. The printk() should be removed because this path can be
triggered at will by a bogus interpreter image created and used by a
malicious user. Further, the error code should not be ENOEXEC, because that
causes the loop in search_binary_handler() to continue trying other exec
handlers (twice, in fact). But it's too late for this to work correctly,
because the user address space has already been torn down, and an exec()
failure cannot be returned to the user code because the code no longer
exists. The only recovery is to force a SIGSEGV, but it's best to terminate
the search loop immediately. I somewhat arbitrarily chose EINVAL as a
fallback error code, but any error returned by load_elf_interp() will
override that (but this value will never be seen by user-space).
The 2nd hunk deals with the non-interp-side of the outer "if". There were
two problems here as well. The SIGSEGV needs to be forced, because a prior
sigaction() syscall might have set the associated disposition to SIG_IGN.
And the ENOEXEC should be changed to EINVAL as described above.
Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Ernie Petrides <petrides@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-03 07:24:14 +00:00
|
|
|
if (BAD_ADDR(k) ||
|
2006-06-23 09:05:35 +00:00
|
|
|
eppnt->p_filesz > eppnt->p_memsz ||
|
|
|
|
eppnt->p_memsz > TASK_SIZE ||
|
|
|
|
TASK_SIZE - eppnt->p_memsz < k) {
|
|
|
|
error = -ENOMEM;
|
2014-09-11 07:30:15 +00:00
|
|
|
goto out;
|
2006-06-23 09:05:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the end of the file mapping for this phdr, and
|
|
|
|
* keep track of the largest address we see for this.
|
|
|
|
*/
|
|
|
|
k = load_addr + eppnt->p_vaddr + eppnt->p_filesz;
|
|
|
|
if (k > elf_bss)
|
|
|
|
elf_bss = k;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do the same thing for the memory mapping - between
|
|
|
|
* elf_bss and last_bss is the bss section.
|
|
|
|
*/
|
binfmt_elf: fix calculations for bss padding
A double-bug exists in the bss calculation code, where an overflow can
happen in the "last_bss - elf_bss" calculation, but vm_brk internally
aligns the argument, underflowing it, wrapping back around safe. We
shouldn't depend on these bugs staying in sync, so this cleans up the
bss padding handling to avoid the overflow.
This moves the bss padzero() before the last_bss > elf_bss case, since
the zero-filling of the ELF_PAGE should have nothing to do with the
relationship of last_bss and elf_bss: any trailing portion should be
zeroed, and a zero size is already handled by padzero().
Then it handles the math on elf_bss vs last_bss correctly. These need
to both be ELF_PAGE aligned to get the comparison correct, since that's
the expected granularity of the mappings. Since elf_bss already had
alignment-based padding happen in padzero(), the "start" of the new
vm_brk() should be moved forward as done in the original code. However,
since the "end" of the vm_brk() area will already become PAGE_ALIGNed in
vm_brk() then last_bss should get aligned here to avoid hiding it as a
side-effect.
Additionally makes a cosmetic change to the initial last_bss calculation
so it's easier to read in comparison to the load_addr calculation above
it (i.e. the only difference is p_filesz vs p_memsz).
Link: http://lkml.kernel.org/r/1468014494-25291-2-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Ismael Ripoll Ripoll <iripoll@upv.es>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Chen Gang <gang.chen.5i5j@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-02 21:04:51 +00:00
|
|
|
k = load_addr + eppnt->p_vaddr + eppnt->p_memsz;
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
if (k > last_bss) {
|
2006-06-23 09:05:35 +00:00
|
|
|
last_bss = k;
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
bss_prot = elf_prot;
|
|
|
|
}
|
2006-06-23 09:05:35 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
binfmt_elf: fix calculations for bss padding
A double-bug exists in the bss calculation code, where an overflow can
happen in the "last_bss - elf_bss" calculation, but vm_brk internally
aligns the argument, underflowing it, wrapping back around safe. We
shouldn't depend on these bugs staying in sync, so this cleans up the
bss padding handling to avoid the overflow.
This moves the bss padzero() before the last_bss > elf_bss case, since
the zero-filling of the ELF_PAGE should have nothing to do with the
relationship of last_bss and elf_bss: any trailing portion should be
zeroed, and a zero size is already handled by padzero().
Then it handles the math on elf_bss vs last_bss correctly. These need
to both be ELF_PAGE aligned to get the comparison correct, since that's
the expected granularity of the mappings. Since elf_bss already had
alignment-based padding happen in padzero(), the "start" of the new
vm_brk() should be moved forward as done in the original code. However,
since the "end" of the vm_brk() area will already become PAGE_ALIGNed in
vm_brk() then last_bss should get aligned here to avoid hiding it as a
side-effect.
Additionally makes a cosmetic change to the initial last_bss calculation
so it's easier to read in comparison to the load_addr calculation above
it (i.e. the only difference is p_filesz vs p_memsz).
Link: http://lkml.kernel.org/r/1468014494-25291-2-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Ismael Ripoll Ripoll <iripoll@upv.es>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Chen Gang <gang.chen.5i5j@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-02 21:04:51 +00:00
|
|
|
/*
|
|
|
|
* Now fill out the bss section: first pad the last page from
|
|
|
|
* the file up to the page boundary, and zero it from elf_bss
|
|
|
|
* up to the end of the page.
|
|
|
|
*/
|
|
|
|
if (padzero(elf_bss)) {
|
|
|
|
error = -EFAULT;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Next, align both the file and mem bss up to the page size,
|
|
|
|
* since this is where elf_bss was just zeroed up to, and where
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
* last_bss will end after the vm_brk_flags() below.
|
binfmt_elf: fix calculations for bss padding
A double-bug exists in the bss calculation code, where an overflow can
happen in the "last_bss - elf_bss" calculation, but vm_brk internally
aligns the argument, underflowing it, wrapping back around safe. We
shouldn't depend on these bugs staying in sync, so this cleans up the
bss padding handling to avoid the overflow.
This moves the bss padzero() before the last_bss > elf_bss case, since
the zero-filling of the ELF_PAGE should have nothing to do with the
relationship of last_bss and elf_bss: any trailing portion should be
zeroed, and a zero size is already handled by padzero().
Then it handles the math on elf_bss vs last_bss correctly. These need
to both be ELF_PAGE aligned to get the comparison correct, since that's
the expected granularity of the mappings. Since elf_bss already had
alignment-based padding happen in padzero(), the "start" of the new
vm_brk() should be moved forward as done in the original code. However,
since the "end" of the vm_brk() area will already become PAGE_ALIGNed in
vm_brk() then last_bss should get aligned here to avoid hiding it as a
side-effect.
Additionally makes a cosmetic change to the initial last_bss calculation
so it's easier to read in comparison to the load_addr calculation above
it (i.e. the only difference is p_filesz vs p_memsz).
Link: http://lkml.kernel.org/r/1468014494-25291-2-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Ismael Ripoll Ripoll <iripoll@upv.es>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Chen Gang <gang.chen.5i5j@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-02 21:04:51 +00:00
|
|
|
*/
|
|
|
|
elf_bss = ELF_PAGEALIGN(elf_bss);
|
|
|
|
last_bss = ELF_PAGEALIGN(last_bss);
|
|
|
|
/* Finally, if there is still more bss to allocate, do it. */
|
2009-09-09 02:49:40 +00:00
|
|
|
if (last_bss > elf_bss) {
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
error = vm_brk_flags(elf_bss, last_bss - elf_bss,
|
|
|
|
bss_prot & PROT_EXEC ? VM_EXEC : 0);
|
2016-05-27 22:57:31 +00:00
|
|
|
if (error)
|
2014-09-11 07:30:15 +00:00
|
|
|
goto out;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2008-01-30 12:31:07 +00:00
|
|
|
error = load_addr;
|
2005-04-16 22:20:36 +00:00
|
|
|
out:
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These are the functions used to load ELF style executables and shared
|
|
|
|
* libraries. There is no binary dependent code anywhere else.
|
|
|
|
*/
|
|
|
|
|
2020-03-16 16:50:44 +00:00
|
|
|
static int parse_elf_property(const char *data, size_t *off, size_t datasz,
|
|
|
|
struct arch_elf_state *arch,
|
|
|
|
bool have_prev_type, u32 *prev_type)
|
|
|
|
{
|
|
|
|
size_t o, step;
|
|
|
|
const struct gnu_property *pr;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (*off == datasz)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(*off > datasz || *off % ELF_GNU_PROPERTY_ALIGN))
|
|
|
|
return -EIO;
|
|
|
|
o = *off;
|
|
|
|
datasz -= *off;
|
|
|
|
|
|
|
|
if (datasz < sizeof(*pr))
|
|
|
|
return -ENOEXEC;
|
|
|
|
pr = (const struct gnu_property *)(data + o);
|
|
|
|
o += sizeof(*pr);
|
|
|
|
datasz -= sizeof(*pr);
|
|
|
|
|
|
|
|
if (pr->pr_datasz > datasz)
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
|
|
|
WARN_ON_ONCE(o % ELF_GNU_PROPERTY_ALIGN);
|
|
|
|
step = round_up(pr->pr_datasz, ELF_GNU_PROPERTY_ALIGN);
|
|
|
|
if (step > datasz)
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
|
|
|
/* Properties are supposed to be unique and sorted on pr_type: */
|
|
|
|
if (have_prev_type && pr->pr_type <= *prev_type)
|
|
|
|
return -ENOEXEC;
|
|
|
|
*prev_type = pr->pr_type;
|
|
|
|
|
|
|
|
ret = arch_parse_elf_property(pr->pr_type, data + o,
|
|
|
|
pr->pr_datasz, ELF_COMPAT, arch);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
*off = o + step;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define NOTE_DATA_SZ SZ_1K
|
|
|
|
#define GNU_PROPERTY_TYPE_0_NAME "GNU"
|
|
|
|
#define NOTE_NAME_SZ (sizeof(GNU_PROPERTY_TYPE_0_NAME))
|
|
|
|
|
|
|
|
static int parse_elf_properties(struct file *f, const struct elf_phdr *phdr,
|
|
|
|
struct arch_elf_state *arch)
|
|
|
|
{
|
|
|
|
union {
|
|
|
|
struct elf_note nhdr;
|
|
|
|
char data[NOTE_DATA_SZ];
|
|
|
|
} note;
|
|
|
|
loff_t pos;
|
|
|
|
ssize_t n;
|
|
|
|
size_t off, datasz;
|
|
|
|
int ret;
|
|
|
|
bool have_prev_type;
|
|
|
|
u32 prev_type;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_ARCH_USE_GNU_PROPERTY) || !phdr)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* load_elf_binary() shouldn't call us unless this is true... */
|
|
|
|
if (WARN_ON_ONCE(phdr->p_type != PT_GNU_PROPERTY))
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
|
|
|
/* If the properties are crazy large, that's too bad (for now): */
|
|
|
|
if (phdr->p_filesz > sizeof(note))
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
|
|
|
pos = phdr->p_offset;
|
|
|
|
n = kernel_read(f, ¬e, phdr->p_filesz, &pos);
|
|
|
|
|
|
|
|
BUILD_BUG_ON(sizeof(note) < sizeof(note.nhdr) + NOTE_NAME_SZ);
|
|
|
|
if (n < 0 || n < sizeof(note.nhdr) + NOTE_NAME_SZ)
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
if (note.nhdr.n_type != NT_GNU_PROPERTY_TYPE_0 ||
|
|
|
|
note.nhdr.n_namesz != NOTE_NAME_SZ ||
|
|
|
|
strncmp(note.data + sizeof(note.nhdr),
|
|
|
|
GNU_PROPERTY_TYPE_0_NAME, n - sizeof(note.nhdr)))
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
|
|
|
off = round_up(sizeof(note.nhdr) + NOTE_NAME_SZ,
|
|
|
|
ELF_GNU_PROPERTY_ALIGN);
|
|
|
|
if (off > n)
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
|
|
|
if (note.nhdr.n_descsz > n - off)
|
|
|
|
return -ENOEXEC;
|
|
|
|
datasz = off + note.nhdr.n_descsz;
|
|
|
|
|
|
|
|
have_prev_type = false;
|
|
|
|
do {
|
|
|
|
ret = parse_elf_property(note.data, &off, datasz, arch,
|
|
|
|
have_prev_type, &prev_type);
|
|
|
|
have_prev_type = true;
|
|
|
|
} while (!ret);
|
|
|
|
|
|
|
|
return ret == -ENOENT ? 0 : ret;
|
|
|
|
}
|
|
|
|
|
2012-10-21 02:00:48 +00:00
|
|
|
static int load_elf_binary(struct linux_binprm *bprm)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct file *interpreter = NULL; /* to shut gcc up */
|
2022-01-27 12:40:17 +00:00
|
|
|
unsigned long load_bias = 0, phdr_addr = 0;
|
|
|
|
int first_pt_load = 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
unsigned long error;
|
2014-09-11 07:30:15 +00:00
|
|
|
struct elf_phdr *elf_ppnt, *elf_phdata, *interp_elf_phdata = NULL;
|
2020-03-16 16:50:44 +00:00
|
|
|
struct elf_phdr *elf_property_phdata = NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
unsigned long elf_bss, elf_brk;
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
int bss_prot = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
int retval, i;
|
2008-01-30 12:31:07 +00:00
|
|
|
unsigned long elf_entry;
|
2020-01-31 06:16:55 +00:00
|
|
|
unsigned long e_entry;
|
2008-01-30 12:31:07 +00:00
|
|
|
unsigned long interp_load_addr = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
unsigned long start_code, end_code, start_data, end_data;
|
2011-03-22 23:34:48 +00:00
|
|
|
unsigned long reloc_func_desc __maybe_unused = 0;
|
2006-12-07 04:40:16 +00:00
|
|
|
int executable_stack = EXSTACK_DEFAULT;
|
2020-01-31 06:16:55 +00:00
|
|
|
struct elfhdr *elf_ex = (struct elfhdr *)bprm->buf;
|
2020-04-07 03:11:29 +00:00
|
|
|
struct elfhdr *interp_elf_ex = NULL;
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
struct arch_elf_state arch_state = INIT_ARCH_ELF_STATE;
|
2020-01-31 06:16:58 +00:00
|
|
|
struct mm_struct *mm;
|
2019-05-14 22:43:54 +00:00
|
|
|
struct pt_regs *regs;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
retval = -ENOEXEC;
|
|
|
|
/* First of all, some simple consistency checks */
|
2020-01-31 06:16:55 +00:00
|
|
|
if (memcmp(elf_ex->e_ident, ELFMAG, SELFMAG) != 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out;
|
|
|
|
|
2020-01-31 06:16:55 +00:00
|
|
|
if (elf_ex->e_type != ET_EXEC && elf_ex->e_type != ET_DYN)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out;
|
2020-01-31 06:16:55 +00:00
|
|
|
if (!elf_check_arch(elf_ex))
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out;
|
2020-01-31 06:16:55 +00:00
|
|
|
if (elf_check_fdpic(elf_ex))
|
2017-08-16 20:05:13 +00:00
|
|
|
goto out;
|
2013-09-22 20:27:52 +00:00
|
|
|
if (!bprm->file->f_op->mmap)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out;
|
|
|
|
|
2020-01-31 06:16:55 +00:00
|
|
|
elf_phdata = load_elf_phdrs(elf_ex, bprm->file);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!elf_phdata)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
elf_ppnt = elf_phdata;
|
2020-01-31 06:16:55 +00:00
|
|
|
for (i = 0; i < elf_ex->e_phnum; i++, elf_ppnt++) {
|
2019-05-14 22:43:45 +00:00
|
|
|
char *elf_interpreter;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2020-03-16 16:50:44 +00:00
|
|
|
if (elf_ppnt->p_type == PT_GNU_PROPERTY) {
|
|
|
|
elf_property_phdata = elf_ppnt;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2019-05-14 22:43:45 +00:00
|
|
|
if (elf_ppnt->p_type != PT_INTERP)
|
|
|
|
continue;
|
2007-01-26 08:57:16 +00:00
|
|
|
|
2019-05-14 22:43:45 +00:00
|
|
|
/*
|
|
|
|
* This is the program interpreter used for shared libraries -
|
|
|
|
* for now assume that this is an a.out format binary.
|
|
|
|
*/
|
|
|
|
retval = -ENOEXEC;
|
|
|
|
if (elf_ppnt->p_filesz > PATH_MAX || elf_ppnt->p_filesz < 2)
|
|
|
|
goto out_free_ph;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-14 22:43:45 +00:00
|
|
|
retval = -ENOMEM;
|
|
|
|
elf_interpreter = kmalloc(elf_ppnt->p_filesz, GFP_KERNEL);
|
|
|
|
if (!elf_interpreter)
|
|
|
|
goto out_free_ph;
|
2019-05-14 22:43:39 +00:00
|
|
|
|
2019-12-05 00:52:25 +00:00
|
|
|
retval = elf_read(bprm->file, elf_interpreter, elf_ppnt->p_filesz,
|
|
|
|
elf_ppnt->p_offset);
|
|
|
|
if (retval < 0)
|
2019-05-14 22:43:45 +00:00
|
|
|
goto out_free_interp;
|
|
|
|
/* make sure path is NULL terminated */
|
|
|
|
retval = -ENOEXEC;
|
|
|
|
if (elf_interpreter[elf_ppnt->p_filesz - 1] != '\0')
|
|
|
|
goto out_free_interp;
|
|
|
|
|
|
|
|
interpreter = open_exec(elf_interpreter);
|
|
|
|
kfree(elf_interpreter);
|
|
|
|
retval = PTR_ERR(interpreter);
|
|
|
|
if (IS_ERR(interpreter))
|
2019-05-14 22:43:39 +00:00
|
|
|
goto out_free_ph;
|
2019-05-14 22:43:45 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the binary is not readable then enforce mm->dumpable = 0
|
|
|
|
* regardless of the interpreter's permissions.
|
|
|
|
*/
|
|
|
|
would_dump(bprm, interpreter);
|
|
|
|
|
2020-04-07 03:11:29 +00:00
|
|
|
interp_elf_ex = kmalloc(sizeof(*interp_elf_ex), GFP_KERNEL);
|
|
|
|
if (!interp_elf_ex) {
|
|
|
|
retval = -ENOMEM;
|
2022-10-24 15:44:21 +00:00
|
|
|
goto out_free_file;
|
2020-04-07 03:11:29 +00:00
|
|
|
}
|
|
|
|
|
2019-05-14 22:43:45 +00:00
|
|
|
/* Get the exec headers */
|
2020-04-07 03:11:26 +00:00
|
|
|
retval = elf_read(interpreter, interp_elf_ex,
|
|
|
|
sizeof(*interp_elf_ex), 0);
|
2019-12-05 00:52:25 +00:00
|
|
|
if (retval < 0)
|
2019-05-14 22:43:45 +00:00
|
|
|
goto out_free_dentry;
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
out_free_interp:
|
|
|
|
kfree(elf_interpreter);
|
|
|
|
goto out_free_ph;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
elf_ppnt = elf_phdata;
|
2020-01-31 06:16:55 +00:00
|
|
|
for (i = 0; i < elf_ex->e_phnum; i++, elf_ppnt++)
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
switch (elf_ppnt->p_type) {
|
|
|
|
case PT_GNU_STACK:
|
2005-04-16 22:20:36 +00:00
|
|
|
if (elf_ppnt->p_flags & PF_X)
|
|
|
|
executable_stack = EXSTACK_ENABLE_X;
|
|
|
|
else
|
|
|
|
executable_stack = EXSTACK_DISABLE_X;
|
|
|
|
break;
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
|
|
|
|
case PT_LOPROC ... PT_HIPROC:
|
2020-01-31 06:16:55 +00:00
|
|
|
retval = arch_elf_pt_proc(elf_ex, elf_ppnt,
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
bprm->file, false,
|
|
|
|
&arch_state);
|
|
|
|
if (retval)
|
|
|
|
goto out_free_dentry;
|
|
|
|
break;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Some simple consistency checks for the interpreter */
|
2019-05-14 22:43:39 +00:00
|
|
|
if (interpreter) {
|
2005-04-16 22:20:36 +00:00
|
|
|
retval = -ELIBBAD;
|
2008-02-08 12:21:54 +00:00
|
|
|
/* Not an ELF interpreter */
|
2020-04-07 03:11:26 +00:00
|
|
|
if (memcmp(interp_elf_ex->e_ident, ELFMAG, SELFMAG) != 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out_free_dentry;
|
|
|
|
/* Verify the interpreter has a valid arch */
|
2020-04-07 03:11:26 +00:00
|
|
|
if (!elf_check_arch(interp_elf_ex) ||
|
|
|
|
elf_check_fdpic(interp_elf_ex))
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out_free_dentry;
|
2014-09-11 07:30:15 +00:00
|
|
|
|
|
|
|
/* Load the interpreter program headers */
|
2020-04-07 03:11:26 +00:00
|
|
|
interp_elf_phdata = load_elf_phdrs(interp_elf_ex,
|
2014-09-11 07:30:15 +00:00
|
|
|
interpreter);
|
|
|
|
if (!interp_elf_phdata)
|
|
|
|
goto out_free_dentry;
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
|
|
|
|
/* Pass PT_LOPROC..PT_HIPROC headers to arch code */
|
2020-03-16 16:50:44 +00:00
|
|
|
elf_property_phdata = NULL;
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
elf_ppnt = interp_elf_phdata;
|
2020-04-07 03:11:26 +00:00
|
|
|
for (i = 0; i < interp_elf_ex->e_phnum; i++, elf_ppnt++)
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
switch (elf_ppnt->p_type) {
|
2020-03-16 16:50:44 +00:00
|
|
|
case PT_GNU_PROPERTY:
|
|
|
|
elf_property_phdata = elf_ppnt;
|
|
|
|
break;
|
|
|
|
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
case PT_LOPROC ... PT_HIPROC:
|
2020-04-07 03:11:26 +00:00
|
|
|
retval = arch_elf_pt_proc(interp_elf_ex,
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
elf_ppnt, interpreter,
|
|
|
|
true, &arch_state);
|
|
|
|
if (retval)
|
|
|
|
goto out_free_dentry;
|
|
|
|
break;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2020-03-16 16:50:44 +00:00
|
|
|
retval = parse_elf_properties(interpreter ?: bprm->file,
|
|
|
|
elf_property_phdata, &arch_state);
|
|
|
|
if (retval)
|
|
|
|
goto out_free_dentry;
|
|
|
|
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
/*
|
|
|
|
* Allow arch code to reject the ELF at this point, whilst it's
|
|
|
|
* still possible to return an error to the code that invoked
|
|
|
|
* the exec syscall.
|
|
|
|
*/
|
2020-01-31 06:16:55 +00:00
|
|
|
retval = arch_check_elf(elf_ex,
|
2020-04-07 03:11:26 +00:00
|
|
|
!!interpreter, interp_elf_ex,
|
2015-11-13 00:47:48 +00:00
|
|
|
&arch_state);
|
binfmt_elf: allow arch code to examine PT_LOPROC ... PT_HIPROC headers
MIPS is introducing new variants of its O32 ABI which differ in their
handling of floating point, in order to enable a gradual transition
towards a world where mips32 binaries can take advantage of new hardware
features only available when configured for certain FP modes. In order
to do this ELF binaries are being augmented with a new section that
indicates, amongst other things, the FP mode requirements of the binary.
The presence & location of such a section is indicated by a program
header in the PT_LOPROC ... PT_HIPROC range.
In order to allow the MIPS architecture code to examine the program
header & section in question, pass all program headers in this range
to an architecture-specific arch_elf_pt_proc function. This function
may return an error if the header is deemed invalid or unsuitable for
the system, in which case that error will be returned from
load_elf_binary and upwards through the execve syscall.
A means is required for the architecture code to make a decision once
it is known that all such headers have been seen, but before it is too
late to return from an execve syscall. For this purpose the
arch_check_elf function is added, and called once, after all PT_LOPROC
to PT_HIPROC headers have been passed to arch_elf_pt_proc but before
the code which invoked execve has been lost. This enables the
architecture code to make a decision based upon all the headers present
in an ELF binary and its interpreter, as is required to forbid
conflicting FP ABI requirements between an ELF & its interpreter.
In order to allow data to be stored throughout the calls to the above
functions, struct arch_elf_state is introduced.
Finally a variant of the SET_PERSONALITY macro is introduced which
accepts a pointer to the struct arch_elf_state, allowing it to act
based upon state observed from the architecture specific program
headers.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7679/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-09-11 07:30:16 +00:00
|
|
|
if (retval)
|
|
|
|
goto out_free_dentry;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Flush all traces of the currently running executable */
|
2020-05-03 12:54:10 +00:00
|
|
|
retval = begin_new_exec(bprm);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (retval)
|
|
|
|
goto out_free_dentry;
|
|
|
|
|
|
|
|
/* Do this immediately, since STACK_TOP as used in setup_arg_pages
|
|
|
|
may depend on the personality. */
|
2020-01-31 06:16:55 +00:00
|
|
|
SET_PERSONALITY2(*elf_ex, &arch_state);
|
|
|
|
if (elf_read_implies_exec(*elf_ex, executable_stack))
|
2005-04-16 22:20:36 +00:00
|
|
|
current->personality |= READ_IMPLIES_EXEC;
|
|
|
|
|
2006-06-23 09:05:35 +00:00
|
|
|
if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
|
2005-04-16 22:20:36 +00:00
|
|
|
current->flags |= PF_RANDOMIZE;
|
Split 'flush_old_exec' into two functions
'flush_old_exec()' is the point of no return when doing an execve(), and
it is pretty badly misnamed. It doesn't just flush the old executable
environment, it also starts up the new one.
Which is very inconvenient for things like setting up the new
personality, because we want the new personality to affect the starting
of the new environment, but at the same time we do _not_ want the new
personality to take effect if flushing the old one fails.
As a result, the x86-64 '32-bit' personality is actually done using this
insane "I'm going to change the ABI, but I haven't done it yet" bit
(TIF_ABI_PENDING), with SET_PERSONALITY() not actually setting the
personality, but just the "pending" bit, so that "flush_thread()" can do
the actual personality magic.
This patch in no way changes any of that insanity, but it does split the
'flush_old_exec()' function up into a preparatory part that can fail
(still called flush_old_exec()), and a new part that will actually set
up the new exec environment (setup_new_exec()). All callers are changed
to trivially comply with the new world order.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-01-29 06:14:42 +00:00
|
|
|
|
|
|
|
setup_new_exec(bprm);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Do this so that we can load the interpreter, if need be. We will
|
|
|
|
change some of these later */
|
|
|
|
retval = setup_arg_pages(bprm, randomize_stack_top(STACK_TOP),
|
|
|
|
executable_stack);
|
2014-05-05 00:11:36 +00:00
|
|
|
if (retval < 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out_free_dentry;
|
2022-10-18 07:14:20 +00:00
|
|
|
|
2019-05-14 22:43:48 +00:00
|
|
|
elf_bss = 0;
|
|
|
|
elf_brk = 0;
|
|
|
|
|
|
|
|
start_code = ~0UL;
|
|
|
|
end_code = 0;
|
|
|
|
start_data = 0;
|
|
|
|
end_data = 0;
|
|
|
|
|
tree-wide: fix assorted typos all over the place
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-11-14 15:09:05 +00:00
|
|
|
/* Now we do a little grungy work by mmapping the ELF image into
|
2008-01-30 12:31:07 +00:00
|
|
|
the correct location in memory. */
|
2006-06-23 09:05:35 +00:00
|
|
|
for(i = 0, elf_ppnt = elf_phdata;
|
2020-01-31 06:16:55 +00:00
|
|
|
i < elf_ex->e_phnum; i++, elf_ppnt++) {
|
elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings
In commit 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") we
changed elf to use MAP_FIXED_NOREPLACE instead of MAP_FIXED for the
executable mappings.
Then, people reported that it broke some binaries that had overlapping
segments from the same file, and commit ad55eac74f20 ("elf: enforce
MAP_FIXED on overlaying elf segments") re-instated MAP_FIXED for some
overlaying elf segment cases. But only some - despite the summary line
of that commit, it only did it when it also does a temporary brk vma for
one obvious overlapping case.
Now Russell King reports another overlapping case with old 32-bit x86
binaries, which doesn't trigger that limited case. End result: we had
better just drop MAP_FIXED_NOREPLACE entirely, and go back to MAP_FIXED.
Yes, it's a sign of old binaries generated with old tool-chains, but we
do pride ourselves on not breaking existing setups.
This still leaves MAP_FIXED_NOREPLACE in place for the load_elf_interp()
and the old load_elf_library() use-cases, because nobody has reported
breakage for those. Yet.
Note that in all the cases seen so far, the overlapping elf sections
seem to be just re-mapping of the same executable with different section
attributes. We could possibly introduce a new MAP_FIXED_NOFILECHANGE
flag or similar, which acts like NOREPLACE, but allows just remapping
the same executable file using different protection flags.
It's not clear that would make a huge difference to anything, but if
people really hate that "elf remaps over previous maps" behavior, maybe
at least a more limited form of remapping would alleviate some concerns.
Alternatively, we should take a look at our elf_map() logic to see if we
end up not mapping things properly the first time.
In the meantime, this is the minimal "don't do that then" patch while
people hopefully think about it more.
Reported-by: Russell King <linux@armlinux.org.uk>
Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map")
Fixes: ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments")
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-06 20:53:27 +00:00
|
|
|
int elf_prot, elf_flags;
|
2005-04-16 22:20:36 +00:00
|
|
|
unsigned long k, vaddr;
|
2015-04-14 22:47:38 +00:00
|
|
|
unsigned long total_size = 0;
|
fs/binfmt_elf: use PT_LOAD p_align values for suitable start address
Patch series "Selecting Load Addresses According to p_align", v3.
The current ELF loading mechancism provides page-aligned mappings. This
can lead to the program being loaded in a way unsuitable for file-backed,
transparent huge pages when handling PIE executables.
While specifying -z,max-page-size=0x200000 to the linker will generate
suitably aligned segments for huge pages on x86_64, the executable needs
to be loaded at a suitably aligned address as well. This alignment
requires the binary's cooperation, as distinct segments need to be
appropriately paddded to be eligible for THP.
For binaries built with increased alignment, this limits the number of
bits usable for ASLR, but provides some randomization over using fixed
load addresses/non-PIE binaries.
This patch (of 2):
The current ELF loading mechancism provides page-aligned mappings. This
can lead to the program being loaded in a way unsuitable for file-backed,
transparent huge pages when handling PIE executables.
For binaries built with increased alignment, this limits the number of
bits usable for ASLR, but provides some randomization over using fixed
load addresses/non-PIE binaries.
Tested by verifying program with -Wl,-z,max-page-size=0x200000 loading.
[akpm@linux-foundation.org: fix max() warning]
[ckennelly@google.com: augment comment]
Link: https://lkml.kernel.org/r/20200821233848.3904680-2-ckennelly@google.com
Signed-off-by: Chris Kennelly <ckennelly@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Hugh Dickens <hughd@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Fangrui Song <maskray@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: https://lkml.kernel.org/r/20200820170541.1132271-1-ckennelly@google.com
Link: https://lkml.kernel.org/r/20200820170541.1132271-2-ckennelly@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:12:32 +00:00
|
|
|
unsigned long alignment;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (elf_ppnt->p_type != PT_LOAD)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (unlikely (elf_brk > elf_bss)) {
|
|
|
|
unsigned long nbyte;
|
2022-10-18 07:14:20 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* There was a PT_LOAD segment with p_memsz > p_filesz
|
|
|
|
before this one. Map anonymous pages, if needed,
|
|
|
|
and clear the area. */
|
2011-01-13 01:00:02 +00:00
|
|
|
retval = set_brk(elf_bss + load_bias,
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
elf_brk + load_bias,
|
|
|
|
bss_prot);
|
2014-05-05 00:11:36 +00:00
|
|
|
if (retval)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out_free_dentry;
|
|
|
|
nbyte = ELF_PAGEOFFSET(elf_bss);
|
|
|
|
if (nbyte) {
|
|
|
|
nbyte = ELF_MIN_ALIGN - nbyte;
|
|
|
|
if (nbyte > elf_brk - elf_bss)
|
|
|
|
nbyte = elf_brk - elf_bss;
|
|
|
|
if (clear_user((void __user *)elf_bss +
|
|
|
|
load_bias, nbyte)) {
|
|
|
|
/*
|
|
|
|
* This bss-zeroing can fail if the ELF
|
2006-06-23 09:05:35 +00:00
|
|
|
* file specifies odd protections. So
|
2005-04-16 22:20:36 +00:00
|
|
|
* we don't check the return value
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-16 16:50:46 +00:00
|
|
|
elf_prot = make_prot(elf_ppnt->p_flags, &arch_state,
|
|
|
|
!!interpreter, false);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
binfmt: remove in-tree usage of MAP_DENYWRITE
At exec time when we mmap the new executable via MAP_DENYWRITE we have it
opened via do_open_execat() and already deny_write_access()'ed the file
successfully. Once exec completes, we allow_write_acces(); however,
we set mm->exe_file in begin_new_exec() via set_mm_exe_file() and
also deny_write_access() as long as mm->exe_file remains set. We'll
effectively deny write access to our executable via mm->exe_file
until mm->exe_file is changed -- when the process is removed, on new
exec, or via sys_prctl(PR_SET_MM_MAP/EXE_FILE).
Let's remove all usage of MAP_DENYWRITE, it's no longer necessary for
mm->exe_file.
In case of an elf interpreter, we'll now only deny write access to the file
during exec. This is somewhat okay, because the interpreter behaves
(and sometime is) a shared library; all shared libraries, especially the
ones loaded directly in user space like via dlopen() won't ever be mapped
via MAP_DENYWRITE, because we ignore that from user space completely;
these shared libraries can always be modified while mapped and executed.
Let's only special-case the main executable, denying write access while
being executed by a process. This can be considered a minor user space
visible change.
While this is a cleanup, it also fixes part of a problem reported with
VM_DENYWRITE on overlayfs, as VM_DENYWRITE is effectively unused with
this patch and will be removed next:
"Overlayfs did not honor positive i_writecount on realfile for
VM_DENYWRITE mappings." [1]
[1] https://lore.kernel.org/r/YNHXzBgzRrZu1MrD@miu.piliscsaba.redhat.com/
Reported-by: Chengguang Xu <cgxu519@mykernel.net>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2021-04-23 07:42:41 +00:00
|
|
|
elf_flags = MAP_PRIVATE;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
vaddr = elf_ppnt->p_vaddr;
|
binfmt_elf: use ELF_ET_DYN_BASE only for PIE
The ELF_ET_DYN_BASE position was originally intended to keep loaders
away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2
/bin/cat" might cause the subsequent load of /bin/cat into where the
loader had been loaded.)
With the advent of PIE (ET_DYN binaries with an INTERP Program Header),
ELF_ET_DYN_BASE continued to be used since the kernel was only looking
at ET_DYN. However, since ELF_ET_DYN_BASE is traditionally set at the
top 1/3rd of the TASK_SIZE, a substantial portion of the address space
is unused.
For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs are
loaded above the mmap region. This means they can be made to collide
(CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
pathological stack regions.
Lowering ELF_ET_DYN_BASE solves both by moving programs below the mmap
region in all cases, and will now additionally avoid programs falling
back to the mmap region by enforcing MAP_FIXED for program loads (i.e.
if it would have collided with the stack, now it will fail to load
instead of falling back to the mmap region).
To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
are loaded into the mmap region, leaving space available for either an
ET_EXEC binary with a fixed location or PIE being loaded into mmap by
the loader. Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
which means architectures can now safely lower their values without risk
of loaders colliding with their subsequently loaded programs.
For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to use
the entire 32-bit address space for 32-bit pointers.
Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration and
suggestions on how to implement this solution.
Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
Link: http://lkml.kernel.org/r/20170621173201.GA114489@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-07-10 22:52:37 +00:00
|
|
|
/*
|
2022-01-27 12:40:17 +00:00
|
|
|
* The first time through the loop, first_pt_load is true:
|
2021-11-09 02:33:37 +00:00
|
|
|
* layout will be calculated. Once set, use MAP_FIXED since
|
|
|
|
* we know we've already safely mapped the entire region with
|
|
|
|
* MAP_FIXED_NOREPLACE in the once-per-binary logic following.
|
binfmt_elf: use ELF_ET_DYN_BASE only for PIE
The ELF_ET_DYN_BASE position was originally intended to keep loaders
away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2
/bin/cat" might cause the subsequent load of /bin/cat into where the
loader had been loaded.)
With the advent of PIE (ET_DYN binaries with an INTERP Program Header),
ELF_ET_DYN_BASE continued to be used since the kernel was only looking
at ET_DYN. However, since ELF_ET_DYN_BASE is traditionally set at the
top 1/3rd of the TASK_SIZE, a substantial portion of the address space
is unused.
For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs are
loaded above the mmap region. This means they can be made to collide
(CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
pathological stack regions.
Lowering ELF_ET_DYN_BASE solves both by moving programs below the mmap
region in all cases, and will now additionally avoid programs falling
back to the mmap region by enforcing MAP_FIXED for program loads (i.e.
if it would have collided with the stack, now it will fail to load
instead of falling back to the mmap region).
To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
are loaded into the mmap region, leaving space available for either an
ET_EXEC binary with a fixed location or PIE being loaded into mmap by
the loader. Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
which means architectures can now safely lower their values without risk
of loaders colliding with their subsequently loaded programs.
For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to use
the entire 32-bit address space for 32-bit pointers.
Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration and
suggestions on how to implement this solution.
Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
Link: http://lkml.kernel.org/r/20170621173201.GA114489@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-07-10 22:52:37 +00:00
|
|
|
*/
|
2022-01-27 12:40:17 +00:00
|
|
|
if (!first_pt_load) {
|
elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings
In commit 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") we
changed elf to use MAP_FIXED_NOREPLACE instead of MAP_FIXED for the
executable mappings.
Then, people reported that it broke some binaries that had overlapping
segments from the same file, and commit ad55eac74f20 ("elf: enforce
MAP_FIXED on overlaying elf segments") re-instated MAP_FIXED for some
overlaying elf segment cases. But only some - despite the summary line
of that commit, it only did it when it also does a temporary brk vma for
one obvious overlapping case.
Now Russell King reports another overlapping case with old 32-bit x86
binaries, which doesn't trigger that limited case. End result: we had
better just drop MAP_FIXED_NOREPLACE entirely, and go back to MAP_FIXED.
Yes, it's a sign of old binaries generated with old tool-chains, but we
do pride ourselves on not breaking existing setups.
This still leaves MAP_FIXED_NOREPLACE in place for the load_elf_interp()
and the old load_elf_library() use-cases, because nobody has reported
breakage for those. Yet.
Note that in all the cases seen so far, the overlapping elf sections
seem to be just re-mapping of the same executable with different section
attributes. We could possibly introduce a new MAP_FIXED_NOFILECHANGE
flag or similar, which acts like NOREPLACE, but allows just remapping
the same executable file using different protection flags.
It's not clear that would make a huge difference to anything, but if
people really hate that "elf remaps over previous maps" behavior, maybe
at least a more limited form of remapping would alleviate some concerns.
Alternatively, we should take a look at our elf_map() logic to see if we
end up not mapping things properly the first time.
In the meantime, this is the minimal "don't do that then" patch while
people hopefully think about it more.
Reported-by: Russell King <linux@armlinux.org.uk>
Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map")
Fixes: ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments")
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-10-06 20:53:27 +00:00
|
|
|
elf_flags |= MAP_FIXED;
|
2021-11-09 02:33:37 +00:00
|
|
|
} else if (elf_ex->e_type == ET_EXEC) {
|
|
|
|
/*
|
|
|
|
* This logic is run once for the first LOAD Program
|
|
|
|
* Header for ET_EXEC binaries. No special handling
|
|
|
|
* is needed.
|
|
|
|
*/
|
|
|
|
elf_flags |= MAP_FIXED_NOREPLACE;
|
2020-01-31 06:16:55 +00:00
|
|
|
} else if (elf_ex->e_type == ET_DYN) {
|
binfmt_elf: use ELF_ET_DYN_BASE only for PIE
The ELF_ET_DYN_BASE position was originally intended to keep loaders
away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2
/bin/cat" might cause the subsequent load of /bin/cat into where the
loader had been loaded.)
With the advent of PIE (ET_DYN binaries with an INTERP Program Header),
ELF_ET_DYN_BASE continued to be used since the kernel was only looking
at ET_DYN. However, since ELF_ET_DYN_BASE is traditionally set at the
top 1/3rd of the TASK_SIZE, a substantial portion of the address space
is unused.
For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs are
loaded above the mmap region. This means they can be made to collide
(CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
pathological stack regions.
Lowering ELF_ET_DYN_BASE solves both by moving programs below the mmap
region in all cases, and will now additionally avoid programs falling
back to the mmap region by enforcing MAP_FIXED for program loads (i.e.
if it would have collided with the stack, now it will fail to load
instead of falling back to the mmap region).
To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
are loaded into the mmap region, leaving space available for either an
ET_EXEC binary with a fixed location or PIE being loaded into mmap by
the loader. Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
which means architectures can now safely lower their values without risk
of loaders colliding with their subsequently loaded programs.
For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to use
the entire 32-bit address space for 32-bit pointers.
Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration and
suggestions on how to implement this solution.
Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
Link: http://lkml.kernel.org/r/20170621173201.GA114489@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-07-10 22:52:37 +00:00
|
|
|
/*
|
|
|
|
* This logic is run once for the first LOAD Program
|
|
|
|
* Header for ET_DYN binaries to calculate the
|
|
|
|
* randomization (load_bias) for all the LOAD
|
2021-11-09 02:33:37 +00:00
|
|
|
* Program Headers.
|
binfmt_elf: use ELF_ET_DYN_BASE only for PIE
The ELF_ET_DYN_BASE position was originally intended to keep loaders
away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2
/bin/cat" might cause the subsequent load of /bin/cat into where the
loader had been loaded.)
With the advent of PIE (ET_DYN binaries with an INTERP Program Header),
ELF_ET_DYN_BASE continued to be used since the kernel was only looking
at ET_DYN. However, since ELF_ET_DYN_BASE is traditionally set at the
top 1/3rd of the TASK_SIZE, a substantial portion of the address space
is unused.
For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs are
loaded above the mmap region. This means they can be made to collide
(CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
pathological stack regions.
Lowering ELF_ET_DYN_BASE solves both by moving programs below the mmap
region in all cases, and will now additionally avoid programs falling
back to the mmap region by enforcing MAP_FIXED for program loads (i.e.
if it would have collided with the stack, now it will fail to load
instead of falling back to the mmap region).
To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
are loaded into the mmap region, leaving space available for either an
ET_EXEC binary with a fixed location or PIE being loaded into mmap by
the loader. Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
which means architectures can now safely lower their values without risk
of loaders colliding with their subsequently loaded programs.
For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to use
the entire 32-bit address space for 32-bit pointers.
Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration and
suggestions on how to implement this solution.
Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
Link: http://lkml.kernel.org/r/20170621173201.GA114489@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-07-10 22:52:37 +00:00
|
|
|
*
|
|
|
|
* There are effectively two types of ET_DYN
|
|
|
|
* binaries: programs (i.e. PIE: ET_DYN with INTERP)
|
|
|
|
* and loaders (ET_DYN without INTERP, since they
|
|
|
|
* _are_ the ELF interpreter). The loaders must
|
|
|
|
* be loaded away from programs since the program
|
|
|
|
* may otherwise collide with the loader (especially
|
|
|
|
* for ET_EXEC which does not have a randomized
|
|
|
|
* position). For example to handle invocations of
|
|
|
|
* "./ld.so someprog" to test out a new version of
|
|
|
|
* the loader, the subsequent program that the
|
|
|
|
* loader loads must avoid the loader itself, so
|
|
|
|
* they cannot share the same load range. Sufficient
|
|
|
|
* room for the brk must be allocated with the
|
|
|
|
* loader as well, since brk must be available with
|
|
|
|
* the loader.
|
|
|
|
*
|
|
|
|
* Therefore, programs are loaded offset from
|
|
|
|
* ELF_ET_DYN_BASE and loaders are loaded into the
|
|
|
|
* independently randomized mmap region (0 load_bias
|
2021-11-09 02:33:37 +00:00
|
|
|
* without MAP_FIXED nor MAP_FIXED_NOREPLACE).
|
binfmt_elf: use ELF_ET_DYN_BASE only for PIE
The ELF_ET_DYN_BASE position was originally intended to keep loaders
away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2
/bin/cat" might cause the subsequent load of /bin/cat into where the
loader had been loaded.)
With the advent of PIE (ET_DYN binaries with an INTERP Program Header),
ELF_ET_DYN_BASE continued to be used since the kernel was only looking
at ET_DYN. However, since ELF_ET_DYN_BASE is traditionally set at the
top 1/3rd of the TASK_SIZE, a substantial portion of the address space
is unused.
For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs are
loaded above the mmap region. This means they can be made to collide
(CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
pathological stack regions.
Lowering ELF_ET_DYN_BASE solves both by moving programs below the mmap
region in all cases, and will now additionally avoid programs falling
back to the mmap region by enforcing MAP_FIXED for program loads (i.e.
if it would have collided with the stack, now it will fail to load
instead of falling back to the mmap region).
To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
are loaded into the mmap region, leaving space available for either an
ET_EXEC binary with a fixed location or PIE being loaded into mmap by
the loader. Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
which means architectures can now safely lower their values without risk
of loaders colliding with their subsequently loaded programs.
For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to use
the entire 32-bit address space for 32-bit pointers.
Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration and
suggestions on how to implement this solution.
Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
Link: http://lkml.kernel.org/r/20170621173201.GA114489@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-07-10 22:52:37 +00:00
|
|
|
*/
|
2022-04-15 02:13:58 +00:00
|
|
|
if (interpreter) {
|
binfmt_elf: use ELF_ET_DYN_BASE only for PIE
The ELF_ET_DYN_BASE position was originally intended to keep loaders
away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2
/bin/cat" might cause the subsequent load of /bin/cat into where the
loader had been loaded.)
With the advent of PIE (ET_DYN binaries with an INTERP Program Header),
ELF_ET_DYN_BASE continued to be used since the kernel was only looking
at ET_DYN. However, since ELF_ET_DYN_BASE is traditionally set at the
top 1/3rd of the TASK_SIZE, a substantial portion of the address space
is unused.
For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs are
loaded above the mmap region. This means they can be made to collide
(CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
pathological stack regions.
Lowering ELF_ET_DYN_BASE solves both by moving programs below the mmap
region in all cases, and will now additionally avoid programs falling
back to the mmap region by enforcing MAP_FIXED for program loads (i.e.
if it would have collided with the stack, now it will fail to load
instead of falling back to the mmap region).
To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
are loaded into the mmap region, leaving space available for either an
ET_EXEC binary with a fixed location or PIE being loaded into mmap by
the loader. Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
which means architectures can now safely lower their values without risk
of loaders colliding with their subsequently loaded programs.
For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to use
the entire 32-bit address space for 32-bit pointers.
Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration and
suggestions on how to implement this solution.
Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
Link: http://lkml.kernel.org/r/20170621173201.GA114489@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-07-10 22:52:37 +00:00
|
|
|
load_bias = ELF_ET_DYN_BASE;
|
|
|
|
if (current->flags & PF_RANDOMIZE)
|
|
|
|
load_bias += arch_mmap_rnd();
|
2022-04-15 02:13:58 +00:00
|
|
|
alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum);
|
fs/binfmt_elf: use PT_LOAD p_align values for suitable start address
Patch series "Selecting Load Addresses According to p_align", v3.
The current ELF loading mechancism provides page-aligned mappings. This
can lead to the program being loaded in a way unsuitable for file-backed,
transparent huge pages when handling PIE executables.
While specifying -z,max-page-size=0x200000 to the linker will generate
suitably aligned segments for huge pages on x86_64, the executable needs
to be loaded at a suitably aligned address as well. This alignment
requires the binary's cooperation, as distinct segments need to be
appropriately paddded to be eligible for THP.
For binaries built with increased alignment, this limits the number of
bits usable for ASLR, but provides some randomization over using fixed
load addresses/non-PIE binaries.
This patch (of 2):
The current ELF loading mechancism provides page-aligned mappings. This
can lead to the program being loaded in a way unsuitable for file-backed,
transparent huge pages when handling PIE executables.
For binaries built with increased alignment, this limits the number of
bits usable for ASLR, but provides some randomization over using fixed
load addresses/non-PIE binaries.
Tested by verifying program with -Wl,-z,max-page-size=0x200000 loading.
[akpm@linux-foundation.org: fix max() warning]
[ckennelly@google.com: augment comment]
Link: https://lkml.kernel.org/r/20200821233848.3904680-2-ckennelly@google.com
Signed-off-by: Chris Kennelly <ckennelly@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Song Liu <songliubraving@fb.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Hugh Dickens <hughd@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Fangrui Song <maskray@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: https://lkml.kernel.org/r/20200820170541.1132271-1-ckennelly@google.com
Link: https://lkml.kernel.org/r/20200820170541.1132271-2-ckennelly@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:12:32 +00:00
|
|
|
if (alignment)
|
|
|
|
load_bias &= ~(alignment - 1);
|
2021-11-09 02:33:37 +00:00
|
|
|
elf_flags |= MAP_FIXED_NOREPLACE;
|
binfmt_elf: use ELF_ET_DYN_BASE only for PIE
The ELF_ET_DYN_BASE position was originally intended to keep loaders
away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2
/bin/cat" might cause the subsequent load of /bin/cat into where the
loader had been loaded.)
With the advent of PIE (ET_DYN binaries with an INTERP Program Header),
ELF_ET_DYN_BASE continued to be used since the kernel was only looking
at ET_DYN. However, since ELF_ET_DYN_BASE is traditionally set at the
top 1/3rd of the TASK_SIZE, a substantial portion of the address space
is unused.
For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs are
loaded above the mmap region. This means they can be made to collide
(CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
pathological stack regions.
Lowering ELF_ET_DYN_BASE solves both by moving programs below the mmap
region in all cases, and will now additionally avoid programs falling
back to the mmap region by enforcing MAP_FIXED for program loads (i.e.
if it would have collided with the stack, now it will fail to load
instead of falling back to the mmap region).
To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
are loaded into the mmap region, leaving space available for either an
ET_EXEC binary with a fixed location or PIE being loaded into mmap by
the loader. Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
which means architectures can now safely lower their values without risk
of loaders colliding with their subsequently loaded programs.
For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to use
the entire 32-bit address space for 32-bit pointers.
Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration and
suggestions on how to implement this solution.
Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
Link: http://lkml.kernel.org/r/20170621173201.GA114489@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-07-10 22:52:37 +00:00
|
|
|
} else
|
|
|
|
load_bias = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since load_bias is used for all subsequent loading
|
|
|
|
* calculations, we must lower it by the first vaddr
|
|
|
|
* so that the remaining calculations based on the
|
|
|
|
* ELF vaddrs will be correctly offset. The result
|
|
|
|
* is then page aligned.
|
|
|
|
*/
|
|
|
|
load_bias = ELF_PAGESTART(load_bias - vaddr);
|
|
|
|
|
2022-02-28 18:59:12 +00:00
|
|
|
/*
|
|
|
|
* Calculate the entire size of the ELF mapping
|
|
|
|
* (total_size), used for the initial mapping,
|
|
|
|
* due to load_addr_set which is set to true later
|
|
|
|
* once the initial mapping is performed.
|
|
|
|
*
|
|
|
|
* Note that this is only sensible when the LOAD
|
|
|
|
* segments are contiguous (or overlapping). If
|
|
|
|
* used for LOADs that are far apart, this would
|
|
|
|
* cause the holes between LOADs to be mapped,
|
|
|
|
* running the risk of having the mapping fail,
|
|
|
|
* as it would be larger than the ELF file itself.
|
|
|
|
*
|
|
|
|
* As a result, only ET_DYN does this, since
|
|
|
|
* some ET_EXEC (e.g. ia64) may have large virtual
|
|
|
|
* memory holes between LOADs.
|
|
|
|
*
|
|
|
|
*/
|
2015-04-14 22:47:38 +00:00
|
|
|
total_size = total_mapping_size(elf_phdata,
|
2020-01-31 06:16:55 +00:00
|
|
|
elf_ex->e_phnum);
|
2015-04-14 22:47:38 +00:00
|
|
|
if (!total_size) {
|
2015-05-28 22:44:24 +00:00
|
|
|
retval = -EINVAL;
|
2015-04-14 22:47:38 +00:00
|
|
|
goto out_free_dentry;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2006-06-23 09:05:35 +00:00
|
|
|
error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt,
|
2015-04-14 22:47:38 +00:00
|
|
|
elf_prot, elf_flags, total_size);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (BAD_ADDR(error)) {
|
2022-11-15 03:17:57 +00:00
|
|
|
retval = IS_ERR_VALUE(error) ?
|
2007-05-08 07:31:57 +00:00
|
|
|
PTR_ERR((void*)error) : -EINVAL;
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out_free_dentry;
|
|
|
|
}
|
|
|
|
|
2022-01-27 12:40:17 +00:00
|
|
|
if (first_pt_load) {
|
|
|
|
first_pt_load = 0;
|
2020-01-31 06:16:55 +00:00
|
|
|
if (elf_ex->e_type == ET_DYN) {
|
2005-04-16 22:20:36 +00:00
|
|
|
load_bias += error -
|
|
|
|
ELF_PAGESTART(load_bias + vaddr);
|
|
|
|
reloc_func_desc = load_bias;
|
|
|
|
}
|
|
|
|
}
|
2022-01-27 12:40:16 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Figure out which segment in the file contains the Program
|
|
|
|
* Header table, and map to the associated memory address.
|
|
|
|
*/
|
|
|
|
if (elf_ppnt->p_offset <= elf_ex->e_phoff &&
|
|
|
|
elf_ex->e_phoff < elf_ppnt->p_offset + elf_ppnt->p_filesz) {
|
|
|
|
phdr_addr = elf_ex->e_phoff - elf_ppnt->p_offset +
|
|
|
|
elf_ppnt->p_vaddr;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
k = elf_ppnt->p_vaddr;
|
2020-01-31 06:16:52 +00:00
|
|
|
if ((elf_ppnt->p_flags & PF_X) && k < start_code)
|
2006-06-23 09:05:35 +00:00
|
|
|
start_code = k;
|
|
|
|
if (start_data < k)
|
|
|
|
start_data = k;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to see if the section's size will overflow the
|
|
|
|
* allowed task size. Note that p_filesz must always be
|
|
|
|
* <= p_memsz so it is only necessary to check p_memsz.
|
|
|
|
*/
|
[PATCH] binfmt_elf: fix checks for bad address
Fix check for bad address; use macro instead of open-coding two checks.
Taken from RHEL4 kernel update.
From: Ernie Petrides <petrides@redhat.com>
For background, the BAD_ADDR() macro should return TRUE if the address is
TASK_SIZE, because that's the lowest address that is *not* valid for
user-space mappings. The macro was correct in binfmt_aout.c but was wrong
for the "equal to" case in binfmt_elf.c. There were two in-line validations
of user-space addresses in binfmt_elf.c, which have been appropriately
converted to use the corrected BAD_ADDR() macro in the patch you posted
yesterday. Note that the size checks against TASK_SIZE are okay as coded.
The additional changes that I propose are below. These are in the error
paths for bad ELF entry addresses once load_elf_binary() has already
committed to exec'ing the new image (following the tearing down of the
task's original address space).
The 1st hunk deals with the interp-side of the outer "if". There were two
problems here. The printk() should be removed because this path can be
triggered at will by a bogus interpreter image created and used by a
malicious user. Further, the error code should not be ENOEXEC, because that
causes the loop in search_binary_handler() to continue trying other exec
handlers (twice, in fact). But it's too late for this to work correctly,
because the user address space has already been torn down, and an exec()
failure cannot be returned to the user code because the code no longer
exists. The only recovery is to force a SIGSEGV, but it's best to terminate
the search loop immediately. I somewhat arbitrarily chose EINVAL as a
fallback error code, but any error returned by load_elf_interp() will
override that (but this value will never be seen by user-space).
The 2nd hunk deals with the non-interp-side of the outer "if". There were
two problems here as well. The SIGSEGV needs to be forced, because a prior
sigaction() syscall might have set the associated disposition to SIG_IGN.
And the ENOEXEC should be changed to EINVAL as described above.
Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Ernie Petrides <petrides@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-03 07:24:14 +00:00
|
|
|
if (BAD_ADDR(k) || elf_ppnt->p_filesz > elf_ppnt->p_memsz ||
|
2005-04-16 22:20:36 +00:00
|
|
|
elf_ppnt->p_memsz > TASK_SIZE ||
|
|
|
|
TASK_SIZE - elf_ppnt->p_memsz < k) {
|
2006-06-23 09:05:35 +00:00
|
|
|
/* set_brk can never work. Avoid overflows. */
|
2007-05-08 07:31:57 +00:00
|
|
|
retval = -EINVAL;
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out_free_dentry;
|
|
|
|
}
|
|
|
|
|
|
|
|
k = elf_ppnt->p_vaddr + elf_ppnt->p_filesz;
|
|
|
|
|
|
|
|
if (k > elf_bss)
|
|
|
|
elf_bss = k;
|
|
|
|
if ((elf_ppnt->p_flags & PF_X) && end_code < k)
|
|
|
|
end_code = k;
|
|
|
|
if (end_data < k)
|
|
|
|
end_data = k;
|
|
|
|
k = elf_ppnt->p_vaddr + elf_ppnt->p_memsz;
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
if (k > elf_brk) {
|
|
|
|
bss_prot = elf_prot;
|
2005-04-16 22:20:36 +00:00
|
|
|
elf_brk = k;
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2020-01-31 06:16:55 +00:00
|
|
|
e_entry = elf_ex->e_entry + load_bias;
|
2022-01-27 12:40:16 +00:00
|
|
|
phdr_addr += load_bias;
|
2005-04-16 22:20:36 +00:00
|
|
|
elf_bss += load_bias;
|
|
|
|
elf_brk += load_bias;
|
|
|
|
start_code += load_bias;
|
|
|
|
end_code += load_bias;
|
|
|
|
start_data += load_bias;
|
|
|
|
end_data += load_bias;
|
|
|
|
|
|
|
|
/* Calling set_brk effectively mmaps the pages that we need
|
|
|
|
* for the bss and break sections. We must do this before
|
|
|
|
* mapping in the interpreter, to make sure it doesn't wind
|
|
|
|
* up getting placed where the bss needs to go.
|
|
|
|
*/
|
powerpc: do not make the entire heap executable
On 32-bit powerpc the ELF PLT sections of binaries (built with
--bss-plt, or with a toolchain which defaults to it) look like this:
[17] .sbss NOBITS 0002aff8 01aff8 000014 00 WA 0 0 4
[18] .plt NOBITS 0002b00c 01aff8 000084 00 WAX 0 0 4
[19] .bss NOBITS 0002b090 01aff8 0000a4 00 WA 0 0 4
Which results in an ELF load header:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x019c70 0x00029c70 0x00029c70 0x01388 0x014c4 RWE 0x10000
This is all correct, the load region containing the PLT is marked as
executable. Note that the PLT starts at 0002b00c but the file mapping
ends at 0002aff8, so the PLT falls in the 0 fill section described by
the load header, and after a page boundary.
Unfortunately the generic ELF loader ignores the X bit in the load
headers when it creates the 0 filled non-file backed mappings. It
assumes all of these mappings are RW BSS sections, which is not the case
for PPC.
gcc/ld has an option (--secure-plt) to not do this, this is said to
incur a small performance penalty.
Currently, to support 32-bit binaries with PLT in BSS kernel maps
*entire brk area* with executable rights for all binaries, even
--secure-plt ones.
Stop doing that.
Teach the ELF loader to check the X bit in the relevant load header and
create 0 filled anonymous mappings that are executable if the load
header requests that.
Test program showing the difference in /proc/$PID/maps:
int main() {
char buf[16*1024];
char *p = malloc(123); /* make "[heap]" mapping appear */
int fd = open("/proc/self/maps", O_RDONLY);
int len = read(fd, buf, sizeof(buf));
write(1, buf, len);
printf("%p\n", p);
return 0;
}
Compiled using: gcc -mbss-plt -m32 -Os test.c -otest
Unpatched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10690000-106c0000 rwxp 00000000 00:00 0 [heap]
f7f70000-f7fa0000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fa0000-f7fb0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7fb0000-f7fc0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ffa90000-ffac0000 rw-p 00000000 00:00 0 [stack]
0x10690008
Patched ppc64 kernel:
00100000-00120000 r-xp 00000000 00:00 0 [vdso]
0fe10000-0ffd0000 r-xp 00000000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffd0000-0ffe0000 r--p 001b0000 fd:00 67898094 /usr/lib/libc-2.17.so
0ffe0000-0fff0000 rw-p 001c0000 fd:00 67898094 /usr/lib/libc-2.17.so
10000000-10010000 r-xp 00000000 fd:00 100674505 /home/user/test
10010000-10020000 r--p 00000000 fd:00 100674505 /home/user/test
10020000-10030000 rw-p 00010000 fd:00 100674505 /home/user/test
10180000-101b0000 rw-p 00000000 00:00 0 [heap]
^^^^ this has changed
f7c60000-f7c90000 r-xp 00000000 fd:00 67898089 /usr/lib/ld-2.17.so
f7c90000-f7ca0000 r--p 00020000 fd:00 67898089 /usr/lib/ld-2.17.so
f7ca0000-f7cb0000 rw-p 00030000 fd:00 67898089 /usr/lib/ld-2.17.so
ff860000-ff890000 rw-p 00000000 00:00 0 [stack]
0x10180008
The patch was originally posted in 2012 by Jason Gunthorpe
and apparently ignored:
https://lkml.org/lkml/2012/9/30/138
Lightly run-tested.
Link: http://lkml.kernel.org/r/20161215131950.23054-1-dvlasenk@redhat.com
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-22 23:45:16 +00:00
|
|
|
retval = set_brk(elf_bss, elf_brk, bss_prot);
|
2014-05-05 00:11:36 +00:00
|
|
|
if (retval)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out_free_dentry;
|
2005-10-11 15:29:08 +00:00
|
|
|
if (likely(elf_bss != elf_brk) && unlikely(padzero(elf_bss))) {
|
2005-04-16 22:20:36 +00:00
|
|
|
retval = -EFAULT; /* Nobody gets to see this, but.. */
|
|
|
|
goto out_free_dentry;
|
|
|
|
}
|
|
|
|
|
2019-05-14 22:43:39 +00:00
|
|
|
if (interpreter) {
|
2020-04-07 03:11:26 +00:00
|
|
|
elf_entry = load_elf_interp(interp_elf_ex,
|
2008-02-08 12:21:54 +00:00
|
|
|
interpreter,
|
2020-03-16 16:50:46 +00:00
|
|
|
load_bias, interp_elf_phdata,
|
|
|
|
&arch_state);
|
2022-11-15 03:17:57 +00:00
|
|
|
if (!IS_ERR_VALUE(elf_entry)) {
|
2008-02-08 12:21:54 +00:00
|
|
|
/*
|
|
|
|
* load_elf_interp() returns relocation
|
|
|
|
* adjustment
|
|
|
|
*/
|
|
|
|
interp_load_addr = elf_entry;
|
2020-04-07 03:11:26 +00:00
|
|
|
elf_entry += interp_elf_ex->e_entry;
|
2008-01-30 12:31:07 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
if (BAD_ADDR(elf_entry)) {
|
2022-11-15 03:17:57 +00:00
|
|
|
retval = IS_ERR_VALUE(elf_entry) ?
|
[PATCH] binfmt_elf: fix checks for bad address
Fix check for bad address; use macro instead of open-coding two checks.
Taken from RHEL4 kernel update.
From: Ernie Petrides <petrides@redhat.com>
For background, the BAD_ADDR() macro should return TRUE if the address is
TASK_SIZE, because that's the lowest address that is *not* valid for
user-space mappings. The macro was correct in binfmt_aout.c but was wrong
for the "equal to" case in binfmt_elf.c. There were two in-line validations
of user-space addresses in binfmt_elf.c, which have been appropriately
converted to use the corrected BAD_ADDR() macro in the patch you posted
yesterday. Note that the size checks against TASK_SIZE are okay as coded.
The additional changes that I propose are below. These are in the error
paths for bad ELF entry addresses once load_elf_binary() has already
committed to exec'ing the new image (following the tearing down of the
task's original address space).
The 1st hunk deals with the interp-side of the outer "if". There were two
problems here. The printk() should be removed because this path can be
triggered at will by a bogus interpreter image created and used by a
malicious user. Further, the error code should not be ENOEXEC, because that
causes the loop in search_binary_handler() to continue trying other exec
handlers (twice, in fact). But it's too late for this to work correctly,
because the user address space has already been torn down, and an exec()
failure cannot be returned to the user code because the code no longer
exists. The only recovery is to force a SIGSEGV, but it's best to terminate
the search loop immediately. I somewhat arbitrarily chose EINVAL as a
fallback error code, but any error returned by load_elf_interp() will
override that (but this value will never be seen by user-space).
The 2nd hunk deals with the non-interp-side of the outer "if". There were
two problems here as well. The SIGSEGV needs to be forced, because a prior
sigaction() syscall might have set the associated disposition to SIG_IGN.
And the ENOEXEC should be changed to EINVAL as described above.
Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Ernie Petrides <petrides@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-03 07:24:14 +00:00
|
|
|
(int)elf_entry : -EINVAL;
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out_free_dentry;
|
|
|
|
}
|
|
|
|
reloc_func_desc = interp_load_addr;
|
|
|
|
|
|
|
|
allow_write_access(interpreter);
|
|
|
|
fput(interpreter);
|
2020-04-07 03:11:29 +00:00
|
|
|
|
|
|
|
kfree(interp_elf_ex);
|
2020-04-07 03:11:32 +00:00
|
|
|
kfree(interp_elf_phdata);
|
2005-04-16 22:20:36 +00:00
|
|
|
} else {
|
2020-01-31 06:16:55 +00:00
|
|
|
elf_entry = e_entry;
|
2006-02-26 03:18:28 +00:00
|
|
|
if (BAD_ADDR(elf_entry)) {
|
[PATCH] binfmt_elf: fix checks for bad address
Fix check for bad address; use macro instead of open-coding two checks.
Taken from RHEL4 kernel update.
From: Ernie Petrides <petrides@redhat.com>
For background, the BAD_ADDR() macro should return TRUE if the address is
TASK_SIZE, because that's the lowest address that is *not* valid for
user-space mappings. The macro was correct in binfmt_aout.c but was wrong
for the "equal to" case in binfmt_elf.c. There were two in-line validations
of user-space addresses in binfmt_elf.c, which have been appropriately
converted to use the corrected BAD_ADDR() macro in the patch you posted
yesterday. Note that the size checks against TASK_SIZE are okay as coded.
The additional changes that I propose are below. These are in the error
paths for bad ELF entry addresses once load_elf_binary() has already
committed to exec'ing the new image (following the tearing down of the
task's original address space).
The 1st hunk deals with the interp-side of the outer "if". There were two
problems here. The printk() should be removed because this path can be
triggered at will by a bogus interpreter image created and used by a
malicious user. Further, the error code should not be ENOEXEC, because that
causes the loop in search_binary_handler() to continue trying other exec
handlers (twice, in fact). But it's too late for this to work correctly,
because the user address space has already been torn down, and an exec()
failure cannot be returned to the user code because the code no longer
exists. The only recovery is to force a SIGSEGV, but it's best to terminate
the search loop immediately. I somewhat arbitrarily chose EINVAL as a
fallback error code, but any error returned by load_elf_interp() will
override that (but this value will never be seen by user-space).
The 2nd hunk deals with the non-interp-side of the outer "if". There were
two problems here as well. The SIGSEGV needs to be forced, because a prior
sigaction() syscall might have set the associated disposition to SIG_IGN.
And the ENOEXEC should be changed to EINVAL as described above.
Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Ernie Petrides <petrides@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-03 07:24:14 +00:00
|
|
|
retval = -EINVAL;
|
2006-02-26 03:18:28 +00:00
|
|
|
goto out_free_dentry;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
kfree(elf_phdata);
|
|
|
|
|
|
|
|
set_binfmt(&elf_format);
|
|
|
|
|
2005-04-16 22:24:35 +00:00
|
|
|
#ifdef ARCH_HAS_SETUP_ADDITIONAL_PAGES
|
2020-10-04 03:25:33 +00:00
|
|
|
retval = ARCH_SETUP_ADDITIONAL_PAGES(bprm, elf_ex, !!interpreter);
|
2014-05-05 00:11:36 +00:00
|
|
|
if (retval < 0)
|
2005-04-28 22:17:19 +00:00
|
|
|
goto out;
|
2005-04-16 22:24:35 +00:00
|
|
|
#endif /* ARCH_HAS_SETUP_ADDITIONAL_PAGES */
|
|
|
|
|
2022-01-27 12:40:16 +00:00
|
|
|
retval = create_elf_tables(bprm, elf_ex, interp_load_addr,
|
|
|
|
e_entry, phdr_addr);
|
2014-05-05 00:11:36 +00:00
|
|
|
if (retval < 0)
|
2007-07-19 08:48:16 +00:00
|
|
|
goto out;
|
2020-01-31 06:16:58 +00:00
|
|
|
|
|
|
|
mm = current->mm;
|
|
|
|
mm->end_code = end_code;
|
|
|
|
mm->start_code = start_code;
|
|
|
|
mm->start_data = start_data;
|
|
|
|
mm->end_data = end_data;
|
|
|
|
mm->start_stack = bprm->p;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-04-14 22:22:09 +00:00
|
|
|
if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1)) {
|
2019-05-14 22:43:57 +00:00
|
|
|
/*
|
|
|
|
* For architectures with ELF randomization, when executing
|
|
|
|
* a loader directly (i.e. no interpreter listed in ELF
|
|
|
|
* headers), move the brk area out of the mmap region
|
|
|
|
* (since it grows up, and may collide early with the stack
|
|
|
|
* growing down), and into the unused ELF_ET_DYN_BASE region.
|
|
|
|
*/
|
2019-09-26 17:15:25 +00:00
|
|
|
if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) &&
|
2020-01-31 06:16:58 +00:00
|
|
|
elf_ex->e_type == ET_DYN && !interpreter) {
|
|
|
|
mm->brk = mm->start_brk = ELF_ET_DYN_BASE;
|
|
|
|
}
|
2019-05-14 22:43:57 +00:00
|
|
|
|
2020-01-31 06:16:58 +00:00
|
|
|
mm->brk = mm->start_brk = arch_randomize_brk(mm);
|
2015-04-14 22:48:12 +00:00
|
|
|
#ifdef compat_brk_randomized
|
2011-04-14 22:22:09 +00:00
|
|
|
current->brk_randomized = 1;
|
|
|
|
#endif
|
|
|
|
}
|
2008-01-30 12:30:40 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (current->personality & MMAP_PAGE_ZERO) {
|
|
|
|
/* Why this, you ask??? Well SVr4 maps page 0 as read-only,
|
|
|
|
and some applications "depend" upon this behavior.
|
|
|
|
Since we do not have the power to recompile these, we
|
2006-06-23 09:05:35 +00:00
|
|
|
emulate the SVr4 behavior. Sigh. */
|
2012-04-21 00:13:58 +00:00
|
|
|
error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC,
|
2005-04-16 22:20:36 +00:00
|
|
|
MAP_FIXED | MAP_PRIVATE, 0);
|
|
|
|
}
|
|
|
|
|
2019-05-14 22:43:54 +00:00
|
|
|
regs = current_pt_regs();
|
2005-04-16 22:20:36 +00:00
|
|
|
#ifdef ELF_PLAT_INIT
|
|
|
|
/*
|
|
|
|
* The ABI may specify that certain registers be set up in special
|
|
|
|
* ways (on i386 %edx is the address of a DT_FINI function, for
|
|
|
|
* example. In addition, it may also specify (eg, PowerPC64 ELF)
|
|
|
|
* that the e_entry field is the address of the function descriptor
|
|
|
|
* for the startup routine, rather than the address of the startup
|
|
|
|
* routine itself. This macro performs whatever initialization to
|
|
|
|
* the regs structure is required as well as any relocations to the
|
|
|
|
* function descriptor entries when executing dynamically links apps.
|
|
|
|
*/
|
|
|
|
ELF_PLAT_INIT(regs, reloc_func_desc);
|
|
|
|
#endif
|
|
|
|
|
2018-04-10 23:34:57 +00:00
|
|
|
finalize_exec(bprm);
|
2020-10-04 03:25:31 +00:00
|
|
|
START_THREAD(elf_ex, regs, elf_entry, bprm->p);
|
2005-04-16 22:20:36 +00:00
|
|
|
retval = 0;
|
|
|
|
out:
|
|
|
|
return retval;
|
|
|
|
|
|
|
|
/* error cleanup */
|
|
|
|
out_free_dentry:
|
2020-04-07 03:11:29 +00:00
|
|
|
kfree(interp_elf_ex);
|
2014-09-11 07:30:15 +00:00
|
|
|
kfree(interp_elf_phdata);
|
2022-10-24 15:44:21 +00:00
|
|
|
out_free_file:
|
2005-04-16 22:20:36 +00:00
|
|
|
allow_write_access(interpreter);
|
|
|
|
if (interpreter)
|
|
|
|
fput(interpreter);
|
|
|
|
out_free_ph:
|
|
|
|
kfree(elf_phdata);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2014-04-03 21:48:27 +00:00
|
|
|
#ifdef CONFIG_USELIB
|
2005-04-16 22:20:36 +00:00
|
|
|
/* This is really simpleminded and specialized - we are loading an
|
|
|
|
a.out library that is given an ELF header. */
|
|
|
|
static int load_elf_library(struct file *file)
|
|
|
|
{
|
|
|
|
struct elf_phdr *elf_phdata;
|
|
|
|
struct elf_phdr *eppnt;
|
|
|
|
unsigned long elf_bss, bss, len;
|
|
|
|
int retval, error, i, j;
|
|
|
|
struct elfhdr elf_ex;
|
|
|
|
|
|
|
|
error = -ENOEXEC;
|
2019-12-05 00:52:25 +00:00
|
|
|
retval = elf_read(file, &elf_ex, sizeof(elf_ex), 0);
|
|
|
|
if (retval < 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (memcmp(elf_ex.e_ident, ELFMAG, SELFMAG) != 0)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* First of all, some simple consistency checks */
|
|
|
|
if (elf_ex.e_type != ET_EXEC || elf_ex.e_phnum > 2 ||
|
2013-09-22 20:27:52 +00:00
|
|
|
!elf_check_arch(&elf_ex) || !file->f_op->mmap)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out;
|
2017-08-16 20:05:13 +00:00
|
|
|
if (elf_check_fdpic(&elf_ex))
|
|
|
|
goto out;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Now read in all of the header information */
|
|
|
|
|
|
|
|
j = sizeof(struct elf_phdr) * elf_ex.e_phnum;
|
|
|
|
/* j < ELF_MIN_ALIGN because elf_ex.e_phnum <= 2 */
|
|
|
|
|
|
|
|
error = -ENOMEM;
|
|
|
|
elf_phdata = kmalloc(j, GFP_KERNEL);
|
|
|
|
if (!elf_phdata)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
eppnt = elf_phdata;
|
|
|
|
error = -ENOEXEC;
|
2019-12-05 00:52:25 +00:00
|
|
|
retval = elf_read(file, eppnt, j, elf_ex.e_phoff);
|
|
|
|
if (retval < 0)
|
2005-04-16 22:20:36 +00:00
|
|
|
goto out_free_ph;
|
|
|
|
|
|
|
|
for (j = 0, i = 0; i<elf_ex.e_phnum; i++)
|
|
|
|
if ((eppnt + i)->p_type == PT_LOAD)
|
|
|
|
j++;
|
|
|
|
if (j != 1)
|
|
|
|
goto out_free_ph;
|
|
|
|
|
|
|
|
while (eppnt->p_type != PT_LOAD)
|
|
|
|
eppnt++;
|
|
|
|
|
|
|
|
/* Now use mmap to map the library into memory. */
|
2012-04-21 00:13:58 +00:00
|
|
|
error = vm_mmap(file,
|
2005-04-16 22:20:36 +00:00
|
|
|
ELF_PAGESTART(eppnt->p_vaddr),
|
|
|
|
(eppnt->p_filesz +
|
|
|
|
ELF_PAGEOFFSET(eppnt->p_vaddr)),
|
|
|
|
PROT_READ | PROT_WRITE | PROT_EXEC,
|
2021-04-22 10:53:00 +00:00
|
|
|
MAP_FIXED_NOREPLACE | MAP_PRIVATE,
|
2005-04-16 22:20:36 +00:00
|
|
|
(eppnt->p_offset -
|
|
|
|
ELF_PAGEOFFSET(eppnt->p_vaddr)));
|
|
|
|
if (error != ELF_PAGESTART(eppnt->p_vaddr))
|
|
|
|
goto out_free_ph;
|
|
|
|
|
|
|
|
elf_bss = eppnt->p_vaddr + eppnt->p_filesz;
|
|
|
|
if (padzero(elf_bss)) {
|
|
|
|
error = -EFAULT;
|
|
|
|
goto out_free_ph;
|
|
|
|
}
|
|
|
|
|
2018-07-13 23:59:13 +00:00
|
|
|
len = ELF_PAGEALIGN(eppnt->p_filesz + eppnt->p_vaddr);
|
|
|
|
bss = ELF_PAGEALIGN(eppnt->p_memsz + eppnt->p_vaddr);
|
2016-05-23 23:25:39 +00:00
|
|
|
if (bss > len) {
|
|
|
|
error = vm_brk(len, bss - len);
|
2016-05-27 22:57:31 +00:00
|
|
|
if (error)
|
2016-05-23 23:25:39 +00:00
|
|
|
goto out_free_ph;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
error = 0;
|
|
|
|
|
|
|
|
out_free_ph:
|
|
|
|
kfree(elf_phdata);
|
|
|
|
out:
|
|
|
|
return error;
|
|
|
|
}
|
2014-04-03 21:48:27 +00:00
|
|
|
#endif /* #ifdef CONFIG_USELIB */
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-12-16 00:47:37 +00:00
|
|
|
#ifdef CONFIG_ELF_CORE
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* ELF core dumper
|
|
|
|
*
|
|
|
|
* Modelled on fs/exec.c:aout_core_dump()
|
|
|
|
* Jeremy Fitzhardinge <jeremy@sw.oz.au>
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* An ELF note in memory */
|
|
|
|
struct memelfnote
|
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
int type;
|
|
|
|
unsigned int datasz;
|
|
|
|
void *data;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int notesize(struct memelfnote *en)
|
|
|
|
{
|
|
|
|
int sz;
|
|
|
|
|
|
|
|
sz = sizeof(struct elf_note);
|
|
|
|
sz += roundup(strlen(en->name) + 1, 4);
|
|
|
|
sz += roundup(en->datasz, 4);
|
|
|
|
|
|
|
|
return sz;
|
|
|
|
}
|
|
|
|
|
2013-10-05 19:32:35 +00:00
|
|
|
static int writenote(struct memelfnote *men, struct coredump_params *cprm)
|
2006-10-01 06:29:28 +00:00
|
|
|
{
|
|
|
|
struct elf_note en;
|
2005-04-16 22:20:36 +00:00
|
|
|
en.n_namesz = strlen(men->name) + 1;
|
|
|
|
en.n_descsz = men->datasz;
|
|
|
|
en.n_type = men->type;
|
|
|
|
|
2013-10-05 19:32:35 +00:00
|
|
|
return dump_emit(cprm, &en, sizeof(en)) &&
|
2013-10-08 15:05:01 +00:00
|
|
|
dump_emit(cprm, men->name, en.n_namesz) && dump_align(cprm, 4) &&
|
|
|
|
dump_emit(cprm, men->data, men->datasz) && dump_align(cprm, 4);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2008-01-30 12:31:44 +00:00
|
|
|
static void fill_elf_header(struct elfhdr *elf, int segs,
|
2013-02-22 00:44:20 +00:00
|
|
|
u16 machine, u32 flags)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-04-29 08:01:18 +00:00
|
|
|
memset(elf, 0, sizeof(*elf));
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
memcpy(elf->e_ident, ELFMAG, SELFMAG);
|
|
|
|
elf->e_ident[EI_CLASS] = ELF_CLASS;
|
|
|
|
elf->e_ident[EI_DATA] = ELF_DATA;
|
|
|
|
elf->e_ident[EI_VERSION] = EV_CURRENT;
|
|
|
|
elf->e_ident[EI_OSABI] = ELF_OSABI;
|
|
|
|
|
|
|
|
elf->e_type = ET_CORE;
|
2008-01-30 12:31:44 +00:00
|
|
|
elf->e_machine = machine;
|
2005-04-16 22:20:36 +00:00
|
|
|
elf->e_version = EV_CURRENT;
|
|
|
|
elf->e_phoff = sizeof(struct elfhdr);
|
2008-01-30 12:31:44 +00:00
|
|
|
elf->e_flags = flags;
|
2005-04-16 22:20:36 +00:00
|
|
|
elf->e_ehsize = sizeof(struct elfhdr);
|
|
|
|
elf->e_phentsize = sizeof(struct elf_phdr);
|
|
|
|
elf->e_phnum = segs;
|
|
|
|
}
|
|
|
|
|
2006-09-26 06:32:04 +00:00
|
|
|
static void fill_elf_note_phdr(struct elf_phdr *phdr, int sz, loff_t offset)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
phdr->p_type = PT_NOTE;
|
|
|
|
phdr->p_offset = offset;
|
|
|
|
phdr->p_vaddr = 0;
|
|
|
|
phdr->p_paddr = 0;
|
|
|
|
phdr->p_filesz = sz;
|
|
|
|
phdr->p_memsz = 0;
|
|
|
|
phdr->p_flags = 0;
|
|
|
|
phdr->p_align = 0;
|
|
|
|
}
|
|
|
|
|
2022-10-18 07:14:20 +00:00
|
|
|
static void fill_note(struct memelfnote *note, const char *name, int type,
|
2005-04-16 22:20:36 +00:00
|
|
|
unsigned int sz, void *data)
|
|
|
|
{
|
|
|
|
note->name = name;
|
|
|
|
note->type = type;
|
|
|
|
note->datasz = sz;
|
|
|
|
note->data = data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2006-06-23 09:05:35 +00:00
|
|
|
* fill up all the fields in prstatus from the given task struct, except
|
|
|
|
* registers which need to be filled up separately.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2020-06-13 04:08:44 +00:00
|
|
|
static void fill_prstatus(struct elf_prstatus_common *prstatus,
|
2006-06-23 09:05:35 +00:00
|
|
|
struct task_struct *p, long signr)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
prstatus->pr_info.si_signo = prstatus->pr_cursig = signr;
|
|
|
|
prstatus->pr_sigpend = p->pending.signal.sig[0];
|
|
|
|
prstatus->pr_sighold = p->blocked.sig[0];
|
2009-06-17 23:27:38 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
prstatus->pr_ppid = task_pid_vnr(rcu_dereference(p->real_parent));
|
|
|
|
rcu_read_unlock();
|
2007-10-19 06:40:14 +00:00
|
|
|
prstatus->pr_pid = task_pid_vnr(p);
|
|
|
|
prstatus->pr_pgrp = task_pgrp_vnr(p);
|
|
|
|
prstatus->pr_sid = task_session_vnr(p);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (thread_group_leader(p)) {
|
2017-01-31 03:09:27 +00:00
|
|
|
struct task_cputime cputime;
|
timers: fix itimer/many thread hang
Overview
This patch reworks the handling of POSIX CPU timers, including the
ITIMER_PROF, ITIMER_VIRT timers and rlimit handling. It was put together
with the help of Roland McGrath, the owner and original writer of this code.
The problem we ran into, and the reason for this rework, has to do with using
a profiling timer in a process with a large number of threads. It appears
that the performance of the old implementation of run_posix_cpu_timers() was
at least O(n*3) (where "n" is the number of threads in a process) or worse.
Everything is fine with an increasing number of threads until the time taken
for that routine to run becomes the same as or greater than the tick time, at
which point things degrade rather quickly.
This patch fixes bug 9906, "Weird hang with NPTL and SIGPROF."
Code Changes
This rework corrects the implementation of run_posix_cpu_timers() to make it
run in constant time for a particular machine. (Performance may vary between
one machine and another depending upon whether the kernel is built as single-
or multiprocessor and, in the latter case, depending upon the number of
running processors.) To do this, at each tick we now update fields in
signal_struct as well as task_struct. The run_posix_cpu_timers() function
uses those fields to make its decisions.
We define a new structure, "task_cputime," to contain user, system and
scheduler times and use these in appropriate places:
struct task_cputime {
cputime_t utime;
cputime_t stime;
unsigned long long sum_exec_runtime;
};
This is included in the structure "thread_group_cputime," which is a new
substructure of signal_struct and which varies for uniprocessor versus
multiprocessor kernels. For uniprocessor kernels, it uses "task_cputime" as
a simple substructure, while for multiprocessor kernels it is a pointer:
struct thread_group_cputime {
struct task_cputime totals;
};
struct thread_group_cputime {
struct task_cputime *totals;
};
We also add a new task_cputime substructure directly to signal_struct, to
cache the earliest expiration of process-wide timers, and task_cputime also
replaces the it_*_expires fields of task_struct (used for earliest expiration
of thread timers). The "thread_group_cputime" structure contains process-wide
timers that are updated via account_user_time() and friends. In the non-SMP
case the structure is a simple aggregator; unfortunately in the SMP case that
simplicity was not achievable due to cache-line contention between CPUs (in
one measured case performance was actually _worse_ on a 16-cpu system than
the same test on a 4-cpu system, due to this contention). For SMP, the
thread_group_cputime counters are maintained as a per-cpu structure allocated
using alloc_percpu(). The timer functions update only the timer field in
the structure corresponding to the running CPU, obtained using per_cpu_ptr().
We define a set of inline functions in sched.h that we use to maintain the
thread_group_cputime structure and hide the differences between UP and SMP
implementations from the rest of the kernel. The thread_group_cputime_init()
function initializes the thread_group_cputime structure for the given task.
The thread_group_cputime_alloc() is a no-op for UP; for SMP it calls the
out-of-line function thread_group_cputime_alloc_smp() to allocate and fill
in the per-cpu structures and fields. The thread_group_cputime_free()
function, also a no-op for UP, in SMP frees the per-cpu structures. The
thread_group_cputime_clone_thread() function (also a UP no-op) for SMP calls
thread_group_cputime_alloc() if the per-cpu structures haven't yet been
allocated. The thread_group_cputime() function fills the task_cputime
structure it is passed with the contents of the thread_group_cputime fields;
in UP it's that simple but in SMP it must also safely check that tsk->signal
is non-NULL (if it is it just uses the appropriate fields of task_struct) and,
if so, sums the per-cpu values for each online CPU. Finally, the three
functions account_group_user_time(), account_group_system_time() and
account_group_exec_runtime() are used by timer functions to update the
respective fields of the thread_group_cputime structure.
Non-SMP operation is trivial and will not be mentioned further.
The per-cpu structure is always allocated when a task creates its first new
thread, via a call to thread_group_cputime_clone_thread() from copy_signal().
It is freed at process exit via a call to thread_group_cputime_free() from
cleanup_signal().
All functions that formerly summed utime/stime/sum_sched_runtime values from
from all threads in the thread group now use thread_group_cputime() to
snapshot the values in the thread_group_cputime structure or the values in
the task structure itself if the per-cpu structure hasn't been allocated.
Finally, the code in kernel/posix-cpu-timers.c has changed quite a bit.
The run_posix_cpu_timers() function has been split into a fast path and a
slow path; the former safely checks whether there are any expired thread
timers and, if not, just returns, while the slow path does the heavy lifting.
With the dedicated thread group fields, timers are no longer "rebalanced" and
the process_timer_rebalance() function and related code has gone away. All
summing loops are gone and all code that used them now uses the
thread_group_cputime() inline. When process-wide timers are set, the new
task_cputime structure in signal_struct is used to cache the earliest
expiration; this is checked in the fast path.
Performance
The fix appears not to add significant overhead to existing operations. It
generally performs the same as the current code except in two cases, one in
which it performs slightly worse (Case 5 below) and one in which it performs
very significantly better (Case 2 below). Overall it's a wash except in those
two cases.
I've since done somewhat more involved testing on a dual-core Opteron system.
Case 1: With no itimer running, for a test with 100,000 threads, the fixed
kernel took 1428.5 seconds, 513 seconds more than the unfixed system,
all of which was spent in the system. There were twice as many
voluntary context switches with the fix as without it.
Case 2: With an itimer running at .01 second ticks and 4000 threads (the most
an unmodified kernel can handle), the fixed kernel ran the test in
eight percent of the time (5.8 seconds as opposed to 70 seconds) and
had better tick accuracy (.012 seconds per tick as opposed to .023
seconds per tick).
Case 3: A 4000-thread test with an initial timer tick of .01 second and an
interval of 10,000 seconds (i.e. a timer that ticks only once) had
very nearly the same performance in both cases: 6.3 seconds elapsed
for the fixed kernel versus 5.5 seconds for the unfixed kernel.
With fewer threads (eight in these tests), the Case 1 test ran in essentially
the same time on both the modified and unmodified kernels (5.2 seconds versus
5.8 seconds). The Case 2 test ran in about the same time as well, 5.9 seconds
versus 5.4 seconds but again with much better tick accuracy, .013 seconds per
tick versus .025 seconds per tick for the unmodified kernel.
Since the fix affected the rlimit code, I also tested soft and hard CPU limits.
Case 4: With a hard CPU limit of 20 seconds and eight threads (and an itimer
running), the modified kernel was very slightly favored in that while
it killed the process in 19.997 seconds of CPU time (5.002 seconds of
wall time), only .003 seconds of that was system time, the rest was
user time. The unmodified kernel killed the process in 20.001 seconds
of CPU (5.014 seconds of wall time) of which .016 seconds was system
time. Really, though, the results were too close to call. The results
were essentially the same with no itimer running.
Case 5: With a soft limit of 20 seconds and a hard limit of 2000 seconds
(where the hard limit would never be reached) and an itimer running,
the modified kernel exhibited worse tick accuracy than the unmodified
kernel: .050 seconds/tick versus .028 seconds/tick. Otherwise,
performance was almost indistinguishable. With no itimer running this
test exhibited virtually identical behavior and times in both cases.
In times past I did some limited performance testing. those results are below.
On a four-cpu Opteron system without this fix, a sixteen-thread test executed
in 3569.991 seconds, of which user was 3568.435s and system was 1.556s. On
the same system with the fix, user and elapsed time were about the same, but
system time dropped to 0.007 seconds. Performance with eight, four and one
thread were comparable. Interestingly, the timer ticks with the fix seemed
more accurate: The sixteen-thread test with the fix received 149543 ticks
for 0.024 seconds per tick, while the same test without the fix received 58720
for 0.061 seconds per tick. Both cases were configured for an interval of
0.01 seconds. Again, the other tests were comparable. Each thread in this
test computed the primes up to 25,000,000.
I also did a test with a large number of threads, 100,000 threads, which is
impossible without the fix. In this case each thread computed the primes only
up to 10,000 (to make the runtime manageable). System time dominated, at
1546.968 seconds out of a total 2176.906 seconds (giving a user time of
629.938s). It received 147651 ticks for 0.015 seconds per tick, still quite
accurate. There is obviously no comparable test without the fix.
Signed-off-by: Frank Mayhar <fmayhar@google.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-12 16:54:39 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
timers: fix itimer/many thread hang
Overview
This patch reworks the handling of POSIX CPU timers, including the
ITIMER_PROF, ITIMER_VIRT timers and rlimit handling. It was put together
with the help of Roland McGrath, the owner and original writer of this code.
The problem we ran into, and the reason for this rework, has to do with using
a profiling timer in a process with a large number of threads. It appears
that the performance of the old implementation of run_posix_cpu_timers() was
at least O(n*3) (where "n" is the number of threads in a process) or worse.
Everything is fine with an increasing number of threads until the time taken
for that routine to run becomes the same as or greater than the tick time, at
which point things degrade rather quickly.
This patch fixes bug 9906, "Weird hang with NPTL and SIGPROF."
Code Changes
This rework corrects the implementation of run_posix_cpu_timers() to make it
run in constant time for a particular machine. (Performance may vary between
one machine and another depending upon whether the kernel is built as single-
or multiprocessor and, in the latter case, depending upon the number of
running processors.) To do this, at each tick we now update fields in
signal_struct as well as task_struct. The run_posix_cpu_timers() function
uses those fields to make its decisions.
We define a new structure, "task_cputime," to contain user, system and
scheduler times and use these in appropriate places:
struct task_cputime {
cputime_t utime;
cputime_t stime;
unsigned long long sum_exec_runtime;
};
This is included in the structure "thread_group_cputime," which is a new
substructure of signal_struct and which varies for uniprocessor versus
multiprocessor kernels. For uniprocessor kernels, it uses "task_cputime" as
a simple substructure, while for multiprocessor kernels it is a pointer:
struct thread_group_cputime {
struct task_cputime totals;
};
struct thread_group_cputime {
struct task_cputime *totals;
};
We also add a new task_cputime substructure directly to signal_struct, to
cache the earliest expiration of process-wide timers, and task_cputime also
replaces the it_*_expires fields of task_struct (used for earliest expiration
of thread timers). The "thread_group_cputime" structure contains process-wide
timers that are updated via account_user_time() and friends. In the non-SMP
case the structure is a simple aggregator; unfortunately in the SMP case that
simplicity was not achievable due to cache-line contention between CPUs (in
one measured case performance was actually _worse_ on a 16-cpu system than
the same test on a 4-cpu system, due to this contention). For SMP, the
thread_group_cputime counters are maintained as a per-cpu structure allocated
using alloc_percpu(). The timer functions update only the timer field in
the structure corresponding to the running CPU, obtained using per_cpu_ptr().
We define a set of inline functions in sched.h that we use to maintain the
thread_group_cputime structure and hide the differences between UP and SMP
implementations from the rest of the kernel. The thread_group_cputime_init()
function initializes the thread_group_cputime structure for the given task.
The thread_group_cputime_alloc() is a no-op for UP; for SMP it calls the
out-of-line function thread_group_cputime_alloc_smp() to allocate and fill
in the per-cpu structures and fields. The thread_group_cputime_free()
function, also a no-op for UP, in SMP frees the per-cpu structures. The
thread_group_cputime_clone_thread() function (also a UP no-op) for SMP calls
thread_group_cputime_alloc() if the per-cpu structures haven't yet been
allocated. The thread_group_cputime() function fills the task_cputime
structure it is passed with the contents of the thread_group_cputime fields;
in UP it's that simple but in SMP it must also safely check that tsk->signal
is non-NULL (if it is it just uses the appropriate fields of task_struct) and,
if so, sums the per-cpu values for each online CPU. Finally, the three
functions account_group_user_time(), account_group_system_time() and
account_group_exec_runtime() are used by timer functions to update the
respective fields of the thread_group_cputime structure.
Non-SMP operation is trivial and will not be mentioned further.
The per-cpu structure is always allocated when a task creates its first new
thread, via a call to thread_group_cputime_clone_thread() from copy_signal().
It is freed at process exit via a call to thread_group_cputime_free() from
cleanup_signal().
All functions that formerly summed utime/stime/sum_sched_runtime values from
from all threads in the thread group now use thread_group_cputime() to
snapshot the values in the thread_group_cputime structure or the values in
the task structure itself if the per-cpu structure hasn't been allocated.
Finally, the code in kernel/posix-cpu-timers.c has changed quite a bit.
The run_posix_cpu_timers() function has been split into a fast path and a
slow path; the former safely checks whether there are any expired thread
timers and, if not, just returns, while the slow path does the heavy lifting.
With the dedicated thread group fields, timers are no longer "rebalanced" and
the process_timer_rebalance() function and related code has gone away. All
summing loops are gone and all code that used them now uses the
thread_group_cputime() inline. When process-wide timers are set, the new
task_cputime structure in signal_struct is used to cache the earliest
expiration; this is checked in the fast path.
Performance
The fix appears not to add significant overhead to existing operations. It
generally performs the same as the current code except in two cases, one in
which it performs slightly worse (Case 5 below) and one in which it performs
very significantly better (Case 2 below). Overall it's a wash except in those
two cases.
I've since done somewhat more involved testing on a dual-core Opteron system.
Case 1: With no itimer running, for a test with 100,000 threads, the fixed
kernel took 1428.5 seconds, 513 seconds more than the unfixed system,
all of which was spent in the system. There were twice as many
voluntary context switches with the fix as without it.
Case 2: With an itimer running at .01 second ticks and 4000 threads (the most
an unmodified kernel can handle), the fixed kernel ran the test in
eight percent of the time (5.8 seconds as opposed to 70 seconds) and
had better tick accuracy (.012 seconds per tick as opposed to .023
seconds per tick).
Case 3: A 4000-thread test with an initial timer tick of .01 second and an
interval of 10,000 seconds (i.e. a timer that ticks only once) had
very nearly the same performance in both cases: 6.3 seconds elapsed
for the fixed kernel versus 5.5 seconds for the unfixed kernel.
With fewer threads (eight in these tests), the Case 1 test ran in essentially
the same time on both the modified and unmodified kernels (5.2 seconds versus
5.8 seconds). The Case 2 test ran in about the same time as well, 5.9 seconds
versus 5.4 seconds but again with much better tick accuracy, .013 seconds per
tick versus .025 seconds per tick for the unmodified kernel.
Since the fix affected the rlimit code, I also tested soft and hard CPU limits.
Case 4: With a hard CPU limit of 20 seconds and eight threads (and an itimer
running), the modified kernel was very slightly favored in that while
it killed the process in 19.997 seconds of CPU time (5.002 seconds of
wall time), only .003 seconds of that was system time, the rest was
user time. The unmodified kernel killed the process in 20.001 seconds
of CPU (5.014 seconds of wall time) of which .016 seconds was system
time. Really, though, the results were too close to call. The results
were essentially the same with no itimer running.
Case 5: With a soft limit of 20 seconds and a hard limit of 2000 seconds
(where the hard limit would never be reached) and an itimer running,
the modified kernel exhibited worse tick accuracy than the unmodified
kernel: .050 seconds/tick versus .028 seconds/tick. Otherwise,
performance was almost indistinguishable. With no itimer running this
test exhibited virtually identical behavior and times in both cases.
In times past I did some limited performance testing. those results are below.
On a four-cpu Opteron system without this fix, a sixteen-thread test executed
in 3569.991 seconds, of which user was 3568.435s and system was 1.556s. On
the same system with the fix, user and elapsed time were about the same, but
system time dropped to 0.007 seconds. Performance with eight, four and one
thread were comparable. Interestingly, the timer ticks with the fix seemed
more accurate: The sixteen-thread test with the fix received 149543 ticks
for 0.024 seconds per tick, while the same test without the fix received 58720
for 0.061 seconds per tick. Both cases were configured for an interval of
0.01 seconds. Again, the other tests were comparable. Each thread in this
test computed the primes up to 25,000,000.
I also did a test with a large number of threads, 100,000 threads, which is
impossible without the fix. In this case each thread computed the primes only
up to 10,000 (to make the runtime manageable). System time dominated, at
1546.968 seconds out of a total 2176.906 seconds (giving a user time of
629.938s). It received 147651 ticks for 0.015 seconds per tick, still quite
accurate. There is obviously no comparable test without the fix.
Signed-off-by: Frank Mayhar <fmayhar@google.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-12 16:54:39 +00:00
|
|
|
* This is the record for the group leader. It shows the
|
|
|
|
* group-wide total, not its individual thread total.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2017-01-31 03:09:27 +00:00
|
|
|
thread_group_cputime(p, &cputime);
|
2017-11-23 12:46:33 +00:00
|
|
|
prstatus->pr_utime = ns_to_kernel_old_timeval(cputime.utime);
|
|
|
|
prstatus->pr_stime = ns_to_kernel_old_timeval(cputime.stime);
|
2005-04-16 22:20:36 +00:00
|
|
|
} else {
|
2017-01-31 03:09:27 +00:00
|
|
|
u64 utime, stime;
|
2012-11-13 13:20:55 +00:00
|
|
|
|
2017-01-31 03:09:27 +00:00
|
|
|
task_cputime(p, &utime, &stime);
|
2017-11-23 12:46:33 +00:00
|
|
|
prstatus->pr_utime = ns_to_kernel_old_timeval(utime);
|
|
|
|
prstatus->pr_stime = ns_to_kernel_old_timeval(stime);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2017-01-31 03:09:23 +00:00
|
|
|
|
2017-11-23 12:46:33 +00:00
|
|
|
prstatus->pr_cutime = ns_to_kernel_old_timeval(p->signal->cutime);
|
|
|
|
prstatus->pr_cstime = ns_to_kernel_old_timeval(p->signal->cstime);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int fill_psinfo(struct elf_prpsinfo *psinfo, struct task_struct *p,
|
|
|
|
struct mm_struct *mm)
|
|
|
|
{
|
2008-11-13 23:39:19 +00:00
|
|
|
const struct cred *cred;
|
2005-05-11 07:10:44 +00:00
|
|
|
unsigned int i, len;
|
2021-06-11 08:28:17 +00:00
|
|
|
unsigned int state;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* first copy the parameters from user space */
|
|
|
|
memset(psinfo, 0, sizeof(struct elf_prpsinfo));
|
|
|
|
|
|
|
|
len = mm->arg_end - mm->arg_start;
|
|
|
|
if (len >= ELF_PRARGSZ)
|
|
|
|
len = ELF_PRARGSZ-1;
|
|
|
|
if (copy_from_user(&psinfo->pr_psargs,
|
|
|
|
(const char __user *)mm->arg_start, len))
|
|
|
|
return -EFAULT;
|
|
|
|
for(i = 0; i < len; i++)
|
|
|
|
if (psinfo->pr_psargs[i] == 0)
|
|
|
|
psinfo->pr_psargs[i] = ' ';
|
|
|
|
psinfo->pr_psargs[len] = 0;
|
|
|
|
|
2009-06-17 23:27:38 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
psinfo->pr_ppid = task_pid_vnr(rcu_dereference(p->real_parent));
|
|
|
|
rcu_read_unlock();
|
2007-10-19 06:40:14 +00:00
|
|
|
psinfo->pr_pid = task_pid_vnr(p);
|
|
|
|
psinfo->pr_pgrp = task_pgrp_vnr(p);
|
|
|
|
psinfo->pr_sid = task_session_vnr(p);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-06-11 08:28:17 +00:00
|
|
|
state = READ_ONCE(p->__state);
|
|
|
|
i = state ? ffz(~state) + 1 : 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
psinfo->pr_state = i;
|
2006-03-25 11:08:22 +00:00
|
|
|
psinfo->pr_sname = (i > 5) ? '.' : "RSDTZW"[i];
|
2005-04-16 22:20:36 +00:00
|
|
|
psinfo->pr_zomb = psinfo->pr_sname == 'Z';
|
|
|
|
psinfo->pr_nice = task_nice(p);
|
|
|
|
psinfo->pr_flag = p->flags;
|
2008-11-13 23:39:19 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
cred = __task_cred(p);
|
2012-02-08 02:36:10 +00:00
|
|
|
SET_UID(psinfo->pr_uid, from_kuid_munged(cred->user_ns, cred->uid));
|
|
|
|
SET_GID(psinfo->pr_gid, from_kgid_munged(cred->user_ns, cred->gid));
|
2008-11-13 23:39:19 +00:00
|
|
|
rcu_read_unlock();
|
2022-01-20 02:08:29 +00:00
|
|
|
get_task_comm(psinfo->pr_fname, p);
|
2021-06-11 08:28:17 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-01-30 12:31:44 +00:00
|
|
|
static void fill_auxv_note(struct memelfnote *note, struct mm_struct *mm)
|
|
|
|
{
|
|
|
|
elf_addr_t *auxv = (elf_addr_t *) mm->saved_auxv;
|
|
|
|
int i = 0;
|
|
|
|
do
|
|
|
|
i += 2;
|
|
|
|
while (auxv[i - 2] != AT_NULL);
|
|
|
|
fill_note(note, "CORE", NT_AUXV, i * sizeof(elf_addr_t), auxv);
|
|
|
|
}
|
|
|
|
|
2012-10-05 00:15:35 +00:00
|
|
|
static void fill_siginfo_note(struct memelfnote *note, user_siginfo_t *csigdata,
|
2018-09-25 09:27:20 +00:00
|
|
|
const kernel_siginfo_t *siginfo)
|
2012-10-05 00:15:35 +00:00
|
|
|
{
|
2020-05-05 10:12:54 +00:00
|
|
|
copy_siginfo_to_external(csigdata, siginfo);
|
2012-10-05 00:15:35 +00:00
|
|
|
fill_note(note, "CORE", NT_SIGINFO, sizeof(*csigdata), csigdata);
|
|
|
|
}
|
|
|
|
|
2012-10-05 00:15:36 +00:00
|
|
|
#define MAX_FILE_NOTE_SIZE (4*1024*1024)
|
|
|
|
/*
|
|
|
|
* Format of NT_FILE note:
|
|
|
|
*
|
|
|
|
* long count -- how many files are mapped
|
|
|
|
* long page_size -- units for file_ofs
|
|
|
|
* array of [COUNT] elements of
|
|
|
|
* long start
|
|
|
|
* long end
|
|
|
|
* long file_ofs
|
|
|
|
* followed by COUNT filenames in ASCII: "FILE1" NUL "FILE2" NUL...
|
|
|
|
*/
|
2022-03-08 19:04:19 +00:00
|
|
|
static int fill_files_note(struct memelfnote *note, struct coredump_params *cprm)
|
2012-10-05 00:15:36 +00:00
|
|
|
{
|
|
|
|
unsigned count, size, names_ofs, remaining, n;
|
|
|
|
user_long_t *data;
|
|
|
|
user_long_t *start_end_ofs;
|
|
|
|
char *name_base, *name_curpos;
|
2022-03-08 19:04:19 +00:00
|
|
|
int i;
|
2012-10-05 00:15:36 +00:00
|
|
|
|
|
|
|
/* *Estimated* file count and total data size needed */
|
2022-03-08 19:04:19 +00:00
|
|
|
count = cprm->vma_count;
|
2018-02-06 23:39:13 +00:00
|
|
|
if (count > UINT_MAX / 64)
|
|
|
|
return -EINVAL;
|
2012-10-05 00:15:36 +00:00
|
|
|
size = count * 64;
|
|
|
|
|
|
|
|
names_ofs = (2 + 3 * count) * sizeof(data[0]);
|
|
|
|
alloc:
|
|
|
|
if (size >= MAX_FILE_NOTE_SIZE) /* paranoia check */
|
2013-09-30 20:45:02 +00:00
|
|
|
return -EINVAL;
|
2012-10-05 00:15:36 +00:00
|
|
|
size = round_up(size, PAGE_SIZE);
|
2020-01-31 06:17:10 +00:00
|
|
|
/*
|
|
|
|
* "size" can be 0 here legitimately.
|
|
|
|
* Let it ENOMEM and omit NT_FILE section which will be empty anyway.
|
|
|
|
*/
|
2018-06-14 22:27:24 +00:00
|
|
|
data = kvmalloc(size, GFP_KERNEL);
|
|
|
|
if (ZERO_OR_NULL_PTR(data))
|
2013-09-30 20:45:02 +00:00
|
|
|
return -ENOMEM;
|
2012-10-05 00:15:36 +00:00
|
|
|
|
|
|
|
start_end_ofs = data + 2;
|
|
|
|
name_base = name_curpos = ((char *)data) + names_ofs;
|
|
|
|
remaining = size - names_ofs;
|
|
|
|
count = 0;
|
2022-03-08 19:04:19 +00:00
|
|
|
for (i = 0; i < cprm->vma_count; i++) {
|
|
|
|
struct core_vma_metadata *m = &cprm->vma_meta[i];
|
2012-10-05 00:15:36 +00:00
|
|
|
struct file *file;
|
|
|
|
const char *filename;
|
|
|
|
|
2022-03-08 19:04:19 +00:00
|
|
|
file = m->file;
|
2012-10-05 00:15:36 +00:00
|
|
|
if (!file)
|
|
|
|
continue;
|
2015-06-19 08:29:13 +00:00
|
|
|
filename = file_path(file, name_curpos, remaining);
|
2012-10-05 00:15:36 +00:00
|
|
|
if (IS_ERR(filename)) {
|
|
|
|
if (PTR_ERR(filename) == -ENAMETOOLONG) {
|
2018-06-14 22:27:24 +00:00
|
|
|
kvfree(data);
|
2012-10-05 00:15:36 +00:00
|
|
|
size = size * 5 / 4;
|
|
|
|
goto alloc;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2015-06-19 08:29:13 +00:00
|
|
|
/* file_path() fills at the end, move name down */
|
2012-10-05 00:15:36 +00:00
|
|
|
/* n = strlen(filename) + 1: */
|
|
|
|
n = (name_curpos + remaining) - filename;
|
|
|
|
remaining = filename - name_curpos;
|
|
|
|
memmove(name_curpos, filename, n);
|
|
|
|
name_curpos += n;
|
|
|
|
|
2022-03-08 19:04:19 +00:00
|
|
|
*start_end_ofs++ = m->start;
|
|
|
|
*start_end_ofs++ = m->end;
|
|
|
|
*start_end_ofs++ = m->pgoff;
|
2012-10-05 00:15:36 +00:00
|
|
|
count++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now we know exact count of files, can store it */
|
|
|
|
data[0] = count;
|
|
|
|
data[1] = PAGE_SIZE;
|
|
|
|
/*
|
2020-01-31 06:16:58 +00:00
|
|
|
* Count usually is less than mm->map_count,
|
2012-10-05 00:15:36 +00:00
|
|
|
* we need to move filenames down.
|
|
|
|
*/
|
2022-03-08 19:04:19 +00:00
|
|
|
n = cprm->vma_count - count;
|
2012-10-05 00:15:36 +00:00
|
|
|
if (n != 0) {
|
|
|
|
unsigned shift_bytes = n * 3 * sizeof(data[0]);
|
|
|
|
memmove(name_base - shift_bytes, name_base,
|
|
|
|
name_curpos - name_base);
|
|
|
|
name_curpos -= shift_bytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
size = name_curpos - (char *)data;
|
|
|
|
fill_note(note, "CORE", NT_FILE, size, data);
|
2013-09-30 20:45:02 +00:00
|
|
|
return 0;
|
2012-10-05 00:15:36 +00:00
|
|
|
}
|
|
|
|
|
2008-01-30 12:31:45 +00:00
|
|
|
#include <linux/regset.h>
|
|
|
|
|
|
|
|
struct elf_thread_core_info {
|
|
|
|
struct elf_thread_core_info *next;
|
|
|
|
struct task_struct *task;
|
|
|
|
struct elf_prstatus prstatus;
|
2020-08-31 13:25:42 +00:00
|
|
|
struct memelfnote notes[];
|
2008-01-30 12:31:45 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct elf_note_info {
|
|
|
|
struct elf_thread_core_info *thread;
|
|
|
|
struct memelfnote psinfo;
|
2012-10-05 00:15:35 +00:00
|
|
|
struct memelfnote signote;
|
2008-01-30 12:31:45 +00:00
|
|
|
struct memelfnote auxv;
|
2012-10-05 00:15:36 +00:00
|
|
|
struct memelfnote files;
|
2012-10-05 00:15:35 +00:00
|
|
|
user_siginfo_t csigdata;
|
2008-01-30 12:31:45 +00:00
|
|
|
size_t size;
|
|
|
|
int thread_notes;
|
|
|
|
};
|
|
|
|
|
2022-09-05 04:41:05 +00:00
|
|
|
#ifdef CORE_DUMP_USE_REGSET
|
2008-03-04 22:28:30 +00:00
|
|
|
/*
|
|
|
|
* When a regset has a writeback hook, we call it on each thread before
|
|
|
|
* dumping user memory. On register window machines, this makes sure the
|
|
|
|
* user memory backing the register data is up to date before we read it.
|
|
|
|
*/
|
|
|
|
static void do_thread_regset_writeback(struct task_struct *task,
|
|
|
|
const struct user_regset *regset)
|
|
|
|
{
|
|
|
|
if (regset->writeback)
|
|
|
|
regset->writeback(task, regset, 1);
|
|
|
|
}
|
|
|
|
|
2012-02-14 21:34:52 +00:00
|
|
|
#ifndef PRSTATUS_SIZE
|
binfmt_elf: partially sanitize PRSTATUS_SIZE and SET_PR_FPVALID
On 64bit architectures that support 32bit processes there are
two possible layouts for NT_PRSTATUS note in ELF coredumps.
For one thing, several fields are 64bit for native processes
and 32bit for compat ones (pr_sigpend, etc.). For another,
the register dump is obviously different - the size and number
of registers are not going to be the same for 32bit and 64bit
variants of processor.
Usually that's handled by having two structures - elf_prstatus
for native layout and compat_elf_prstatus for 32bit one.
32bit processes are handled by fs/compat_binfmt_elf.c, which
defines a macro called 'elf_prstatus' that expands to compat_elf_prstatus.
Then it includes fs/binfmt_elf.c, which makes all references to
struct elf_prstatus to be textually replaced with struct
compat_elf_prstatus. Ugly and somewhat brittle, but it works.
However, amd64 is worse - there are _three_ possible layouts.
One for native 64bit processes, another for i386 (32bit) processes
and yet another for x32 (32bit address space with full 64bit
registers).
Both i386 and x32 processes are handled by fs/compat_binfmt_elf.c,
with usual compat_binfmt_elf.c trickery. However, the layouts
for i386 and x32 are not identical - they have the common beginning,
but the register dump part (pr_reg) is bigger on x32. Worse, pr_reg
is not the last field - it's followed by int pr_fpvalid, so that
field ends up at different offsets for i386 and x32 layouts.
Fortunately, there's not much code that cares about any of that -
it's all encapsulated in fill_thread_core_info(). Since x32
variant is bigger, we define compat_elf_prstatus to match that
layout. That way i386 processes have enough space to fit
their layout into.
Moreover, since these layouts are identical prior to pr_reg,
we don't need to distinguish x32 and i386 cases when we are
setting the fields prior to pr_reg.
Filling pr_reg itself is done by calling ->get() method of
appropriate regset, and that method knows what layout (and size)
to use.
We do need to distinguish x32 and i386 cases only for two
things: setting ->pr_fpvalid (offset differs for x32 and
i386) and choosing the right size for our note.
The way it's done is Not Nice, for the lack of more accurate
printable description. There are two macros (PRSTATUS_SIZE and
SET_PR_FPVALID), that default essentially to sizeof(struct elf_prstatus)
and (S)->pr_fpvalid = 1. On x86 asm/compat.h provides its own
variants.
Unfortunately, quite a few things go wrong there:
* PRSTATUS_SIZE doesn't use the normal test for process
being an x32 one; it compares the size reported by regset with
the size of pr_reg.
* it hardcodes the sizes of x32 and i386 variants (296 and 144
resp.), so if some change in includes leads to asm/compat.h pulled
in by fs/binfmt_elf.c we are in trouble - it will end up using
the size of x32 variant for 64bit processes.
* it's in the wrong place; asm/compat.h couldn't define
the structure for i386 layout, since it lacks quite a few types
needed for it. Hardcoded sizes are largely due to that.
The proper fix would be to have an explicitly defined i386 variant
of structure and have PRSTATUS_SIZE/SET_PR_FPVALID check for
TIF_X32 to choose the variant that should be used. Unfortunately,
that requires some manipulations of headers; we'll do that later
in the series, but for now let's go with the minimal variant -
rename PRSTATUS_SIZE in asm/compat.h to COMPAT_PRSTATUS_SIZE,
have fs/compat_binfmt_elf.c define PRSTATUS_SIZE to COMPAT_PRSTATUS_SIZE
and use the normal TIF_X32 check in that macro. The size of i386 variant
is kept hardcoded for now. Similar story for SET_PR_FPVALID.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2020-06-23 00:14:02 +00:00
|
|
|
#define PRSTATUS_SIZE sizeof(struct elf_prstatus)
|
2012-02-14 21:34:52 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef SET_PR_FPVALID
|
binfmt_elf: partially sanitize PRSTATUS_SIZE and SET_PR_FPVALID
On 64bit architectures that support 32bit processes there are
two possible layouts for NT_PRSTATUS note in ELF coredumps.
For one thing, several fields are 64bit for native processes
and 32bit for compat ones (pr_sigpend, etc.). For another,
the register dump is obviously different - the size and number
of registers are not going to be the same for 32bit and 64bit
variants of processor.
Usually that's handled by having two structures - elf_prstatus
for native layout and compat_elf_prstatus for 32bit one.
32bit processes are handled by fs/compat_binfmt_elf.c, which
defines a macro called 'elf_prstatus' that expands to compat_elf_prstatus.
Then it includes fs/binfmt_elf.c, which makes all references to
struct elf_prstatus to be textually replaced with struct
compat_elf_prstatus. Ugly and somewhat brittle, but it works.
However, amd64 is worse - there are _three_ possible layouts.
One for native 64bit processes, another for i386 (32bit) processes
and yet another for x32 (32bit address space with full 64bit
registers).
Both i386 and x32 processes are handled by fs/compat_binfmt_elf.c,
with usual compat_binfmt_elf.c trickery. However, the layouts
for i386 and x32 are not identical - they have the common beginning,
but the register dump part (pr_reg) is bigger on x32. Worse, pr_reg
is not the last field - it's followed by int pr_fpvalid, so that
field ends up at different offsets for i386 and x32 layouts.
Fortunately, there's not much code that cares about any of that -
it's all encapsulated in fill_thread_core_info(). Since x32
variant is bigger, we define compat_elf_prstatus to match that
layout. That way i386 processes have enough space to fit
their layout into.
Moreover, since these layouts are identical prior to pr_reg,
we don't need to distinguish x32 and i386 cases when we are
setting the fields prior to pr_reg.
Filling pr_reg itself is done by calling ->get() method of
appropriate regset, and that method knows what layout (and size)
to use.
We do need to distinguish x32 and i386 cases only for two
things: setting ->pr_fpvalid (offset differs for x32 and
i386) and choosing the right size for our note.
The way it's done is Not Nice, for the lack of more accurate
printable description. There are two macros (PRSTATUS_SIZE and
SET_PR_FPVALID), that default essentially to sizeof(struct elf_prstatus)
and (S)->pr_fpvalid = 1. On x86 asm/compat.h provides its own
variants.
Unfortunately, quite a few things go wrong there:
* PRSTATUS_SIZE doesn't use the normal test for process
being an x32 one; it compares the size reported by regset with
the size of pr_reg.
* it hardcodes the sizes of x32 and i386 variants (296 and 144
resp.), so if some change in includes leads to asm/compat.h pulled
in by fs/binfmt_elf.c we are in trouble - it will end up using
the size of x32 variant for 64bit processes.
* it's in the wrong place; asm/compat.h couldn't define
the structure for i386 layout, since it lacks quite a few types
needed for it. Hardcoded sizes are largely due to that.
The proper fix would be to have an explicitly defined i386 variant
of structure and have PRSTATUS_SIZE/SET_PR_FPVALID check for
TIF_X32 to choose the variant that should be used. Unfortunately,
that requires some manipulations of headers; we'll do that later
in the series, but for now let's go with the minimal variant -
rename PRSTATUS_SIZE in asm/compat.h to COMPAT_PRSTATUS_SIZE,
have fs/compat_binfmt_elf.c define PRSTATUS_SIZE to COMPAT_PRSTATUS_SIZE
and use the normal TIF_X32 check in that macro. The size of i386 variant
is kept hardcoded for now. Similar story for SET_PR_FPVALID.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2020-06-23 00:14:02 +00:00
|
|
|
#define SET_PR_FPVALID(S) ((S)->pr_fpvalid = 1)
|
2012-02-14 21:34:52 +00:00
|
|
|
#endif
|
|
|
|
|
2008-01-30 12:31:45 +00:00
|
|
|
static int fill_thread_core_info(struct elf_thread_core_info *t,
|
|
|
|
const struct user_regset_view *view,
|
binfmt_elf: Don't write past end of notes for regset gap
In fill_thread_core_info() the ptrace accessible registers are collected
to be written out as notes in a core file. The note array is allocated
from a size calculated by iterating the user regset view, and counting the
regsets that have a non-zero core_note_type. However, this only allows for
there to be non-zero core_note_type at the end of the regset view. If
there are any gaps in the middle, fill_thread_core_info() will overflow the
note allocation, as it iterates over the size of the view and the
allocation would be smaller than that.
There doesn't appear to be any arch that has gaps such that they exceed
the notes allocation, but the code is brittle and tries to support
something it doesn't. It could be fixed by increasing the allocation size,
but instead just have the note collecting code utilize the array better.
This way the allocation can stay smaller.
Even in the case of no arch's that have gaps in their regset views, this
introduces a change in the resulting indicies of t->notes. It does not
introduce any changes to the core file itself, because any blank notes are
skipped in write_note_info().
In case, the allocation logic between fill_note_info() and
fill_thread_core_info() ever diverges from the usage logic, warn and skip
writing any notes that would overflow the array.
This fix is derrived from an earlier one[0] by Yu-cheng Yu.
[0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
2022-03-17 19:20:13 +00:00
|
|
|
long signr, struct elf_note_info *info)
|
2008-01-30 12:31:45 +00:00
|
|
|
{
|
binfmt_elf: Don't write past end of notes for regset gap
In fill_thread_core_info() the ptrace accessible registers are collected
to be written out as notes in a core file. The note array is allocated
from a size calculated by iterating the user regset view, and counting the
regsets that have a non-zero core_note_type. However, this only allows for
there to be non-zero core_note_type at the end of the regset view. If
there are any gaps in the middle, fill_thread_core_info() will overflow the
note allocation, as it iterates over the size of the view and the
allocation would be smaller than that.
There doesn't appear to be any arch that has gaps such that they exceed
the notes allocation, but the code is brittle and tries to support
something it doesn't. It could be fixed by increasing the allocation size,
but instead just have the note collecting code utilize the array better.
This way the allocation can stay smaller.
Even in the case of no arch's that have gaps in their regset views, this
introduces a change in the resulting indicies of t->notes. It does not
introduce any changes to the core file itself, because any blank notes are
skipped in write_note_info().
In case, the allocation logic between fill_note_info() and
fill_thread_core_info() ever diverges from the usage logic, warn and skip
writing any notes that would overflow the array.
This fix is derrived from an earlier one[0] by Yu-cheng Yu.
[0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
2022-03-17 19:20:13 +00:00
|
|
|
unsigned int note_iter, view_iter;
|
2008-01-30 12:31:45 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* NT_PRSTATUS is the one special case, because the regset data
|
|
|
|
* goes into the pr_reg field inside the note contents, rather
|
|
|
|
* than being the whole note contents. We fill the reset in here.
|
|
|
|
* We assume that regset 0 is NT_PRSTATUS.
|
|
|
|
*/
|
2020-06-13 04:08:44 +00:00
|
|
|
fill_prstatus(&t->prstatus.common, t->task, signr);
|
binfmt_elf: partially sanitize PRSTATUS_SIZE and SET_PR_FPVALID
On 64bit architectures that support 32bit processes there are
two possible layouts for NT_PRSTATUS note in ELF coredumps.
For one thing, several fields are 64bit for native processes
and 32bit for compat ones (pr_sigpend, etc.). For another,
the register dump is obviously different - the size and number
of registers are not going to be the same for 32bit and 64bit
variants of processor.
Usually that's handled by having two structures - elf_prstatus
for native layout and compat_elf_prstatus for 32bit one.
32bit processes are handled by fs/compat_binfmt_elf.c, which
defines a macro called 'elf_prstatus' that expands to compat_elf_prstatus.
Then it includes fs/binfmt_elf.c, which makes all references to
struct elf_prstatus to be textually replaced with struct
compat_elf_prstatus. Ugly and somewhat brittle, but it works.
However, amd64 is worse - there are _three_ possible layouts.
One for native 64bit processes, another for i386 (32bit) processes
and yet another for x32 (32bit address space with full 64bit
registers).
Both i386 and x32 processes are handled by fs/compat_binfmt_elf.c,
with usual compat_binfmt_elf.c trickery. However, the layouts
for i386 and x32 are not identical - they have the common beginning,
but the register dump part (pr_reg) is bigger on x32. Worse, pr_reg
is not the last field - it's followed by int pr_fpvalid, so that
field ends up at different offsets for i386 and x32 layouts.
Fortunately, there's not much code that cares about any of that -
it's all encapsulated in fill_thread_core_info(). Since x32
variant is bigger, we define compat_elf_prstatus to match that
layout. That way i386 processes have enough space to fit
their layout into.
Moreover, since these layouts are identical prior to pr_reg,
we don't need to distinguish x32 and i386 cases when we are
setting the fields prior to pr_reg.
Filling pr_reg itself is done by calling ->get() method of
appropriate regset, and that method knows what layout (and size)
to use.
We do need to distinguish x32 and i386 cases only for two
things: setting ->pr_fpvalid (offset differs for x32 and
i386) and choosing the right size for our note.
The way it's done is Not Nice, for the lack of more accurate
printable description. There are two macros (PRSTATUS_SIZE and
SET_PR_FPVALID), that default essentially to sizeof(struct elf_prstatus)
and (S)->pr_fpvalid = 1. On x86 asm/compat.h provides its own
variants.
Unfortunately, quite a few things go wrong there:
* PRSTATUS_SIZE doesn't use the normal test for process
being an x32 one; it compares the size reported by regset with
the size of pr_reg.
* it hardcodes the sizes of x32 and i386 variants (296 and 144
resp.), so if some change in includes leads to asm/compat.h pulled
in by fs/binfmt_elf.c we are in trouble - it will end up using
the size of x32 variant for 64bit processes.
* it's in the wrong place; asm/compat.h couldn't define
the structure for i386 layout, since it lacks quite a few types
needed for it. Hardcoded sizes are largely due to that.
The proper fix would be to have an explicitly defined i386 variant
of structure and have PRSTATUS_SIZE/SET_PR_FPVALID check for
TIF_X32 to choose the variant that should be used. Unfortunately,
that requires some manipulations of headers; we'll do that later
in the series, but for now let's go with the minimal variant -
rename PRSTATUS_SIZE in asm/compat.h to COMPAT_PRSTATUS_SIZE,
have fs/compat_binfmt_elf.c define PRSTATUS_SIZE to COMPAT_PRSTATUS_SIZE
and use the normal TIF_X32 check in that macro. The size of i386 variant
is kept hardcoded for now. Similar story for SET_PR_FPVALID.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2020-06-23 00:14:02 +00:00
|
|
|
regset_get(t->task, &view->regsets[0],
|
2020-06-01 23:42:40 +00:00
|
|
|
sizeof(t->prstatus.pr_reg), &t->prstatus.pr_reg);
|
2008-01-30 12:31:45 +00:00
|
|
|
|
|
|
|
fill_note(&t->notes[0], "CORE", NT_PRSTATUS,
|
binfmt_elf: partially sanitize PRSTATUS_SIZE and SET_PR_FPVALID
On 64bit architectures that support 32bit processes there are
two possible layouts for NT_PRSTATUS note in ELF coredumps.
For one thing, several fields are 64bit for native processes
and 32bit for compat ones (pr_sigpend, etc.). For another,
the register dump is obviously different - the size and number
of registers are not going to be the same for 32bit and 64bit
variants of processor.
Usually that's handled by having two structures - elf_prstatus
for native layout and compat_elf_prstatus for 32bit one.
32bit processes are handled by fs/compat_binfmt_elf.c, which
defines a macro called 'elf_prstatus' that expands to compat_elf_prstatus.
Then it includes fs/binfmt_elf.c, which makes all references to
struct elf_prstatus to be textually replaced with struct
compat_elf_prstatus. Ugly and somewhat brittle, but it works.
However, amd64 is worse - there are _three_ possible layouts.
One for native 64bit processes, another for i386 (32bit) processes
and yet another for x32 (32bit address space with full 64bit
registers).
Both i386 and x32 processes are handled by fs/compat_binfmt_elf.c,
with usual compat_binfmt_elf.c trickery. However, the layouts
for i386 and x32 are not identical - they have the common beginning,
but the register dump part (pr_reg) is bigger on x32. Worse, pr_reg
is not the last field - it's followed by int pr_fpvalid, so that
field ends up at different offsets for i386 and x32 layouts.
Fortunately, there's not much code that cares about any of that -
it's all encapsulated in fill_thread_core_info(). Since x32
variant is bigger, we define compat_elf_prstatus to match that
layout. That way i386 processes have enough space to fit
their layout into.
Moreover, since these layouts are identical prior to pr_reg,
we don't need to distinguish x32 and i386 cases when we are
setting the fields prior to pr_reg.
Filling pr_reg itself is done by calling ->get() method of
appropriate regset, and that method knows what layout (and size)
to use.
We do need to distinguish x32 and i386 cases only for two
things: setting ->pr_fpvalid (offset differs for x32 and
i386) and choosing the right size for our note.
The way it's done is Not Nice, for the lack of more accurate
printable description. There are two macros (PRSTATUS_SIZE and
SET_PR_FPVALID), that default essentially to sizeof(struct elf_prstatus)
and (S)->pr_fpvalid = 1. On x86 asm/compat.h provides its own
variants.
Unfortunately, quite a few things go wrong there:
* PRSTATUS_SIZE doesn't use the normal test for process
being an x32 one; it compares the size reported by regset with
the size of pr_reg.
* it hardcodes the sizes of x32 and i386 variants (296 and 144
resp.), so if some change in includes leads to asm/compat.h pulled
in by fs/binfmt_elf.c we are in trouble - it will end up using
the size of x32 variant for 64bit processes.
* it's in the wrong place; asm/compat.h couldn't define
the structure for i386 layout, since it lacks quite a few types
needed for it. Hardcoded sizes are largely due to that.
The proper fix would be to have an explicitly defined i386 variant
of structure and have PRSTATUS_SIZE/SET_PR_FPVALID check for
TIF_X32 to choose the variant that should be used. Unfortunately,
that requires some manipulations of headers; we'll do that later
in the series, but for now let's go with the minimal variant -
rename PRSTATUS_SIZE in asm/compat.h to COMPAT_PRSTATUS_SIZE,
have fs/compat_binfmt_elf.c define PRSTATUS_SIZE to COMPAT_PRSTATUS_SIZE
and use the normal TIF_X32 check in that macro. The size of i386 variant
is kept hardcoded for now. Similar story for SET_PR_FPVALID.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2020-06-23 00:14:02 +00:00
|
|
|
PRSTATUS_SIZE, &t->prstatus);
|
binfmt_elf: Don't write past end of notes for regset gap
In fill_thread_core_info() the ptrace accessible registers are collected
to be written out as notes in a core file. The note array is allocated
from a size calculated by iterating the user regset view, and counting the
regsets that have a non-zero core_note_type. However, this only allows for
there to be non-zero core_note_type at the end of the regset view. If
there are any gaps in the middle, fill_thread_core_info() will overflow the
note allocation, as it iterates over the size of the view and the
allocation would be smaller than that.
There doesn't appear to be any arch that has gaps such that they exceed
the notes allocation, but the code is brittle and tries to support
something it doesn't. It could be fixed by increasing the allocation size,
but instead just have the note collecting code utilize the array better.
This way the allocation can stay smaller.
Even in the case of no arch's that have gaps in their regset views, this
introduces a change in the resulting indicies of t->notes. It does not
introduce any changes to the core file itself, because any blank notes are
skipped in write_note_info().
In case, the allocation logic between fill_note_info() and
fill_thread_core_info() ever diverges from the usage logic, warn and skip
writing any notes that would overflow the array.
This fix is derrived from an earlier one[0] by Yu-cheng Yu.
[0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
2022-03-17 19:20:13 +00:00
|
|
|
info->size += notesize(&t->notes[0]);
|
2008-01-30 12:31:45 +00:00
|
|
|
|
2008-03-04 22:28:30 +00:00
|
|
|
do_thread_regset_writeback(t->task, &view->regsets[0]);
|
|
|
|
|
2008-01-30 12:31:45 +00:00
|
|
|
/*
|
|
|
|
* Each other regset might generate a note too. For each regset
|
binfmt_elf: Don't write past end of notes for regset gap
In fill_thread_core_info() the ptrace accessible registers are collected
to be written out as notes in a core file. The note array is allocated
from a size calculated by iterating the user regset view, and counting the
regsets that have a non-zero core_note_type. However, this only allows for
there to be non-zero core_note_type at the end of the regset view. If
there are any gaps in the middle, fill_thread_core_info() will overflow the
note allocation, as it iterates over the size of the view and the
allocation would be smaller than that.
There doesn't appear to be any arch that has gaps such that they exceed
the notes allocation, but the code is brittle and tries to support
something it doesn't. It could be fixed by increasing the allocation size,
but instead just have the note collecting code utilize the array better.
This way the allocation can stay smaller.
Even in the case of no arch's that have gaps in their regset views, this
introduces a change in the resulting indicies of t->notes. It does not
introduce any changes to the core file itself, because any blank notes are
skipped in write_note_info().
In case, the allocation logic between fill_note_info() and
fill_thread_core_info() ever diverges from the usage logic, warn and skip
writing any notes that would overflow the array.
This fix is derrived from an earlier one[0] by Yu-cheng Yu.
[0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
2022-03-17 19:20:13 +00:00
|
|
|
* that has no core_note_type or is inactive, skip it.
|
2008-01-30 12:31:45 +00:00
|
|
|
*/
|
binfmt_elf: Don't write past end of notes for regset gap
In fill_thread_core_info() the ptrace accessible registers are collected
to be written out as notes in a core file. The note array is allocated
from a size calculated by iterating the user regset view, and counting the
regsets that have a non-zero core_note_type. However, this only allows for
there to be non-zero core_note_type at the end of the regset view. If
there are any gaps in the middle, fill_thread_core_info() will overflow the
note allocation, as it iterates over the size of the view and the
allocation would be smaller than that.
There doesn't appear to be any arch that has gaps such that they exceed
the notes allocation, but the code is brittle and tries to support
something it doesn't. It could be fixed by increasing the allocation size,
but instead just have the note collecting code utilize the array better.
This way the allocation can stay smaller.
Even in the case of no arch's that have gaps in their regset views, this
introduces a change in the resulting indicies of t->notes. It does not
introduce any changes to the core file itself, because any blank notes are
skipped in write_note_info().
In case, the allocation logic between fill_note_info() and
fill_thread_core_info() ever diverges from the usage logic, warn and skip
writing any notes that would overflow the array.
This fix is derrived from an earlier one[0] by Yu-cheng Yu.
[0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
2022-03-17 19:20:13 +00:00
|
|
|
note_iter = 1;
|
|
|
|
for (view_iter = 1; view_iter < view->n; ++view_iter) {
|
|
|
|
const struct user_regset *regset = &view->regsets[view_iter];
|
2020-06-01 23:42:40 +00:00
|
|
|
int note_type = regset->core_note_type;
|
|
|
|
bool is_fpreg = note_type == NT_PRFPREG;
|
|
|
|
void *data;
|
|
|
|
int ret;
|
|
|
|
|
2008-03-04 22:28:30 +00:00
|
|
|
do_thread_regset_writeback(t->task, regset);
|
2020-06-01 23:42:40 +00:00
|
|
|
if (!note_type) // not for coredumps
|
|
|
|
continue;
|
|
|
|
if (regset->active && regset->active(t->task, regset) <= 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = regset_get_alloc(t->task, regset, ~0U, &data);
|
|
|
|
if (ret < 0)
|
|
|
|
continue;
|
|
|
|
|
binfmt_elf: Don't write past end of notes for regset gap
In fill_thread_core_info() the ptrace accessible registers are collected
to be written out as notes in a core file. The note array is allocated
from a size calculated by iterating the user regset view, and counting the
regsets that have a non-zero core_note_type. However, this only allows for
there to be non-zero core_note_type at the end of the regset view. If
there are any gaps in the middle, fill_thread_core_info() will overflow the
note allocation, as it iterates over the size of the view and the
allocation would be smaller than that.
There doesn't appear to be any arch that has gaps such that they exceed
the notes allocation, but the code is brittle and tries to support
something it doesn't. It could be fixed by increasing the allocation size,
but instead just have the note collecting code utilize the array better.
This way the allocation can stay smaller.
Even in the case of no arch's that have gaps in their regset views, this
introduces a change in the resulting indicies of t->notes. It does not
introduce any changes to the core file itself, because any blank notes are
skipped in write_note_info().
In case, the allocation logic between fill_note_info() and
fill_thread_core_info() ever diverges from the usage logic, warn and skip
writing any notes that would overflow the array.
This fix is derrived from an earlier one[0] by Yu-cheng Yu.
[0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
2022-03-17 19:20:13 +00:00
|
|
|
if (WARN_ON_ONCE(note_iter >= info->thread_notes))
|
|
|
|
break;
|
|
|
|
|
2020-06-01 23:42:40 +00:00
|
|
|
if (is_fpreg)
|
binfmt_elf: partially sanitize PRSTATUS_SIZE and SET_PR_FPVALID
On 64bit architectures that support 32bit processes there are
two possible layouts for NT_PRSTATUS note in ELF coredumps.
For one thing, several fields are 64bit for native processes
and 32bit for compat ones (pr_sigpend, etc.). For another,
the register dump is obviously different - the size and number
of registers are not going to be the same for 32bit and 64bit
variants of processor.
Usually that's handled by having two structures - elf_prstatus
for native layout and compat_elf_prstatus for 32bit one.
32bit processes are handled by fs/compat_binfmt_elf.c, which
defines a macro called 'elf_prstatus' that expands to compat_elf_prstatus.
Then it includes fs/binfmt_elf.c, which makes all references to
struct elf_prstatus to be textually replaced with struct
compat_elf_prstatus. Ugly and somewhat brittle, but it works.
However, amd64 is worse - there are _three_ possible layouts.
One for native 64bit processes, another for i386 (32bit) processes
and yet another for x32 (32bit address space with full 64bit
registers).
Both i386 and x32 processes are handled by fs/compat_binfmt_elf.c,
with usual compat_binfmt_elf.c trickery. However, the layouts
for i386 and x32 are not identical - they have the common beginning,
but the register dump part (pr_reg) is bigger on x32. Worse, pr_reg
is not the last field - it's followed by int pr_fpvalid, so that
field ends up at different offsets for i386 and x32 layouts.
Fortunately, there's not much code that cares about any of that -
it's all encapsulated in fill_thread_core_info(). Since x32
variant is bigger, we define compat_elf_prstatus to match that
layout. That way i386 processes have enough space to fit
their layout into.
Moreover, since these layouts are identical prior to pr_reg,
we don't need to distinguish x32 and i386 cases when we are
setting the fields prior to pr_reg.
Filling pr_reg itself is done by calling ->get() method of
appropriate regset, and that method knows what layout (and size)
to use.
We do need to distinguish x32 and i386 cases only for two
things: setting ->pr_fpvalid (offset differs for x32 and
i386) and choosing the right size for our note.
The way it's done is Not Nice, for the lack of more accurate
printable description. There are two macros (PRSTATUS_SIZE and
SET_PR_FPVALID), that default essentially to sizeof(struct elf_prstatus)
and (S)->pr_fpvalid = 1. On x86 asm/compat.h provides its own
variants.
Unfortunately, quite a few things go wrong there:
* PRSTATUS_SIZE doesn't use the normal test for process
being an x32 one; it compares the size reported by regset with
the size of pr_reg.
* it hardcodes the sizes of x32 and i386 variants (296 and 144
resp.), so if some change in includes leads to asm/compat.h pulled
in by fs/binfmt_elf.c we are in trouble - it will end up using
the size of x32 variant for 64bit processes.
* it's in the wrong place; asm/compat.h couldn't define
the structure for i386 layout, since it lacks quite a few types
needed for it. Hardcoded sizes are largely due to that.
The proper fix would be to have an explicitly defined i386 variant
of structure and have PRSTATUS_SIZE/SET_PR_FPVALID check for
TIF_X32 to choose the variant that should be used. Unfortunately,
that requires some manipulations of headers; we'll do that later
in the series, but for now let's go with the minimal variant -
rename PRSTATUS_SIZE in asm/compat.h to COMPAT_PRSTATUS_SIZE,
have fs/compat_binfmt_elf.c define PRSTATUS_SIZE to COMPAT_PRSTATUS_SIZE
and use the normal TIF_X32 check in that macro. The size of i386 variant
is kept hardcoded for now. Similar story for SET_PR_FPVALID.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2020-06-23 00:14:02 +00:00
|
|
|
SET_PR_FPVALID(&t->prstatus);
|
2020-06-01 23:42:40 +00:00
|
|
|
|
binfmt_elf: Don't write past end of notes for regset gap
In fill_thread_core_info() the ptrace accessible registers are collected
to be written out as notes in a core file. The note array is allocated
from a size calculated by iterating the user regset view, and counting the
regsets that have a non-zero core_note_type. However, this only allows for
there to be non-zero core_note_type at the end of the regset view. If
there are any gaps in the middle, fill_thread_core_info() will overflow the
note allocation, as it iterates over the size of the view and the
allocation would be smaller than that.
There doesn't appear to be any arch that has gaps such that they exceed
the notes allocation, but the code is brittle and tries to support
something it doesn't. It could be fixed by increasing the allocation size,
but instead just have the note collecting code utilize the array better.
This way the allocation can stay smaller.
Even in the case of no arch's that have gaps in their regset views, this
introduces a change in the resulting indicies of t->notes. It does not
introduce any changes to the core file itself, because any blank notes are
skipped in write_note_info().
In case, the allocation logic between fill_note_info() and
fill_thread_core_info() ever diverges from the usage logic, warn and skip
writing any notes that would overflow the array.
This fix is derrived from an earlier one[0] by Yu-cheng Yu.
[0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
2022-03-17 19:20:13 +00:00
|
|
|
fill_note(&t->notes[note_iter], is_fpreg ? "CORE" : "LINUX",
|
2020-06-01 23:42:40 +00:00
|
|
|
note_type, ret, data);
|
|
|
|
|
binfmt_elf: Don't write past end of notes for regset gap
In fill_thread_core_info() the ptrace accessible registers are collected
to be written out as notes in a core file. The note array is allocated
from a size calculated by iterating the user regset view, and counting the
regsets that have a non-zero core_note_type. However, this only allows for
there to be non-zero core_note_type at the end of the regset view. If
there are any gaps in the middle, fill_thread_core_info() will overflow the
note allocation, as it iterates over the size of the view and the
allocation would be smaller than that.
There doesn't appear to be any arch that has gaps such that they exceed
the notes allocation, but the code is brittle and tries to support
something it doesn't. It could be fixed by increasing the allocation size,
but instead just have the note collecting code utilize the array better.
This way the allocation can stay smaller.
Even in the case of no arch's that have gaps in their regset views, this
introduces a change in the resulting indicies of t->notes. It does not
introduce any changes to the core file itself, because any blank notes are
skipped in write_note_info().
In case, the allocation logic between fill_note_info() and
fill_thread_core_info() ever diverges from the usage logic, warn and skip
writing any notes that would overflow the array.
This fix is derrived from an earlier one[0] by Yu-cheng Yu.
[0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
2022-03-17 19:20:13 +00:00
|
|
|
info->size += notesize(&t->notes[note_iter]);
|
|
|
|
note_iter++;
|
2008-01-30 12:31:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
2022-09-05 04:41:05 +00:00
|
|
|
#else
|
|
|
|
static int fill_thread_core_info(struct elf_thread_core_info *t,
|
|
|
|
const struct user_regset_view *view,
|
|
|
|
long signr, struct elf_note_info *info)
|
|
|
|
{
|
|
|
|
struct task_struct *p = t->task;
|
|
|
|
elf_fpregset_t *fpu;
|
|
|
|
|
|
|
|
fill_prstatus(&t->prstatus.common, p, signr);
|
|
|
|
elf_core_copy_task_regs(p, &t->prstatus.pr_reg);
|
|
|
|
|
|
|
|
fill_note(&t->notes[0], "CORE", NT_PRSTATUS, sizeof(t->prstatus),
|
|
|
|
&(t->prstatus));
|
|
|
|
info->size += notesize(&t->notes[0]);
|
|
|
|
|
|
|
|
fpu = kzalloc(sizeof(elf_fpregset_t), GFP_KERNEL);
|
|
|
|
if (!fpu || !elf_core_copy_task_fpregs(p, fpu)) {
|
|
|
|
kfree(fpu);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
t->prstatus.pr_fpvalid = 1;
|
|
|
|
fill_note(&t->notes[1], "CORE", NT_PRFPREG, sizeof(*fpu), fpu);
|
|
|
|
info->size += notesize(&t->notes[1]);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#endif
|
2008-01-30 12:31:45 +00:00
|
|
|
|
|
|
|
static int fill_note_info(struct elfhdr *elf, int phdrs,
|
|
|
|
struct elf_note_info *info,
|
2022-01-31 18:17:38 +00:00
|
|
|
struct coredump_params *cprm)
|
2008-01-30 12:31:45 +00:00
|
|
|
{
|
|
|
|
struct task_struct *dump_task = current;
|
2022-09-05 04:41:05 +00:00
|
|
|
const struct user_regset_view *view;
|
2008-01-30 12:31:45 +00:00
|
|
|
struct elf_thread_core_info *t;
|
|
|
|
struct elf_prpsinfo *psinfo;
|
2008-07-25 08:47:45 +00:00
|
|
|
struct core_thread *ct;
|
2008-01-30 12:31:45 +00:00
|
|
|
|
|
|
|
psinfo = kmalloc(sizeof(*psinfo), GFP_KERNEL);
|
2022-09-05 04:39:23 +00:00
|
|
|
if (!psinfo)
|
2008-01-30 12:31:45 +00:00
|
|
|
return 0;
|
2009-07-01 05:06:26 +00:00
|
|
|
fill_note(&info->psinfo, "CORE", NT_PRPSINFO, sizeof(*psinfo), psinfo);
|
|
|
|
|
2022-09-05 04:41:05 +00:00
|
|
|
#ifdef CORE_DUMP_USE_REGSET
|
|
|
|
view = task_user_regset_view(dump_task);
|
|
|
|
|
2008-01-30 12:31:45 +00:00
|
|
|
/*
|
|
|
|
* Figure out how many notes we're going to need for each thread.
|
|
|
|
*/
|
|
|
|
info->thread_notes = 0;
|
2022-09-05 04:39:23 +00:00
|
|
|
for (int i = 0; i < view->n; ++i)
|
2008-01-30 12:31:45 +00:00
|
|
|
if (view->regsets[i].core_note_type != 0)
|
|
|
|
++info->thread_notes;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sanity check. We rely on regset 0 being in NT_PRSTATUS,
|
|
|
|
* since it is our one special case.
|
|
|
|
*/
|
|
|
|
if (unlikely(info->thread_notes == 0) ||
|
|
|
|
unlikely(view->regsets[0].core_note_type != NT_PRSTATUS)) {
|
|
|
|
WARN_ON(1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize the ELF file header.
|
|
|
|
*/
|
|
|
|
fill_elf_header(elf, phdrs,
|
2013-02-22 00:44:20 +00:00
|
|
|
view->e_machine, view->e_flags);
|
2022-09-05 04:41:05 +00:00
|
|
|
#else
|
|
|
|
view = NULL;
|
|
|
|
info->thread_notes = 2;
|
|
|
|
fill_elf_header(elf, phdrs, ELF_ARCH, ELF_CORE_EFLAGS);
|
|
|
|
#endif
|
2008-01-30 12:31:45 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate a structure for each thread.
|
|
|
|
*/
|
2020-06-08 17:44:16 +00:00
|
|
|
info->thread = kzalloc(offsetof(struct elf_thread_core_info,
|
|
|
|
notes[info->thread_notes]),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (unlikely(!info->thread))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
info->thread->task = dump_task;
|
|
|
|
for (ct = dump_task->signal->core_state->dumper.next; ct; ct = ct->next) {
|
2008-07-25 08:47:45 +00:00
|
|
|
t = kzalloc(offsetof(struct elf_thread_core_info,
|
|
|
|
notes[info->thread_notes]),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (unlikely(!t))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
t->task = ct->task;
|
2020-06-08 17:44:16 +00:00
|
|
|
t->next = info->thread->next;
|
|
|
|
info->thread->next = t;
|
2008-07-25 08:47:45 +00:00
|
|
|
}
|
2008-01-30 12:31:45 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now fill in each thread's information.
|
|
|
|
*/
|
|
|
|
for (t = info->thread; t != NULL; t = t->next)
|
binfmt_elf: Don't write past end of notes for regset gap
In fill_thread_core_info() the ptrace accessible registers are collected
to be written out as notes in a core file. The note array is allocated
from a size calculated by iterating the user regset view, and counting the
regsets that have a non-zero core_note_type. However, this only allows for
there to be non-zero core_note_type at the end of the regset view. If
there are any gaps in the middle, fill_thread_core_info() will overflow the
note allocation, as it iterates over the size of the view and the
allocation would be smaller than that.
There doesn't appear to be any arch that has gaps such that they exceed
the notes allocation, but the code is brittle and tries to support
something it doesn't. It could be fixed by increasing the allocation size,
but instead just have the note collecting code utilize the array better.
This way the allocation can stay smaller.
Even in the case of no arch's that have gaps in their regset views, this
introduces a change in the resulting indicies of t->notes. It does not
introduce any changes to the core file itself, because any blank notes are
skipped in write_note_info().
In case, the allocation logic between fill_note_info() and
fill_thread_core_info() ever diverges from the usage logic, warn and skip
writing any notes that would overflow the array.
This fix is derrived from an earlier one[0] by Yu-cheng Yu.
[0] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
2022-03-17 19:20:13 +00:00
|
|
|
if (!fill_thread_core_info(t, view, cprm->siginfo->si_signo, info))
|
2008-01-30 12:31:45 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fill in the two process-wide notes.
|
|
|
|
*/
|
|
|
|
fill_psinfo(psinfo, dump_task->group_leader, dump_task->mm);
|
|
|
|
info->size += notesize(&info->psinfo);
|
|
|
|
|
2022-01-31 18:17:38 +00:00
|
|
|
fill_siginfo_note(&info->signote, &info->csigdata, cprm->siginfo);
|
2012-10-05 00:15:35 +00:00
|
|
|
info->size += notesize(&info->signote);
|
|
|
|
|
2008-01-30 12:31:45 +00:00
|
|
|
fill_auxv_note(&info->auxv, current->mm);
|
|
|
|
info->size += notesize(&info->auxv);
|
|
|
|
|
2022-03-08 19:04:19 +00:00
|
|
|
if (fill_files_note(&info->files, cprm) == 0)
|
2013-09-30 20:45:02 +00:00
|
|
|
info->size += notesize(&info->files);
|
2012-10-05 00:15:36 +00:00
|
|
|
|
2008-01-30 12:31:45 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write all the notes for each thread. When writing the first thread, the
|
|
|
|
* process-wide notes are interleaved after the first thread-specific note.
|
|
|
|
*/
|
|
|
|
static int write_note_info(struct elf_note_info *info,
|
2013-10-05 19:32:35 +00:00
|
|
|
struct coredump_params *cprm)
|
2008-01-30 12:31:45 +00:00
|
|
|
{
|
2014-06-04 23:12:14 +00:00
|
|
|
bool first = true;
|
2008-01-30 12:31:45 +00:00
|
|
|
struct elf_thread_core_info *t = info->thread;
|
|
|
|
|
|
|
|
do {
|
|
|
|
int i;
|
|
|
|
|
2013-10-05 19:32:35 +00:00
|
|
|
if (!writenote(&t->notes[0], cprm))
|
2008-01-30 12:31:45 +00:00
|
|
|
return 0;
|
|
|
|
|
2013-10-05 19:32:35 +00:00
|
|
|
if (first && !writenote(&info->psinfo, cprm))
|
2008-01-30 12:31:45 +00:00
|
|
|
return 0;
|
2013-10-05 19:32:35 +00:00
|
|
|
if (first && !writenote(&info->signote, cprm))
|
2012-10-05 00:15:35 +00:00
|
|
|
return 0;
|
2013-10-05 19:32:35 +00:00
|
|
|
if (first && !writenote(&info->auxv, cprm))
|
2008-01-30 12:31:45 +00:00
|
|
|
return 0;
|
2013-09-30 20:45:02 +00:00
|
|
|
if (first && info->files.data &&
|
2013-10-05 19:32:35 +00:00
|
|
|
!writenote(&info->files, cprm))
|
2012-10-05 00:15:36 +00:00
|
|
|
return 0;
|
2008-01-30 12:31:45 +00:00
|
|
|
|
|
|
|
for (i = 1; i < info->thread_notes; ++i)
|
|
|
|
if (t->notes[i].data &&
|
2013-10-05 19:32:35 +00:00
|
|
|
!writenote(&t->notes[i], cprm))
|
2008-01-30 12:31:45 +00:00
|
|
|
return 0;
|
|
|
|
|
2014-06-04 23:12:14 +00:00
|
|
|
first = false;
|
2008-01-30 12:31:45 +00:00
|
|
|
t = t->next;
|
|
|
|
} while (t);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_note_info(struct elf_note_info *info)
|
|
|
|
{
|
|
|
|
struct elf_thread_core_info *threads = info->thread;
|
|
|
|
while (threads) {
|
|
|
|
unsigned int i;
|
|
|
|
struct elf_thread_core_info *t = threads;
|
|
|
|
threads = t->next;
|
|
|
|
WARN_ON(t->notes[0].data && t->notes[0].data != &t->prstatus);
|
|
|
|
for (i = 1; i < info->thread_notes; ++i)
|
|
|
|
kfree(t->notes[i].data);
|
|
|
|
kfree(t);
|
|
|
|
}
|
|
|
|
kfree(info->psinfo.data);
|
2018-06-14 22:27:24 +00:00
|
|
|
kvfree(info->files.data);
|
2008-01-30 12:31:45 +00:00
|
|
|
}
|
|
|
|
|
2010-03-05 21:44:10 +00:00
|
|
|
static void fill_extnum_info(struct elfhdr *elf, struct elf_shdr *shdr4extnum,
|
|
|
|
elf_addr_t e_shoff, int segs)
|
|
|
|
{
|
|
|
|
elf->e_shoff = e_shoff;
|
|
|
|
elf->e_shentsize = sizeof(*shdr4extnum);
|
|
|
|
elf->e_shnum = 1;
|
|
|
|
elf->e_shstrndx = SHN_UNDEF;
|
|
|
|
|
|
|
|
memset(shdr4extnum, 0, sizeof(*shdr4extnum));
|
|
|
|
|
|
|
|
shdr4extnum->sh_type = SHT_NULL;
|
|
|
|
shdr4extnum->sh_size = elf->e_shnum;
|
|
|
|
shdr4extnum->sh_link = elf->e_shstrndx;
|
|
|
|
shdr4extnum->sh_info = segs;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Actual dumper
|
|
|
|
*
|
|
|
|
* This is a two-pass process; first we find the offsets of the bits,
|
|
|
|
* and then they are actually written out. If we run out of core limit
|
|
|
|
* we just truncate.
|
|
|
|
*/
|
2009-12-17 23:27:16 +00:00
|
|
|
static int elf_core_dump(struct coredump_params *cprm)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
int has_dumped = 0;
|
2022-03-08 18:55:29 +00:00
|
|
|
int segs, i;
|
2020-01-31 06:17:04 +00:00
|
|
|
struct elfhdr elf;
|
2013-10-06 02:24:29 +00:00
|
|
|
loff_t offset = 0, dataoff;
|
2013-09-30 20:45:02 +00:00
|
|
|
struct elf_note_info info = { };
|
2010-03-05 21:44:09 +00:00
|
|
|
struct elf_phdr *phdr4note = NULL;
|
2010-03-05 21:44:10 +00:00
|
|
|
struct elf_shdr *shdr4extnum = NULL;
|
|
|
|
Elf_Half e_phnum;
|
|
|
|
elf_addr_t e_shoff;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-06-30 18:41:23 +00:00
|
|
|
/*
|
|
|
|
* The number of segs are recored into ELF header as 16bit value.
|
|
|
|
* Please check DEFAULT_MAX_MAP_COUNT definition when you modify here.
|
|
|
|
*/
|
2022-12-22 18:12:50 +00:00
|
|
|
segs = cprm->vma_count + elf_core_extra_phdrs(cprm);
|
2007-01-26 08:56:49 +00:00
|
|
|
|
2010-03-05 21:44:10 +00:00
|
|
|
/* for notes section */
|
|
|
|
segs++;
|
|
|
|
|
|
|
|
/* If segs > PN_XNUM(0xffff), then e_phnum overflows. To avoid
|
|
|
|
* this, kernel supports extended numbering. Have a look at
|
|
|
|
* include/linux/elf.h for further information. */
|
|
|
|
e_phnum = segs > PN_XNUM ? PN_XNUM : segs;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2008-01-30 12:31:44 +00:00
|
|
|
* Collect all the non-memory information about the process for the
|
|
|
|
* notes. This also sets up the file header.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2022-01-31 18:17:38 +00:00
|
|
|
if (!fill_note_info(&elf, e_phnum, &info, cprm))
|
2020-05-05 10:12:55 +00:00
|
|
|
goto end_coredump;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-01-30 12:31:44 +00:00
|
|
|
has_dumped = 1;
|
2013-04-30 22:28:16 +00:00
|
|
|
|
2023-02-28 12:14:17 +00:00
|
|
|
offset += sizeof(elf); /* ELF header */
|
2010-03-05 21:44:10 +00:00
|
|
|
offset += segs * sizeof(struct elf_phdr); /* Program headers */
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Write notes phdr entry */
|
|
|
|
{
|
2022-09-05 03:24:11 +00:00
|
|
|
size_t sz = info.size;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2020-11-25 21:51:32 +00:00
|
|
|
/* For cell spufs */
|
[POWERPC] spufs: Cleanup ELF coredump extra notes logic
To start with, arch_notes_size() etc. is a little too ambiguous a name for
my liking, so change the function names to be more explicit.
Calling through macros is ugly, especially with hidden parameters, so don't
do that, call the routines directly.
Use ARCH_HAVE_EXTRA_ELF_NOTES as the only flag, and based on it decide
whether we want the extern declarations or the empty versions.
Since we have empty routines, actually use them in the coredump code to
save a few #ifdefs.
We want to change the handling of foffset so that the write routine updates
foffset as it goes, instead of using file->f_pos (so that writing to a pipe
works). So pass foffset to the write routine, and for now just set it to
file->f_pos at the end of writing.
It should also be possible for the write routine to fail, so change it to
return int and treat a non-zero return as failure.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-19 04:38:12 +00:00
|
|
|
sz += elf_coredump_extra_notes_size();
|
[POWERPC] coredump: Add SPU elf notes to coredump.
This patch adds SPU elf notes to the coredump. It creates a separate note
for each of /regs, /fpcr, /lslr, /decr, /decr_status, /mem, /signal1,
/signal1_type, /signal2, /signal2_type, /event_mask, /event_status,
/mbox_info, /ibox_info, /wbox_info, /dma_info, /proxydma_info, /object-id.
A new macro, ARCH_HAVE_EXTRA_NOTES, was created for architectures to
specify they have extra elf core notes.
A new macro, ELF_CORE_EXTRA_NOTES_SIZE, was created so the size of the
additional notes could be calculated and added to the notes phdr entry.
A new macro, ELF_CORE_WRITE_EXTRA_NOTES, was created so the new notes
would be written after the existing notes.
The SPU coredump code resides in spufs. Stub functions are provided in the
kernel which are hooked into the spufs code which does the actual work via
register_arch_coredump_calls().
A new set of __spufs_<file>_read/get() functions was provided to allow the
coredump code to read from the spufs files without having to lock the
SPU context for each file read from.
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Dwayne Grant McConnell <decimal@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
2006-11-22 23:46:37 +00:00
|
|
|
|
2010-03-05 21:44:09 +00:00
|
|
|
phdr4note = kmalloc(sizeof(*phdr4note), GFP_KERNEL);
|
|
|
|
if (!phdr4note)
|
2010-03-05 21:44:06 +00:00
|
|
|
goto end_coredump;
|
2010-03-05 21:44:09 +00:00
|
|
|
|
|
|
|
fill_elf_note_phdr(phdr4note, sz, offset);
|
|
|
|
offset += sz;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
|
|
|
|
|
2022-03-08 18:55:29 +00:00
|
|
|
offset += cprm->vma_data_size;
|
2022-12-22 18:12:50 +00:00
|
|
|
offset += elf_core_extra_data_size(cprm);
|
2010-03-05 21:44:10 +00:00
|
|
|
e_shoff = offset;
|
|
|
|
|
|
|
|
if (e_phnum == PN_XNUM) {
|
|
|
|
shdr4extnum = kmalloc(sizeof(*shdr4extnum), GFP_KERNEL);
|
|
|
|
if (!shdr4extnum)
|
|
|
|
goto end_coredump;
|
2020-01-31 06:17:04 +00:00
|
|
|
fill_extnum_info(&elf, shdr4extnum, e_shoff, segs);
|
2010-03-05 21:44:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
offset = dataoff;
|
|
|
|
|
2020-01-31 06:17:04 +00:00
|
|
|
if (!dump_emit(cprm, &elf, sizeof(elf)))
|
2010-03-05 21:44:09 +00:00
|
|
|
goto end_coredump;
|
|
|
|
|
2013-10-05 19:32:35 +00:00
|
|
|
if (!dump_emit(cprm, phdr4note, sizeof(*phdr4note)))
|
2010-03-05 21:44:09 +00:00
|
|
|
goto end_coredump;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Write program headers for segments dump */
|
2022-03-08 18:55:29 +00:00
|
|
|
for (i = 0; i < cprm->vma_count; i++) {
|
|
|
|
struct core_vma_metadata *meta = cprm->vma_meta + i;
|
2005-04-16 22:20:36 +00:00
|
|
|
struct elf_phdr phdr;
|
|
|
|
|
|
|
|
phdr.p_type = PT_LOAD;
|
|
|
|
phdr.p_offset = offset;
|
binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot
In both binfmt_elf and binfmt_elf_fdpic, use a new helper
dump_vma_snapshot() to take a snapshot of the VMA list (including the gate
VMA, if we have one) while protected by the mmap_lock, and then use that
snapshot instead of walking the VMA list without locking.
An alternative approach would be to keep the mmap_lock held across the
entire core dumping operation; however, keeping the mmap_lock locked while
we may be blocked for an unbounded amount of time (e.g. because we're
dumping to a FUSE filesystem or so) isn't really optimal; the mmap_lock
blocks things like the ->release handler of userfaultfd, and we don't
really want critical system daemons to grind to a halt just because
someone "gifted" them SCM_RIGHTS to an eternally-locked userfaultfd, or
something like that.
Since both the normal ELF code and the FDPIC ELF code need this
functionality (and if any other binfmt wants to add coredump support in
the future, they'd probably need it, too), implement this with a common
helper in fs/coredump.c.
A downside of this approach is that we now need a bigger amount of kernel
memory per userspace VMA in the normal ELF case, and that we need O(n)
kernel memory in the FDPIC ELF case at all; but 40 bytes per VMA shouldn't
be terribly bad.
There currently is a data race between stack expansion and anything that
reads ->vm_start or ->vm_end under the mmap_lock held in read mode; to
mitigate that for core dumping, take the mmap_lock in write mode when
taking a snapshot of the VMA hierarchy. (If we only took the mmap_lock in
read mode, we could end up with a corrupted core dump if someone does
get_user_pages_remote() concurrently. Not really a major problem, but
taking the mmap_lock either way works here, so we might as well avoid the
issue.) (This doesn't do anything about the existing data races with stack
expansion in other mm code.)
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Link: http://lkml.kernel.org/r/20200827114932.3572699-6-jannh@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:12:54 +00:00
|
|
|
phdr.p_vaddr = meta->start;
|
2005-04-16 22:20:36 +00:00
|
|
|
phdr.p_paddr = 0;
|
binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot
In both binfmt_elf and binfmt_elf_fdpic, use a new helper
dump_vma_snapshot() to take a snapshot of the VMA list (including the gate
VMA, if we have one) while protected by the mmap_lock, and then use that
snapshot instead of walking the VMA list without locking.
An alternative approach would be to keep the mmap_lock held across the
entire core dumping operation; however, keeping the mmap_lock locked while
we may be blocked for an unbounded amount of time (e.g. because we're
dumping to a FUSE filesystem or so) isn't really optimal; the mmap_lock
blocks things like the ->release handler of userfaultfd, and we don't
really want critical system daemons to grind to a halt just because
someone "gifted" them SCM_RIGHTS to an eternally-locked userfaultfd, or
something like that.
Since both the normal ELF code and the FDPIC ELF code need this
functionality (and if any other binfmt wants to add coredump support in
the future, they'd probably need it, too), implement this with a common
helper in fs/coredump.c.
A downside of this approach is that we now need a bigger amount of kernel
memory per userspace VMA in the normal ELF case, and that we need O(n)
kernel memory in the FDPIC ELF case at all; but 40 bytes per VMA shouldn't
be terribly bad.
There currently is a data race between stack expansion and anything that
reads ->vm_start or ->vm_end under the mmap_lock held in read mode; to
mitigate that for core dumping, take the mmap_lock in write mode when
taking a snapshot of the VMA hierarchy. (If we only took the mmap_lock in
read mode, we could end up with a corrupted core dump if someone does
get_user_pages_remote() concurrently. Not really a major problem, but
taking the mmap_lock either way works here, so we might as well avoid the
issue.) (This doesn't do anything about the existing data races with stack
expansion in other mm code.)
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Link: http://lkml.kernel.org/r/20200827114932.3572699-6-jannh@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:12:54 +00:00
|
|
|
phdr.p_filesz = meta->dump_size;
|
|
|
|
phdr.p_memsz = meta->end - meta->start;
|
2005-04-16 22:20:36 +00:00
|
|
|
offset += phdr.p_filesz;
|
binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot
In both binfmt_elf and binfmt_elf_fdpic, use a new helper
dump_vma_snapshot() to take a snapshot of the VMA list (including the gate
VMA, if we have one) while protected by the mmap_lock, and then use that
snapshot instead of walking the VMA list without locking.
An alternative approach would be to keep the mmap_lock held across the
entire core dumping operation; however, keeping the mmap_lock locked while
we may be blocked for an unbounded amount of time (e.g. because we're
dumping to a FUSE filesystem or so) isn't really optimal; the mmap_lock
blocks things like the ->release handler of userfaultfd, and we don't
really want critical system daemons to grind to a halt just because
someone "gifted" them SCM_RIGHTS to an eternally-locked userfaultfd, or
something like that.
Since both the normal ELF code and the FDPIC ELF code need this
functionality (and if any other binfmt wants to add coredump support in
the future, they'd probably need it, too), implement this with a common
helper in fs/coredump.c.
A downside of this approach is that we now need a bigger amount of kernel
memory per userspace VMA in the normal ELF case, and that we need O(n)
kernel memory in the FDPIC ELF case at all; but 40 bytes per VMA shouldn't
be terribly bad.
There currently is a data race between stack expansion and anything that
reads ->vm_start or ->vm_end under the mmap_lock held in read mode; to
mitigate that for core dumping, take the mmap_lock in write mode when
taking a snapshot of the VMA hierarchy. (If we only took the mmap_lock in
read mode, we could end up with a corrupted core dump if someone does
get_user_pages_remote() concurrently. Not really a major problem, but
taking the mmap_lock either way works here, so we might as well avoid the
issue.) (This doesn't do anything about the existing data races with stack
expansion in other mm code.)
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Link: http://lkml.kernel.org/r/20200827114932.3572699-6-jannh@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:12:54 +00:00
|
|
|
phdr.p_flags = 0;
|
|
|
|
if (meta->flags & VM_READ)
|
|
|
|
phdr.p_flags |= PF_R;
|
|
|
|
if (meta->flags & VM_WRITE)
|
2006-06-23 09:05:35 +00:00
|
|
|
phdr.p_flags |= PF_W;
|
binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot
In both binfmt_elf and binfmt_elf_fdpic, use a new helper
dump_vma_snapshot() to take a snapshot of the VMA list (including the gate
VMA, if we have one) while protected by the mmap_lock, and then use that
snapshot instead of walking the VMA list without locking.
An alternative approach would be to keep the mmap_lock held across the
entire core dumping operation; however, keeping the mmap_lock locked while
we may be blocked for an unbounded amount of time (e.g. because we're
dumping to a FUSE filesystem or so) isn't really optimal; the mmap_lock
blocks things like the ->release handler of userfaultfd, and we don't
really want critical system daemons to grind to a halt just because
someone "gifted" them SCM_RIGHTS to an eternally-locked userfaultfd, or
something like that.
Since both the normal ELF code and the FDPIC ELF code need this
functionality (and if any other binfmt wants to add coredump support in
the future, they'd probably need it, too), implement this with a common
helper in fs/coredump.c.
A downside of this approach is that we now need a bigger amount of kernel
memory per userspace VMA in the normal ELF case, and that we need O(n)
kernel memory in the FDPIC ELF case at all; but 40 bytes per VMA shouldn't
be terribly bad.
There currently is a data race between stack expansion and anything that
reads ->vm_start or ->vm_end under the mmap_lock held in read mode; to
mitigate that for core dumping, take the mmap_lock in write mode when
taking a snapshot of the VMA hierarchy. (If we only took the mmap_lock in
read mode, we could end up with a corrupted core dump if someone does
get_user_pages_remote() concurrently. Not really a major problem, but
taking the mmap_lock either way works here, so we might as well avoid the
issue.) (This doesn't do anything about the existing data races with stack
expansion in other mm code.)
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Link: http://lkml.kernel.org/r/20200827114932.3572699-6-jannh@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:12:54 +00:00
|
|
|
if (meta->flags & VM_EXEC)
|
2006-06-23 09:05:35 +00:00
|
|
|
phdr.p_flags |= PF_X;
|
2005-04-16 22:20:36 +00:00
|
|
|
phdr.p_align = ELF_EXEC_PAGESIZE;
|
|
|
|
|
2013-10-05 19:32:35 +00:00
|
|
|
if (!dump_emit(cprm, &phdr, sizeof(phdr)))
|
2010-03-05 21:44:06 +00:00
|
|
|
goto end_coredump;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2013-10-05 21:22:57 +00:00
|
|
|
if (!elf_core_write_extra_phdrs(cprm, offset))
|
2010-03-05 21:44:07 +00:00
|
|
|
goto end_coredump;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-10-18 07:14:20 +00:00
|
|
|
/* write out the notes section */
|
2013-10-05 19:32:35 +00:00
|
|
|
if (!write_note_info(&info, cprm))
|
2008-01-30 12:31:44 +00:00
|
|
|
goto end_coredump;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2020-11-25 21:51:32 +00:00
|
|
|
/* For cell spufs */
|
2013-10-06 02:24:29 +00:00
|
|
|
if (elf_coredump_extra_notes_write(cprm))
|
[POWERPC] spufs: Cleanup ELF coredump extra notes logic
To start with, arch_notes_size() etc. is a little too ambiguous a name for
my liking, so change the function names to be more explicit.
Calling through macros is ugly, especially with hidden parameters, so don't
do that, call the routines directly.
Use ARCH_HAVE_EXTRA_ELF_NOTES as the only flag, and based on it decide
whether we want the extern declarations or the empty versions.
Since we have empty routines, actually use them in the coredump code to
save a few #ifdefs.
We want to change the handling of foffset so that the write routine updates
foffset as it goes, instead of using file->f_pos (so that writing to a pipe
works). So pass foffset to the write routine, and for now just set it to
file->f_pos at the end of writing.
It should also be possible for the write routine to fail, so change it to
return int and treat a non-zero return as failure.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-19 04:38:12 +00:00
|
|
|
goto end_coredump;
|
[POWERPC] coredump: Add SPU elf notes to coredump.
This patch adds SPU elf notes to the coredump. It creates a separate note
for each of /regs, /fpcr, /lslr, /decr, /decr_status, /mem, /signal1,
/signal1_type, /signal2, /signal2_type, /event_mask, /event_status,
/mbox_info, /ibox_info, /wbox_info, /dma_info, /proxydma_info, /object-id.
A new macro, ARCH_HAVE_EXTRA_NOTES, was created for architectures to
specify they have extra elf core notes.
A new macro, ELF_CORE_EXTRA_NOTES_SIZE, was created so the size of the
additional notes could be calculated and added to the notes phdr entry.
A new macro, ELF_CORE_WRITE_EXTRA_NOTES, was created so the new notes
would be written after the existing notes.
The SPU coredump code resides in spufs. Stub functions are provided in the
kernel which are hooked into the spufs code which does the actual work via
register_arch_coredump_calls().
A new set of __spufs_<file>_read/get() functions was provided to allow the
coredump code to read from the spufs files without having to lock the
SPU context for each file read from.
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Dwayne Grant McConnell <decimal@us.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
2006-11-22 23:46:37 +00:00
|
|
|
|
2006-10-01 06:29:28 +00:00
|
|
|
/* Align to page */
|
2020-03-08 13:16:37 +00:00
|
|
|
dump_skip_to(cprm, dataoff);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-03-08 18:55:29 +00:00
|
|
|
for (i = 0; i < cprm->vma_count; i++) {
|
|
|
|
struct core_vma_metadata *meta = cprm->vma_meta + i;
|
binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot
In both binfmt_elf and binfmt_elf_fdpic, use a new helper
dump_vma_snapshot() to take a snapshot of the VMA list (including the gate
VMA, if we have one) while protected by the mmap_lock, and then use that
snapshot instead of walking the VMA list without locking.
An alternative approach would be to keep the mmap_lock held across the
entire core dumping operation; however, keeping the mmap_lock locked while
we may be blocked for an unbounded amount of time (e.g. because we're
dumping to a FUSE filesystem or so) isn't really optimal; the mmap_lock
blocks things like the ->release handler of userfaultfd, and we don't
really want critical system daemons to grind to a halt just because
someone "gifted" them SCM_RIGHTS to an eternally-locked userfaultfd, or
something like that.
Since both the normal ELF code and the FDPIC ELF code need this
functionality (and if any other binfmt wants to add coredump support in
the future, they'd probably need it, too), implement this with a common
helper in fs/coredump.c.
A downside of this approach is that we now need a bigger amount of kernel
memory per userspace VMA in the normal ELF case, and that we need O(n)
kernel memory in the FDPIC ELF case at all; but 40 bytes per VMA shouldn't
be terribly bad.
There currently is a data race between stack expansion and anything that
reads ->vm_start or ->vm_end under the mmap_lock held in read mode; to
mitigate that for core dumping, take the mmap_lock in write mode when
taking a snapshot of the VMA hierarchy. (If we only took the mmap_lock in
read mode, we could end up with a corrupted core dump if someone does
get_user_pages_remote() concurrently. Not really a major problem, but
taking the mmap_lock either way works here, so we might as well avoid the
issue.) (This doesn't do anything about the existing data races with stack
expansion in other mm code.)
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Link: http://lkml.kernel.org/r/20200827114932.3572699-6-jannh@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-16 03:12:54 +00:00
|
|
|
|
|
|
|
if (!dump_user_range(cprm, meta->start, meta->dump_size))
|
2020-10-16 03:12:46 +00:00
|
|
|
goto end_coredump;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2013-10-05 21:50:15 +00:00
|
|
|
if (!elf_core_write_extra_data(cprm))
|
2010-03-05 21:44:07 +00:00
|
|
|
goto end_coredump;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-03-05 21:44:10 +00:00
|
|
|
if (e_phnum == PN_XNUM) {
|
2013-10-05 22:08:47 +00:00
|
|
|
if (!dump_emit(cprm, shdr4extnum, sizeof(*shdr4extnum)))
|
2010-03-05 21:44:10 +00:00
|
|
|
goto end_coredump;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
end_coredump:
|
2008-01-30 12:31:44 +00:00
|
|
|
free_note_info(&info);
|
2010-03-05 21:44:10 +00:00
|
|
|
kfree(shdr4extnum);
|
2010-03-05 21:44:09 +00:00
|
|
|
kfree(phdr4note);
|
2005-04-16 22:20:36 +00:00
|
|
|
return has_dumped;
|
|
|
|
}
|
|
|
|
|
2009-12-16 00:47:37 +00:00
|
|
|
#endif /* CONFIG_ELF_CORE */
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
static int __init init_elf_binfmt(void)
|
|
|
|
{
|
2012-03-17 07:05:16 +00:00
|
|
|
register_binfmt(&elf_format);
|
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit exit_elf_binfmt(void)
|
|
|
|
{
|
|
|
|
/* Remove the COFF and ELF loaders. */
|
|
|
|
unregister_binfmt(&elf_format);
|
|
|
|
}
|
|
|
|
|
|
|
|
core_initcall(init_elf_binfmt);
|
|
|
|
module_exit(exit_elf_binfmt);
|
2022-02-24 03:32:10 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_BINFMT_ELF_KUNIT_TEST
|
|
|
|
#include "binfmt_elf_test.c"
|
|
|
|
#endif
|