An error occurred fetching the project authors.
  1. 23 Jul, 2024 1 commit
  2. 21 Jun, 2024 1 commit
  3. 19 Jun, 2024 2 commits
    • Kees Cook's avatar
      binfmt_elf: Honor PT_LOAD alignment for static PIE · 3545deff
      Kees Cook authored
      The p_align values in PT_LOAD were ignored for static PIE executables
      (i.e. ET_DYN without PT_INTERP). This is because there is no way to
      request a non-fixed mmap region with a specific alignment. ET_DYN with
      PT_INTERP uses a separate base address (ELF_ET_DYN_BASE) and binfmt_elf
      performs the ASLR itself, which means it can also apply alignment. For
      the mmap region, the address selection happens deep within the vm_mmap()
      implementation (when the requested address is 0).
      
      The earlier attempt to implement this:
      
        commit 9630f0d6 ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE")
        commit 925346c1 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders")
      
      did not take into account the different base address origins, and were
      eventually reverted:
      
        aeb79237 ("revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE"")
      
      In order to get the correct alignment from an mmap base, binfmt_elf must
      perform a 0-address load first, then tear down the mapping and perform
      alignment on the resulting address. Since this is slightly more overhead,
      only do this when it is needed (i.e. the alignment is not the default
      ELF alignment). This does, however, have the benefit of being able to
      use MAP_FIXED_NOREPLACE, to avoid potential collisions.
      
      With this fixed, enable the static PIE self tests again.
      Reported-by: default avatarH.J. Lu <hjl.tools@gmail.com>
      Closes: https://bugzilla.kernel.org/show_bug.cgi?id=215275
      Link: https://lore.kernel.org/r/20240508173149.677910-3-keescook@chromium.orgSigned-off-by: default avatarKees Cook <kees@kernel.org>
      3545deff
    • Kees Cook's avatar
      binfmt_elf: Calculate total_size earlier · 2d4cf7b1
      Kees Cook authored
      In preparation to support PT_LOAD with large p_align values on
      non-PT_INTERP ET_DYN executables (i.e. "static pie"), we'll need to use
      the total_size details earlier. Move this separately now to make the
      next patch more readable. As total_size and load_bias are currently
      calculated separately, this has no behavioral impact.
      
      Link: https://lore.kernel.org/r/20240508173149.677910-2-keescook@chromium.orgSigned-off-by: default avatarKees Cook <kees@kernel.org>
      2d4cf7b1
  4. 08 May, 2024 1 commit
    • Allen Pais's avatar
      fs/coredump: Enable dynamic configuration of max file note size · 4bbf9c3b
      Allen Pais authored
      Introduce the capability to dynamically configure the maximum file
      note size for ELF core dumps via sysctl.
      
      Why is this being done?
      We have observed that during a crash when there are more than 65k mmaps
      in memory, the existing fixed limit on the size of the ELF notes section
      becomes a bottleneck. The notes section quickly reaches its capacity,
      leading to incomplete memory segment information in the resulting coredump.
      This truncation compromises the utility of the coredumps, as crucial
      information about the memory state at the time of the crash might be
      omitted.
      
      This enhancement removes the previous static limit of 4MB, allowing
      system administrators to adjust the size based on system-specific
      requirements or constraints.
      
      Eg:
      $ sysctl -a | grep core_file_note_size_limit
      kernel.core_file_note_size_limit = 4194304
      
      $ sysctl -n kernel.core_file_note_size_limit
      4194304
      
      $echo 519304 > /proc/sys/kernel/core_file_note_size_limit
      
      $sysctl -n kernel.core_file_note_size_limit
      519304
      
      Attempting to write beyond the ceiling value of 16MB
      $echo 17194304 > /proc/sys/kernel/core_file_note_size_limit
      bash: echo: write error: Invalid argument
      Signed-off-by: default avatarVijay Nag <nagvijay@microsoft.com>
      Signed-off-by: default avatarAllen Pais <apais@linux.microsoft.com>
      Link: https://lore.kernel.org/r/20240506193700.7884-1-apais@linux.microsoft.comSigned-off-by: default avatarKees Cook <keescook@chromium.org>
      4bbf9c3b
  5. 26 Apr, 2024 1 commit
    • Douglas Anderson's avatar
      regset: use kvzalloc() for regset_get_alloc() · 6b839b3b
      Douglas Anderson authored
      While browsing through ChromeOS crash reports, I found one with an
      allocation failure that looked like this:
      
        chrome: page allocation failure: order:7,
                mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
      	  nodemask=(null),cpuset=urgent,mems_allowed=0
        CPU: 7 PID: 3295 Comm: chrome Not tainted
                5.15.133-20574-g8044615ac35c #1 (HASH:1162 1)
        Hardware name: Google Lazor (rev3 - 8) with KB Backlight (DT)
        Call trace:
        ...
        warn_alloc+0x104/0x174
        __alloc_pages+0x5f0/0x6e4
        kmalloc_order+0x44/0x98
        kmalloc_order_trace+0x34/0x124
        __kmalloc+0x228/0x36c
        __regset_get+0x68/0xcc
        regset_get_alloc+0x1c/0x28
        elf_core_dump+0x3d8/0xd8c
        do_coredump+0xeb8/0x1378
        get_signal+0x14c/0x804
        ...
      
      An order 7 allocation is (1 << 7) contiguous pages, or 512K. It's not
      a surprise that this allocation failed on a system that's been running
      for a while.
      
      More digging showed that it was fairly easy to see the order 7
      allocation by just sending a SIGQUIT to chrome (or other processes) to
      generate a core dump. The actual amount being allocated was 279,584
      bytes and it was for "core_note_type" NT_ARM_SVE.
      
      There was quite a bit of discussion [1] on the mailing lists in
      response to my v1 patch attempting to switch to vmalloc. The overall
      conclusion was that we could likely reduce the 279,584 byte allocation
      by quite a bit and Mark Brown has sent a patch to that effect [2].
      However even with the 279,584 byte allocation gone there are still
      65,552 byte allocations. These are just barely more than the 65,536
      bytes and thus would require an order 5 allocation.
      
      An order 5 allocation is still something to avoid unless necessary and
      nothing needs the memory here to be contiguous. Change the allocation
      to kvzalloc() which should still be efficient for small allocations
      but doesn't force the memory subsystem to work hard (and maybe fail)
      at getting a large contiguous chunk.
      
      [1] https://lore.kernel.org/r/20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid
      [2] https://lore.kernel.org/r/20240203-arm64-sve-ptrace-regset-size-v1-1-2c3ba1386b9e@kernel.org
      
      Link: https://lkml.kernel.org/r/20240205092626.v2.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeidSigned-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Cc: Christian Brauner <brauner@kernel.org>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      6b839b3b
  6. 24 Apr, 2024 1 commit
  7. 04 Oct, 2023 2 commits
  8. 29 Sep, 2023 3 commits
  9. 27 Jun, 2023 1 commit
    • Linus Torvalds's avatar
      mm: always expand the stack with the mmap write lock held · 8d7071af
      Linus Torvalds authored
      This finishes the job of always holding the mmap write lock when
      extending the user stack vma, and removes the 'write_locked' argument
      from the vm helper functions again.
      
      For some cases, we just avoid expanding the stack at all: drivers and
      page pinning really shouldn't be extending any stacks.  Let's see if any
      strange users really wanted that.
      
      It's worth noting that architectures that weren't converted to the new
      lock_mm_and_find_vma() helper function are left using the legacy
      "expand_stack()" function, but it has been changed to drop the mmap_lock
      and take it for writing while expanding the vma.  This makes it fairly
      straightforward to convert the remaining architectures.
      
      As a result of dropping and re-taking the lock, the calling conventions
      for this function have also changed, since the old vma may no longer be
      valid.  So it will now return the new vma if successful, and NULL - and
      the lock dropped - if the area could not be extended.
      Tested-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> # ia64
      Tested-by: Frank Scheiner <frank.scheiner@web.de> # ia64
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8d7071af
  10. 24 Jun, 2023 1 commit
  11. 23 Jun, 2023 1 commit
  12. 16 May, 2023 1 commit
  13. 13 Apr, 2023 1 commit
    • Nick Alcock's avatar
      binfmt_elf: remove MODULE_LICENSE in non-modules · 7435721a
      Nick Alcock authored
      Since commit 8b41fc44 ("kbuild: create modules.builtin without
      Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
      are used to identify modules. As a consequence, uses of the macro
      in non-modules will cause modprobe to misidentify their containing
      object file as a module when it is not (false positives), and modprobe
      might succeed rather than failing with a suitable error message.
      
      So remove it in the files in this commit, none of which can be built as
      modules.
      Signed-off-by: default avatarNick Alcock <nick.alcock@oracle.com>
      Suggested-by: default avatarLuis Chamberlain <mcgrof@kernel.org>
      Cc: Luis Chamberlain <mcgrof@kernel.org>
      Cc: linux-modules@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Christian Brauner <brauner@kernel.org>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-mm@kvack.org
      Signed-off-by: default avatarLuis Chamberlain <mcgrof@kernel.org>
      7435721a
  14. 08 Apr, 2023 1 commit
  15. 05 Jan, 2023 1 commit
  16. 27 Dec, 2022 1 commit
  17. 25 Nov, 2022 4 commits
  18. 17 Nov, 2022 1 commit
  19. 25 Oct, 2022 4 commits
  20. 23 Oct, 2022 3 commits
  21. 15 Apr, 2022 2 commits
  22. 18 Mar, 2022 1 commit
    • Rick Edgecombe's avatar
      binfmt_elf: Don't write past end of notes for regset gap · dd664099
      Rick Edgecombe authored
      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: default avatarYu-cheng Yu <yu-cheng.yu@intel.com>
      Signed-off-by: default avatarYu-cheng Yu <yu-cheng.yu@intel.com>
      Signed-off-by: default avatarRick Edgecombe <rick.p.edgecombe@intel.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20220317192013.13655-4-rick.p.edgecombe@intel.com
      dd664099
  23. 08 Mar, 2022 3 commits
  24. 04 Mar, 2022 1 commit
    • Kees Cook's avatar
      binfmt_elf: Introduce KUnit test · 9e1a3ce0
      Kees Cook authored
      Adds simple KUnit test for some binfmt_elf internals: specifically a
      regression test for the problem fixed by commit 8904d9cd90ee ("ELF:
      fix overflow in total mapping size calculation").
      
      $ ./tools/testing/kunit/kunit.py run --arch x86_64 \
          --kconfig_add CONFIG_IA32_EMULATION=y '*binfmt_elf'
      ...
      [19:41:08] ================== binfmt_elf (1 subtest) ==================
      [19:41:08] [PASSED] total_mapping_size_test
      [19:41:08] =================== [PASSED] binfmt_elf ====================
      [19:41:08] ============== compat_binfmt_elf (1 subtest) ===============
      [19:41:08] [PASSED] total_mapping_size_test
      [19:41:08] ================ [PASSED] compat_binfmt_elf ================
      [19:41:08] ============================================================
      [19:41:08] Testing complete. Passed: 2, Failed: 0, Crashed: 0, Skipped: 0, Errors: 0
      
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: David Gow <davidgow@google.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: "Magnus Groß" <magnus.gross@rwth-aachen.de>
      Cc: kunit-dev@googlegroups.com
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      ---
      v1: https://lore.kernel.org/lkml/20220224054332.1852813-1-keescook@chromium.org
      v2:
       - improve commit log
       - fix comment URL (Daniel)
       - drop redundant KUnit Kconfig help info (Daniel)
       - note in Kconfig help that COMPAT builds add a compat test (David)
      9e1a3ce0
  25. 02 Mar, 2022 1 commit