1. 08 Jul, 2020 7 commits
  2. 03 Jul, 2020 3 commits
  3. 02 Jul, 2020 1 commit
    • Ard Biesheuvel's avatar
      arm64/alternatives: use subsections for replacement sequences · f7b93d42
      Ard Biesheuvel authored
      When building very large kernels, the logic that emits replacement
      sequences for alternatives fails when relative branches are present
      in the code that is emitted into the .altinstr_replacement section
      and patched in at the original site and fixed up. The reason is that
      the linker will insert veneers if relative branches go out of range,
      and due to the relative distance of the .altinstr_replacement from
      the .text section where its branch targets usually live, veneers
      may be emitted at the end of the .altinstr_replacement section, with
      the relative branches in the sequence pointed at the veneers instead
      of the actual target.
      
      The alternatives patching logic will attempt to fix up the branch to
      point to its original target, which will be the veneer in this case,
      but given that the patch site is likely to be far away as well, it
      will be out of range and so patching will fail. There are other cases
      where these veneers are problematic, e.g., when the target of the
      branch is in .text while the patch site is in .init.text, in which
      case putting the replacement sequence inside .text may not help either.
      
      So let's use subsections to emit the replacement code as closely as
      possible to the patch site, to ensure that veneers are only likely to
      be emitted if they are required at the patch site as well, in which
      case they will be in range for the replacement sequence both before
      and after it is transported to the patch site.
      
      This will prevent alternative sequences in non-init code from being
      released from memory after boot, but this is tolerable given that the
      entire section is only 512 KB on an allyesconfig build (which weighs in
      at 500+ MB for the entire Image). Also, note that modules today carry
      the replacement sequences in non-init sections as well, and any of
      those that target init code will be emitted into init sections after
      this change.
      
      This fixes an early crash when booting an allyesconfig kernel on a
      system where any of the alternatives sequences containing relative
      branches are activated at boot (e.g., ARM64_HAS_PAN on TX2)
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Dave P Martin <dave.martin@arm.com>
      Link: https://lore.kernel.org/r/20200630081921.13443-1-ardb@kernel.orgSigned-off-by: default avatarWill Deacon <will@kernel.org>
      f7b93d42
  4. 25 Jun, 2020 2 commits
  5. 24 Jun, 2020 5 commits
  6. 23 Jun, 2020 5 commits
    • Mark Brown's avatar
      arm64: Depend on newer binutils when building PAC · 4dc9b282
      Mark Brown authored
      Versions of binutils prior to 2.33.1 don't understand the ELF notes that
      are added by modern compilers to indicate the PAC and BTI options used
      to build the code. This causes them to emit large numbers of warnings in
      the form:
      
      aarch64-linux-gnu-nm: warning: .tmp_vmlinux.kallsyms2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000
      
      during the kernel build which is currently causing quite a bit of
      disruption for automated build testing using clang.
      
      In commit 15cd0e67 (arm64: Kconfig: ptrauth: Add binutils version
      check to fix mismatch) we added a dependency on binutils to avoid this
      issue when building with versions of GCC that emit the notes but did not
      do so for clang as it was believed that the existing check for
      .cfi_negate_ra_state was already requiring a new enough binutils. This
      does not appear to be the case for some versions of binutils (eg, the
      binutils in Debian 10) so instead refactor so we require a new enough
      GNU binutils in all cases other than when we are using an old GCC
      version that does not emit notes.
      
      Other, more exotic, combinations of tools are possible such as using
      clang, lld and gas together are possible and may have further problems
      but rather than adding further version checks it looks like the most
      robust thing will be to just test that we can build cleanly with the
      configured tools but that will require more review and discussion so do
      this for now to address the immediate problem disrupting build testing.
      Reported-by: default avatarKernelCI <bot@kernelci.org>
      Reported-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Link: https://github.com/ClangBuiltLinux/linux/issues/1054
      Link: https://lore.kernel.org/r/20200619123550.48098-1-broonie@kernel.orgSigned-off-by: default avatarWill Deacon <will@kernel.org>
      4dc9b282
    • Will Deacon's avatar
      arm64: compat: Remove 32-bit sigreturn code from the vDSO · 2d071968
      Will Deacon authored
      The sigreturn code in the compat vDSO is unused. Remove it.
      Reviewed-by: default avatarVincenzo Frascino <vincenzo.frascino@arm.com>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      2d071968
    • Will Deacon's avatar
      arm64: compat: Always use sigpage for sigreturn trampoline · 8e411be6
      Will Deacon authored
      The 32-bit sigreturn trampoline in the compat sigpage matches the binary
      representation of the arch/arm/ sigpage exactly. This is important for
      debuggers (e.g. GDB) and unwinders (e.g. libunwind) since they rely
      on matching the instruction sequence in order to identify that they are
      unwinding through a signal. The same cannot be said for the sigreturn
      trampoline in the compat vDSO, which defeats the unwinder heuristics and
      instead attempts to use unwind directives for the unwinding. This is in
      contrast to arch/arm/, which never uses the vDSO for sigreturn.
      
      Ensure compatibility with arch/arm/ and existing unwinders by always
      using the sigpage for the sigreturn trampoline, regardless of the
      presence of the compat vDSO.
      Reviewed-by: default avatarVincenzo Frascino <vincenzo.frascino@arm.com>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      8e411be6
    • Will Deacon's avatar
      arm64: compat: Allow 32-bit vdso and sigpage to co-exist · a39060b0
      Will Deacon authored
      In preparation for removing the signal trampoline from the compat vDSO,
      allow the sigpage and the compat vDSO to co-exist.
      
      For the moment the vDSO signal trampoline will still be used when built.
      Subsequent patches will move to the sigpage consistently.
      Acked-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarVincenzo Frascino <vincenzo.frascino@arm.com>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      a39060b0
    • Will Deacon's avatar
      arm64: vdso: Disable dwarf unwinding through the sigreturn trampoline · 87676cfc
      Will Deacon authored
      Commit 7e9f5e66 ("arm64: vdso: Add --eh-frame-hdr to ldflags") results
      in a .eh_frame_hdr section for the vDSO, which in turn causes the libgcc
      unwinder to unwind out of signal handlers using the .eh_frame information
      populated by our .cfi directives. In conjunction with a4eb355a
      ("arm64: vdso: Fix CFI directives in sigreturn trampoline"), this has
      been shown to cause segmentation faults originating from within the
      unwinder during thread cancellation:
      
       | Thread 14 "virtio-net-rx" received signal SIGSEGV, Segmentation fault.
       | 0x0000000000435e24 in uw_frame_state_for ()
       | (gdb) bt
       | #0  0x0000000000435e24 in uw_frame_state_for ()
       | #1  0x0000000000436e88 in _Unwind_ForcedUnwind_Phase2 ()
       | #2  0x00000000004374d8 in _Unwind_ForcedUnwind ()
       | #3  0x0000000000428400 in __pthread_unwind (buf=<optimized out>) at unwind.c:121
       | #4  0x0000000000429808 in __do_cancel () at ./pthreadP.h:304
       | #5  sigcancel_handler (sig=32, si=0xffff33c743f0, ctx=<optimized out>) at nptl-init.c:200
       | #6  sigcancel_handler (sig=<optimized out>, si=0xffff33c743f0, ctx=<optimized out>) at nptl-init.c:165
       | #7  <signal handler called>
       | #8  futex_wait_cancelable (private=0, expected=0, futex_word=0x3890b708) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
      
      After considerable bashing of heads, it appears that our CFI directives
      for unwinding out of the sigreturn trampoline are only processed by libgcc
      when both a .eh_frame_hdr section is present *and* the mysterious NOP is
      covered by an entry in .eh_frame. With both of these now in place, it has
      highlighted that our CFI directives are not comprehensive enough to
      restore the stack pointer of the interrupted context. This results in libgcc
      falling back to an arm64-specific unwinder after computing a bogus PC value
      from the unwind tables. The unwinder promptly dereferences this bogus address
      in an attempt to see if the pointed-to instruction sequence looks like
      the sigreturn trampoline.
      
      Restore the old unwind behaviour, which relied solely on heuristics in
      the unwinder, by removing the .eh_frame_hdr section from the vDSO and
      commenting out the insufficient CFI directives for now. Add comments to
      explain the current, miserable state of affairs.
      
      Cc: Tamas Zsoldos <tamas.zsoldos@arm.com>
      Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Daniel Kiss <daniel.kiss@arm.com>
      Acked-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarVincenzo Frascino <vincenzo.frascino@arm.com>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Reported-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      87676cfc
  7. 18 Jun, 2020 3 commits
  8. 17 Jun, 2020 1 commit
    • Will Deacon's avatar
      arm64: bti: Require clang >= 10.0.1 for in-kernel BTI support · b9249cba
      Will Deacon authored
      Unfortunately, most versions of clang that support BTI are capable of
      miscompiling the kernel when converting a switch statement into a jump
      table. As an example, attempting to spawn a KVM guest results in a panic:
      
      [   56.253312] Kernel panic - not syncing: bad mode
      [   56.253834] CPU: 0 PID: 279 Comm: lkvm Not tainted 5.8.0-rc1 #2
      [   56.254225] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
      [   56.254712] Call trace:
      [   56.254952]  dump_backtrace+0x0/0x1d4
      [   56.255305]  show_stack+0x1c/0x28
      [   56.255647]  dump_stack+0xc4/0x128
      [   56.255905]  panic+0x16c/0x35c
      [   56.256146]  bad_el0_sync+0x0/0x58
      [   56.256403]  el1_sync_handler+0xb4/0xe0
      [   56.256674]  el1_sync+0x7c/0x100
      [   56.256928]  kvm_vm_ioctl_check_extension_generic+0x74/0x98
      [   56.257286]  __arm64_sys_ioctl+0x94/0xcc
      [   56.257569]  el0_svc_common+0x9c/0x150
      [   56.257836]  do_el0_svc+0x84/0x90
      [   56.258083]  el0_sync_handler+0xf8/0x298
      [   56.258361]  el0_sync+0x158/0x180
      
      This is because the switch in kvm_vm_ioctl_check_extension_generic()
      is executed as an indirect branch to tail-call through a jump table:
      
      ffff800010032dc8:       3869694c        ldrb    w12, [x10, x9]
      ffff800010032dcc:       8b0c096b        add     x11, x11, x12, lsl #2
      ffff800010032dd0:       d61f0160        br      x11
      
      However, where the target case uses the stack, the landing pad is elided
      due to the presence of a paciasp instruction:
      
      ffff800010032e14:       d503233f        paciasp
      ffff800010032e18:       a9bf7bfd        stp     x29, x30, [sp, #-16]!
      ffff800010032e1c:       910003fd        mov     x29, sp
      ffff800010032e20:       aa0803e0        mov     x0, x8
      ffff800010032e24:       940017c0        bl      ffff800010038d24 <kvm_vm_ioctl_check_extension>
      ffff800010032e28:       93407c00        sxtw    x0, w0
      ffff800010032e2c:       a8c17bfd        ldp     x29, x30, [sp], #16
      ffff800010032e30:       d50323bf        autiasp
      ffff800010032e34:       d65f03c0        ret
      
      Unfortunately, this results in a fatal exception because paciasp is
      compatible only with branch-and-link (call) instructions and not simple
      indirect branches.
      
      A fix is being merged into Clang 10.0.1 so that a 'bti j' instruction is
      emitted as an explicit landing pad in this situation. Make in-kernel
      BTI depend on that compiler version when building with clang.
      
      Cc: Tom Stellard <tstellar@redhat.com>
      Cc: Daniel Kiss <daniel.kiss@arm.com>
      Reviewed-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: default avatarDave Martin <Dave.Martin@arm.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Acked-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Link: https://lore.kernel.org/r/20200615105524.GA2694@willie-the-truck
      Link: https://lore.kernel.org/r/20200616183630.2445-1-will@kernel.orgSigned-off-by: default avatarWill Deacon <will@kernel.org>
      b9249cba
  9. 16 Jun, 2020 2 commits
  10. 15 Jun, 2020 5 commits
  11. 14 Jun, 2020 4 commits
    • Linus Torvalds's avatar
      Linux 5.8-rc1 · b3a9e3b9
      Linus Torvalds authored
      b3a9e3b9
    • Linus Torvalds's avatar
      Merge tag 'LSM-add-setgid-hook-5.8-author-fix' of git://github.com/micah-morton/linux · 4a87b197
      Linus Torvalds authored
      Pull SafeSetID update from Micah Morton:
       "Add additional LSM hooks for SafeSetID
      
        SafeSetID is capable of making allow/deny decisions for set*uid calls
        on a system, and we want to add similar functionality for set*gid
        calls.
      
        The work to do that is not yet complete, so probably won't make it in
        for v5.8, but we are looking to get this simple patch in for v5.8
        since we have it ready.
      
        We are planning on the rest of the work for extending the SafeSetID
        LSM being merged during the v5.9 merge window"
      
      * tag 'LSM-add-setgid-hook-5.8-author-fix' of git://github.com/micah-morton/linux:
        security: Add LSM hooks to set*gid syscalls
      4a87b197
    • Thomas Cedeno's avatar
      security: Add LSM hooks to set*gid syscalls · 39030e13
      Thomas Cedeno authored
      The SafeSetID LSM uses the security_task_fix_setuid hook to filter
      set*uid() syscalls according to its configured security policy. In
      preparation for adding analagous support in the LSM for set*gid()
      syscalls, we add the requisite hook here. Tested by putting print
      statements in the security_task_fix_setgid hook and seeing them get hit
      during kernel boot.
      Signed-off-by: default avatarThomas Cedeno <thomascedeno@google.com>
      Signed-off-by: default avatarMicah Morton <mortonm@chromium.org>
      39030e13
    • Linus Torvalds's avatar
      Merge tag 'for-5.8-part2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux · 9d645db8
      Linus Torvalds authored
      Pull btrfs updates from David Sterba:
       "This reverts the direct io port to iomap infrastructure of btrfs
        merged in the first pull request. We found problems in invalidate page
        that don't seem to be fixable as regressions or without changing iomap
        code that would not affect other filesystems.
      
        There are four reverts in total, but three of them are followup
        cleanups needed to revert a43a67a2 cleanly. The result is the
        buffer head based implementation of direct io.
      
        Reverts are not great, but under current circumstances I don't see
        better options"
      
      * tag 'for-5.8-part2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
        Revert "btrfs: switch to iomap_dio_rw() for dio"
        Revert "fs: remove dio_end_io()"
        Revert "btrfs: remove BTRFS_INODE_READDIO_NEED_LOCK"
        Revert "btrfs: split btrfs_direct_IO to read and write part"
      9d645db8
  12. 13 Jun, 2020 2 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 96144c58
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Fix cfg80211 deadlock, from Johannes Berg.
      
       2) RXRPC fails to send norigications, from David Howells.
      
       3) MPTCP RM_ADDR parsing has an off by one pointer error, fix from
          Geliang Tang.
      
       4) Fix crash when using MSG_PEEK with sockmap, from Anny Hu.
      
       5) The ucc_geth driver needs __netdev_watchdog_up exported, from
          Valentin Longchamp.
      
       6) Fix hashtable memory leak in dccp, from Wang Hai.
      
       7) Fix how nexthops are marked as FDB nexthops, from David Ahern.
      
       8) Fix mptcp races between shutdown and recvmsg, from Paolo Abeni.
      
       9) Fix crashes in tipc_disc_rcv(), from Tuong Lien.
      
      10) Fix link speed reporting in iavf driver, from Brett Creeley.
      
      11) When a channel is used for XSK and then reused again later for XSK,
          we forget to clear out the relevant data structures in mlx5 which
          causes all kinds of problems. Fix from Maxim Mikityanskiy.
      
      12) Fix memory leak in genetlink, from Cong Wang.
      
      13) Disallow sockmap attachments to UDP sockets, it simply won't work.
          From Lorenz Bauer.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (83 commits)
        net: ethernet: ti: ale: fix allmulti for nu type ale
        net: ethernet: ti: am65-cpsw-nuss: fix ale parameters init
        net: atm: Remove the error message according to the atomic context
        bpf: Undo internal BPF_PROBE_MEM in BPF insns dump
        libbpf: Support pre-initializing .bss global variables
        tools/bpftool: Fix skeleton codegen
        bpf: Fix memlock accounting for sock_hash
        bpf: sockmap: Don't attach programs to UDP sockets
        bpf: tcp: Recv() should return 0 when the peer socket is closed
        ibmvnic: Flush existing work items before device removal
        genetlink: clean up family attributes allocations
        net: ipa: header pad field only valid for AP->modem endpoint
        net: ipa: program upper nibbles of sequencer type
        net: ipa: fix modem LAN RX endpoint id
        net: ipa: program metadata mask differently
        ionic: add pcie_print_link_status
        rxrpc: Fix race between incoming ACK parser and retransmitter
        net/mlx5: E-Switch, Fix some error pointer dereferences
        net/mlx5: Don't fail driver on failure to create debugfs
        net/mlx5e: CT: Fix ipv6 nat header rewrite actions
        ...
      96144c58
    • David Sterba's avatar
      Revert "btrfs: switch to iomap_dio_rw() for dio" · 55e20bd1
      David Sterba authored
      This reverts commit a43a67a2.
      
      This patch reverts the main part of switching direct io implementation
      to iomap infrastructure. There's a problem in invalidate page that
      couldn't be solved as regression in this development cycle.
      
      The problem occurs when buffered and direct io are mixed, and the ranges
      overlap. Although this is not recommended, filesystems implement
      measures or fallbacks to make it somehow work. In this case, fallback to
      buffered IO would be an option for btrfs (this already happens when
      direct io is done on compressed data), but the change would be needed in
      the iomap code, bringing new semantics to other filesystems.
      
      Another problem arises when again the buffered and direct ios are mixed,
      invalidation fails, then -EIO is set on the mapping and fsync will fail,
      though there's no real error.
      
      There have been discussions how to fix that, but revert seems to be the
      least intrusive option.
      
      Link: https://lore.kernel.org/linux-btrfs/20200528192103.xm45qoxqmkw7i5yl@fiona/Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      55e20bd1