06 Jan, 2021

4 commits

  • not defined by any architecture (and never had been)

    Signed-off-by: Al Viro

    Al Viro
     
  • It's not used anywhere downstream (and never had been, AFAICS).
    Theoretically, fs/binfmt_elf.c does use it, but only in the
    non-regset coredump handling and all biarch architectures
    end up with that ifdefed out.

    Signed-off-by: Al Viro

    Al Viro
     
  • To get rid of hardcoded size/offset in those macros we need to have
    a definition of i386 variant of struct elf_prstatus. However, we can't
    do that in asm/compat.h - the types needed for that are not there and
    adding an include of asm/user32.h into asm/compat.h would cause a lot
    of mess.

    That could be conveniently done in elfcore-compat.h, but currently there
    is nowhere to put arch-dependent parts of it - no asm/elfcore-compat.h.
    So we introduce a new file (asm/elfcore-compat.h, present on architectures
    that have CONFIG_ARCH_HAS_ELFCORE_COMPAT set, currently only on x86),
    have it pulled by linux/elfcore-compat.h and move the definitions there.

    As a side benefit, we don't need to worry about accidental inclusion of
    that file into binfmt_elf.c itself, so we don't need the dance with
    COMPAT_PRSTATUS_SIZE, etc. - only fs/compat_binfmt_elf.c will see
    that header.

    Signed-off-by: Al Viro

    Al Viro
     
  • Preparations to doing i386 compat elf_prstatus sanely - rather than duplicating
    the beginning of compat_elf_prstatus, take these fields into a separate
    structure (compat_elf_prstatus_common), so that it could be reused. Due to
    the incestous relationship between binfmt_elf.c and compat_binfmt_elf.c we
    need the same shape change done to native struct elf_prstatus, gathering the
    fields prior to pr_reg into a new structure (struct elf_prstatus_common).

    Fortunately, offset of pr_reg is always a multiple of 16 with no padding
    right before it, so it's possible to turn all the stuff prior to it into
    a single member without disturbing the layout.

    [build fix from Geert Uytterhoeven folded in]

    Signed-off-by: Al Viro

    Al Viro
     

05 Jan, 2021

1 commit

  • 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

    Al Viro
     

26 Oct, 2020

2 commits

  • Like it is done for SET_PERSONALITY with ARM, which requires the ELF
    header to select correct personality parameters, x86 requires the
    headers when selecting which VDSO to load, instead of relying on the
    going-away TIF_IA32/X32 flags.

    Add an indirection macro to arch_setup_additional_pages(), that x86 can
    reimplement to receive the extra parameter just for ELF files. This
    requires no changes to other architectures, who can continue to use the
    original arch_setup_additional_pages for ELF and non-ELF binaries.

    Signed-off-by: Gabriel Krisman Bertazi
    Signed-off-by: Thomas Gleixner
    Link: https://lore.kernel.org/r/20201004032536.1229030-8-krisman@collabora.com

    Gabriel Krisman Bertazi
     
  • Like it is done for SET_PERSONALITY with x86, which requires the ELF header
    to select correct personality parameters, x86 requires the headers on
    compat_start_thread() to choose starting CS for ELF32 binaries, instead of
    relying on the going-away TIF_IA32/X32 flags.

    Add an indirection macro to ELF invocations of START_THREAD, that x86 can
    reimplement to receive the extra parameter just for ELF files. This
    requires no changes to other architectures who don't need the header
    information, they can continue to use the original start_thread for ELF and
    non-ELF binaries, and it prevents affecting non-ELF code paths for x86.

    Signed-off-by: Gabriel Krisman Bertazi
    Signed-off-by: Thomas Gleixner
    Link: https://lore.kernel.org/r/20201004032536.1229030-6-krisman@collabora.com

    Gabriel Krisman Bertazi
     

06 Jun, 2020

1 commit

  • Pull READ_IMPLIES_EXEC changes from Borislav Petkov:
    "Split the old READ_IMPLIES_EXEC workaround from executable
    PT_GNU_STACK now that toolchains long support PT_GNU_STACK marking and
    there's no need anymore to force modern programs into having all its
    user mappings executable instead of only the stack and the PROT_EXEC
    ones.

    Disable that automatic READ_IMPLIES_EXEC forcing on x86-64 and
    arm64.

    Add tables documenting how READ_IMPLIES_EXEC is handled on x86-64, arm
    and arm64.

    By Kees Cook"

    * tag 'core_core_updates_for_5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    arm64/elf: Disable automatic READ_IMPLIES_EXEC for 64-bit address spaces
    arm32/64/elf: Split READ_IMPLIES_EXEC from executable PT_GNU_STACK
    arm32/64/elf: Add tables to document READ_IMPLIES_EXEC
    x86/elf: Disable automatic READ_IMPLIES_EXEC on 64-bit
    x86/elf: Split READ_IMPLIES_EXEC from executable PT_GNU_STACK
    x86/elf: Add table to document READ_IMPLIES_EXEC

    Linus Torvalds
     

