1. 20 Nov, 2019 1 commit
    • Pavel Tatashin's avatar
      arm64: uaccess: Ensure PAN is re-enabled after unhandled uaccess fault · 94bb804e
      Pavel Tatashin authored
      A number of our uaccess routines ('__arch_clear_user()' and
      '__arch_copy_{in,from,to}_user()') fail to re-enable PAN if they
      encounter an unhandled fault whilst accessing userspace.
      
      For CPUs implementing both hardware PAN and UAO, this bug has no effect
      when both extensions are in use by the kernel.
      
      For CPUs implementing hardware PAN but not UAO, this means that a kernel
      using hardware PAN may execute portions of code with PAN inadvertently
      disabled, opening us up to potential security vulnerabilities that rely
      on userspace access from within the kernel which would usually be
      prevented by this mechanism. In other words, parts of the kernel run the
      same way as they would on a CPU without PAN implemented/emulated at all.
      
      For CPUs not implementing hardware PAN and instead relying on software
      emulation via 'CONFIG_ARM64_SW_TTBR0_PAN=y', the impact is unfortunately
      much worse. Calling 'schedule()' with software PAN disabled means that
      the next task will execute in the kernel using the page-table and ASID
      of the previous process even after 'switch_mm()', since the actual
      hardware switch is deferred until return to userspace. At this point, or
      if there is a intermediate call to 'uaccess_enable()', the page-table
      and ASID of the new process are installed. Sadly, due to the changes
      introduced by KPTI, this is not an atomic operation and there is a very
      small window (two instructions) where the CPU is configured with the
      page-table of the old task and the ASID of the new task; a speculative
      access in this state is disastrous because it would corrupt the TLB
      entries for the new task with mappings from the previous address space.
      
      As Pavel explains:
      
        | I was able to reproduce memory corruption problem on Broadcom's SoC
        | ARMv8-A like this:
        |
        | Enable software perf-events with PERF_SAMPLE_CALLCHAIN so userland's
        | stack is accessed and copied.
        |
        | The test program performed the following on every CPU and forking
        | many processes:
        |
        |	unsigned long *map = mmap(NULL, PAGE_SIZE, PROT_READ|PROT_WRITE,
        |				  MAP_SHARED | MAP_ANONYMOUS, -1, 0);
        |	map[0] = getpid();
        |	sched_yield();
        |	if (map[0] != getpid()) {
        |		fprintf(stderr, "Corruption detected!");
        |	}
        |	munmap(map, PAGE_SIZE);
        |
        | From time to time I was getting map[0] to contain pid for a
        | different process.
      
      Ensure that PAN is re-enabled when returning after an unhandled user
      fault from our uaccess routines.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: <stable@vger.kernel.org>
      Fixes: 338d4f49 ("arm64: kernel: Add support for Privileged Access Never")
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@soleen.com>
      [will: rewrote commit message]
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      94bb804e
  2. 13 Nov, 2019 1 commit
  3. 06 Nov, 2019 1 commit
  4. 01 Nov, 2019 3 commits
  5. 31 Oct, 2019 1 commit
  6. 29 Oct, 2019 2 commits
    • Bjorn Andersson's avatar
      arm64: cpufeature: Enable Qualcomm Falkor/Kryo errata 1003 · d4af3c4b
      Bjorn Andersson authored
      With the introduction of 'cce360b5 ("arm64: capabilities: Filter the
      entries based on a given mask")' the Qualcomm Falkor/Kryo errata 1003 is
      no long applied.
      
      The result of not applying errata 1003 is that MSM8996 runs into various
      RCU stalls and fails to boot most of the times.
      
      Give 1003 a "type" to ensure they are not filtered out in
      update_cpu_capabilities().
      
      Fixes: cce360b5 ("arm64: capabilities: Filter the entries based on a given mask")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarMark Brown <broonie@kernel.org>
      Suggested-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      d4af3c4b
    • Catalin Marinas's avatar
      arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default · aa57157b
      Catalin Marinas authored
      Shared and writable mappings (__S.1.) should be clean (!dirty) initially
      and made dirty on a subsequent write either through the hardware DBM
      (dirty bit management) mechanism or through a write page fault. A clean
      pte for the arm64 kernel is one that has PTE_RDONLY set and PTE_DIRTY
      clear.
      
      The PAGE_SHARED{,_EXEC} attributes have PTE_WRITE set (PTE_DBM) and
      PTE_DIRTY clear. Prior to commit 73e86cb0 ("arm64: Move PTE_RDONLY
      bit handling out of set_pte_at()"), it was the responsibility of
      set_pte_at() to set the PTE_RDONLY bit and mark the pte clean if the
      software PTE_DIRTY bit was not set. However, the above commit removed
      the pte_sw_dirty() check and the subsequent setting of PTE_RDONLY in
      set_pte_at() while leaving the PAGE_SHARED{,_EXEC} definitions
      unchanged. The result is that shared+writable mappings are now dirty by
      default
      
      Fix the above by explicitly setting PTE_RDONLY in PAGE_SHARED{,_EXEC}.
      In addition, remove the superfluous PTE_DIRTY bit from the kernel PROT_*
      attributes.
      
      Fixes: 73e86cb0 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()")
      Cc: <stable@vger.kernel.org> # 4.14.x-
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      aa57157b
  7. 17 Oct, 2019 1 commit
    • Will Deacon's avatar
      Merge branch 'errata/tx2-219' into for-next/fixes · 777d062e
      Will Deacon authored
      Workaround for Cavium/Marvell ThunderX2 erratum #219.
      
      * errata/tx2-219:
        arm64: Allow CAVIUM_TX2_ERRATUM_219 to be selected
        arm64: Avoid Cavium TX2 erratum 219 when switching TTBR
        arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT
        arm64: KVM: Trap VM ops when ARM64_WORKAROUND_CAVIUM_TX2_219_TVM is set
      777d062e
  8. 16 Oct, 2019 4 commits
  9. 15 Oct, 2019 2 commits
  10. 11 Oct, 2019 1 commit
    • Chris von Recklinghausen's avatar
      arm64: Fix kcore macros after 52-bit virtual addressing fallout · 86109a69
      Chris von Recklinghausen authored
      We export the entire kernel address space (i.e. the whole of the TTBR1
      address range) via /proc/kcore. The kc_vaddr_to_offset() and
      kc_offset_to_vaddr() macros are intended to convert between a kernel
      virtual address and its offset relative to the start of the TTBR1
      address space.
      
      Prior to commit:
      
        14c127c9 ("arm64: mm: Flip kernel VA space")
      
      ... the offset was calculated relative to VA_START, which at the time
      was the start of the TTBR1 address space. At this time, PAGE_OFFSET
      pointed to the high half of the TTBR1 address space where arm64's
      linear map lived.
      
      That commit swapped the position of VA_START and PAGE_OFFSET, but
      failed to update kc_vaddr_to_offset() or kc_offset_to_vaddr(), so
      since then the two macros behave incorrectly.
      
      Note that VA_START was subsequently renamed to PAGE_END in commit:
      
        77ad4ce6 ("arm64: memory: rename VA_START to PAGE_END")
      
      As the generic implementations of the two macros calculate the offset
      relative to PAGE_OFFSET (which is now the start of the TTBR1 address
      space), we can delete the arm64 implementation and use those.
      
      Fixes: 14c127c9 ("arm64: mm: Flip kernel VA space")
      Reviewed-by: default avatarJames Morse <james.morse@arm.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarChris von Recklinghausen <crecklin@redhat.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      86109a69
  11. 08 Oct, 2019 5 commits
  12. 07 Oct, 2019 12 commits
  13. 06 Oct, 2019 4 commits
    • Linus Torvalds's avatar
      Linux 5.4-rc2 · da0c9ea1
      Linus Torvalds authored
      da0c9ea1
    • Linus Torvalds's avatar
      elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings · b212921b
      Linus Torvalds authored
      In commit 4ed28639 ("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 ad55eac7 ("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: default avatarRussell King <linux@armlinux.org.uk>
      Fixes: 4ed28639 ("fs, elf: drop MAP_FIXED usage from elf_map")
      Fixes: ad55eac7 ("elf: enforce  MAP_FIXED on overlaying elf segments")
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b212921b
    • Linus Torvalds's avatar
      Merge tag 'dma-mapping-5.4-1' of git://git.infradead.org/users/hch/dma-mapping · 7cdb85df
      Linus Torvalds authored
      Pull dma-mapping regression fix from Christoph Hellwig:
       "Revert an incorret hunk from a patch that caused problems on various
        arm boards (Andrey Smirnov)"
      
      * tag 'dma-mapping-5.4-1' of git://git.infradead.org/users/hch/dma-mapping:
        dma-mapping: fix false positive warnings in dma_common_free_remap()
      7cdb85df
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc · 43b815c6
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "A few fixes this time around:
      
         - Fixup of some clock specifications for DRA7 (device-tree fix)
      
         - Removal of some dead/legacy CPU OPP/PM code for OMAP that throws
           warnings at boot
      
         - A few more minor fixups for OMAPs, most around display
      
         - Enable STM32 QSPI as =y since their rootfs sometimes comes from
           there
      
         - Switch CONFIG_REMOTEPROC to =y since it went from tristate to bool
      
         - Fix of thermal zone definition for ux500 (5.4 regression)"
      
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
        ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI support
        ARM: dts: ux500: Fix up the CPU thermal zone
        arm64/ARM: configs: Change CONFIG_REMOTEPROC from m to y
        ARM: dts: am4372: Set memory bandwidth limit for DISPC
        ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage()
        ARM: OMAP2+: Add missing LCDC midlemode for am335x
        ARM: OMAP2+: Fix missing reset done flag for am3 and am43
        ARM: dts: Fix gpio0 flags for am335x-icev2
        ARM: omap2plus_defconfig: Enable more droid4 devices as loadable modules
        ARM: omap2plus_defconfig: Enable DRM_TI_TFP410
        DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again
        ARM: dts: Fix wrong clocks for dra7 mcasp
        clk: ti: dra7: Fix mcasp8 clock bits
      43b815c6
  14. 05 Oct, 2019 2 commits
    • Linus Torvalds's avatar
      Merge tag 'kbuild-fixes-v5.4' of... · 2d00aee2
      Linus Torvalds authored
      Merge tag 'kbuild-fixes-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
      
      Pull Kbuild fixes from Masahiro Yamada:
      
       - remove unneeded ar-option and KBUILD_ARFLAGS
      
       - remove long-deprecated SUBDIRS
      
       - fix modpost to suppress false-positive warnings for UML builds
      
       - fix namespace.pl to handle relative paths to ${objtree}, ${srctree}
      
       - make setlocalversion work for /bin/sh
      
       - make header archive reproducible
      
       - fix some Makefiles and documents
      
      * tag 'kbuild-fixes-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
        kheaders: make headers archive reproducible
        kbuild: update compile-test header list for v5.4-rc2
        kbuild: two minor updates for Documentation/kbuild/modules.rst
        scripts/setlocalversion: clear local variable to make it work for sh
        namespace: fix namespace.pl script to support relative paths
        video/logo: do not generate unneeded logo C files
        video/logo: remove unneeded *.o pattern from clean-files
        integrity: remove pointless subdir-$(CONFIG_...)
        integrity: remove unneeded, broken attempt to add -fshort-wchar
        modpost: fix static EXPORT_SYMBOL warnings for UML build
        kbuild: correct formatting of header in kbuild module docs
        kbuild: remove SUBDIRS support
        kbuild: remove ar-option and KBUILD_ARFLAGS
      2d00aee2
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 126195c9
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Twelve patches mostly small but obvious fixes or cosmetic but small
        updates"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: qla2xxx: Fix Nport ID display value
        scsi: qla2xxx: Fix N2N link up fail
        scsi: qla2xxx: Fix N2N link reset
        scsi: qla2xxx: Optimize NPIV tear down process
        scsi: qla2xxx: Fix stale mem access on driver unload
        scsi: qla2xxx: Fix unbound sleep in fcport delete path.
        scsi: qla2xxx: Silence fwdump template message
        scsi: hisi_sas: Make three functions static
        scsi: megaraid: disable device when probe failed after enabled device
        scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue
        scsi: qedf: Remove always false 'tmp_prio < 0' statement
        scsi: ufs: skip shutdown if hba is not powered
        scsi: bnx2fc: Handle scope bits when array returns BUSY or TSF
      126195c9