02 Jun, 2020

1 commit

  • Pull uaccess/coredump updates from Al Viro:
    "set_fs() removal in coredump-related area - mostly Christoph's
    stuff..."

    * 'work.set_fs-exec' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    binfmt_elf_fdpic: remove the set_fs(KERNEL_DS) in elf_fdpic_core_dump
    binfmt_elf: remove the set_fs(KERNEL_DS) in elf_core_dump
    binfmt_elf: remove the set_fs in fill_siginfo_note
    signal: refactor copy_siginfo_to_user32
    powerpc/spufs: simplify spufs core dumping
    powerpc/spufs: stop using access_ok
    powerpc/spufs: fix copy_to_user while atomic

    Linus Torvalds
     

06 May, 2020

1 commit

  • The code in binfmt_elf.c is differnt from the rest of the code that
    processes siginfo, as it sends siginfo from a kernel buffer to a file
    rather than from kernel memory to userspace buffers. To remove it's
    use of set_fs the code needs some different siginfo helpers.

    Add the helper copy_siginfo_to_external to copy from the kernel's
    internal siginfo layout to a buffer in the siginfo layout that
    userspace expects.

    Modify fill_siginfo_note to use copy_siginfo_to_external instead of
    set_fs and copy_siginfo_to_user.

    Update compat_binfmt_elf.c to use the previously added
    copy_siginfo_to_external32 to handle the compat case.

    Signed-off-by: "Eric W. Biederman"
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Al Viro

    Eric W. Biederman
     

21 Apr, 2020

1 commit

  • With arm64 64-bit environments, there should never be a need for automatic
    READ_IMPLIES_EXEC, as the architecture has always been execute-bit aware
    (as in, the default memory protection should be NX unless a region
    explicitly requests to be executable).

    Suggested-by: Hector Marco-Gisbert
    Signed-off-by: Kees Cook
    Signed-off-by: Borislav Petkov
    Reviewed-by: Jason Gunthorpe
    Reviewed-by: Catalin Marinas
    Link: https://lkml.kernel.org/r/20200327064820.12602-7-keescook@chromium.org

    Kees Cook
     

17 Mar, 2020

1 commit

  • ELF program properties will be needed for detecting whether to
    enable optional architecture or ABI features for a new ELF process.

    For now, there are no generic properties that we care about, so do
    nothing unless CONFIG_ARCH_USE_GNU_PROPERTY=y.

    Otherwise, the presence of properties using the PT_PROGRAM_PROPERTY
    phdrs entry (if any), and notify each property to the arch code.

    For now, the added code is not used.

    Signed-off-by: Mark Brown
    Signed-off-by: Dave Martin
    Reviewed-by: Kees Cook
    Signed-off-by: Catalin Marinas

    Dave Martin
     

15 Nov, 2019

1 commit

  • We store elapsed time for a crashed process in struct elf_prstatus using
    'timeval' structures. Once glibc starts using 64-bit time_t, this becomes
    incompatible with the kernel's idea of timeval since the structure layout
    no longer matches on 32-bit architectures.

    This changes the definition of the elf_prstatus structure to use
    __kernel_old_timeval instead, which is hardcoded to the currently used
    binary layout. There is no risk of overflow in y2038 though, because
    the time values are all relative times, and can store up to 68 years
    of process elapsed time.

    There is a risk of applications breaking at build time when they
    use the new kernel headers and expect the type to be exactly 'timeval'
    rather than a structure that has the same fields as before. Those
    applications have to be modified to deal with 64-bit time_t anyway.

    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this copyrighted material is made available to anyone wishing to use
    modify copy or redistribute it subject to the terms and conditions
    of the gnu general public license v 2

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 45 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Richard Fontana
    Reviewed-by: Allison Randal
    Reviewed-by: Steve Winslow
    Reviewed-by: Alexios Zavras
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190528170027.342746075@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

27 Aug, 2018

1 commit

  • Christoph Hellwig suggested a slightly different path for handling
    backwards compatibility with the 32-bit time_t based system calls:

    Rather than simply reusing the compat_sys_* entry points on 32-bit
    architectures unchanged, we get rid of those entry points and the
    compat_time types by renaming them to something that makes more sense
    on 32-bit architectures (which don't have a compat mode otherwise),
    and then share the entry points under the new name with the 64-bit
    architectures that use them for implementing the compatibility.

    The following types and interfaces are renamed here, and moved
    from linux/compat_time.h to linux/time32.h:

    old new
    --- ---
    compat_time_t old_time32_t
    struct compat_timeval struct old_timeval32
    struct compat_timespec struct old_timespec32
    struct compat_itimerspec struct old_itimerspec32
    ns_to_compat_timeval() ns_to_old_timeval32()
    get_compat_itimerspec64() get_old_itimerspec32()
    put_compat_itimerspec64() put_old_itimerspec32()
    compat_get_timespec64() get_old_timespec32()
    compat_put_timespec64() put_old_timespec32()

    As we already have aliases in place, this patch addresses only the
    instances that are relevant to the system call interface in particular,
    not those that occur in device drivers and other modules. Those
    will get handled separately, while providing the 64-bit version
    of the respective interfaces.

    I'm not renaming the timex, rusage and itimerval structures, as we are
    still debating what the new interface will look like, and whether we
    will need a replacement at all.

    This also doesn't change the names of the syscall entry points, which can
    be done more easily when we actually switch over the 32-bit architectures
    to use them, at that point we need to change COMPAT_SYSCALL_DEFINEx to
    SYSCALL_DEFINEx with a new name, e.g. with a _time32 suffix.

    Suggested-by: Christoph Hellwig
    Link: https://lore.kernel.org/lkml/20180705222110.GA5698@infradead.org/
    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     

01 Feb, 2017

1 commit

  • Use the new nsec based cputime accessors as part of the whole cputime
    conversion from cputime_t to nsecs.

    Signed-off-by: Frederic Weisbecker
    Cc: Benjamin Herrenschmidt
    Cc: Fenghua Yu
    Cc: Heiko Carstens
    Cc: Linus Torvalds
    Cc: Martin Schwidefsky
    Cc: Michael Ellerman
    Cc: Paul Mackerras
    Cc: Peter Zijlstra
    Cc: Rik van Riel
    Cc: Stanislaw Gruszka
    Cc: Thomas Gleixner
    Cc: Tony Luck
    Cc: Wanpeng Li
    Link: http://lkml.kernel.org/r/1485832191-26889-12-git-send-email-fweisbec@gmail.com
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

04 Mar, 2014

1 commit


06 Oct, 2012

2 commits

  • This note has the following format:

    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...

    Signed-off-by: Denys Vlasenko
    Cc: Oleg Nesterov
    Cc: Amerigo Wang
    Cc: "Jonathan M. Foote"
    Cc: Roland McGrath
    Cc: Pedro Alves
    Cc: Fengguang Wu
    Cc: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denys Vlasenko
     
  • Existing PRSTATUS note contains only si_signo, si_code, si_errno fields
    from the siginfo of the signal which caused core to be dumped.

    There are tools which try to analyze crashes for possible security
    implications, and they want to use, among other data, si_addr field from
    the SIGSEGV.

    This patch adds a new elf note, NT_SIGINFO, which contains the complete
    siginfo_t of the signal which killed the process.

    Signed-off-by: Denys Vlasenko
    Reviewed-by: Oleg Nesterov
    Cc: Amerigo Wang
    Cc: "Jonathan M. Foote"
    Cc: Roland McGrath
    Cc: Pedro Alves
    Cc: Fengguang Wu
    Cc: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denys Vlasenko
     

07 Mar, 2010

1 commit

  • elf_core_dump() and elf_fdpic_core_dump() use #ifdef and the corresponding
    macro for hiding _multiline_ logics in functions. This patch removes
    #ifdef and replaces ELF_CORE_EXTRA_* by corresponding functions. For
    architectures not implemeonting ELF_CORE_EXTRA_*, we use weak functions in
    order to reduce a range of modification.

    This cleanup is for my next patches, but I think this cleanup itself is
    worth doing regardless of my firnal purpose.

    Signed-off-by: Daisuke HATAYAMA
    Cc: "Luck, Tony"
    Cc: Jeff Dike
    Cc: David Howells
    Cc: Greg Ungerer
    Cc: Roland McGrath
    Cc: Oleg Nesterov
    Cc: Ingo Molnar
    Cc: Alexander Viro
    Cc: Andi Kleen
    Cc: Alan Cox
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Daisuke HATAYAMA
     

30 Jan, 2008

1 commit

  • This adds fs/compat_binfmt_elf.c, a wrapper around fs/binfmt_elf.c for
    32-bit ELF support on 64-bit kernels. It can replace all the hand-rolled
    versions of this that each 32/64 arch has, which are all about the same.

    To use this, an arch's asm/elf.h has to define at least a few compat_*
    macros that parallel the various macros that fs/binfmt_elf.c uses for
    native support.

    There is no attempt to deal with compat macros for the core dump format
    support. To use this file, the arch has to define compat_gregset_t for
    linux/elfcore-compat.h and #define CORE_DUMP_USE_REGSET. The 32-bit
    compatible formats should come automatically from task_user_regset_view
    called on a 32-bit task.

    Signed-off-by: Roland McGrath
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Roland McGrath