1. 03 11月, 2017 1 次提交
    • D
      arm64/sve: KVM: Prevent guests from using SVE · 17eed27b
      Dave Martin 提交于
      Until KVM has full SVE support, guests must not be allowed to
      execute SVE instructions.
      
      This patch enables the necessary traps, and also ensures that the
      traps are disabled again on exit from the guest so that the host
      can still use SVE if it wants to.
      
      On guest exit, high bits of the SVE Zn registers may have been
      clobbered as a side-effect the execution of FPSIMD instructions in
      the guest.  The existing KVM host FPSIMD restore code is not
      sufficient to restore these bits, so this patch explicitly marks
      the CPU as not containing cached vector state for any task, thus
      forcing a reload on the next return to userspace.  This is an
      interim measure, in advance of adding full SVE awareness to KVM.
      
      This marking of cached vector state in the CPU as invalid is done
      using __this_cpu_write(fpsimd_last_state, NULL) in fpsimd.c.  Due
      to the repeated use of this rather obscure operation, it makes
      sense to factor it out as a separate helper with a clearer name.
      This patch factors it out as fpsimd_flush_cpu_state(), and ports
      all callers to use it.
      
      As a side effect of this refactoring, a this_cpu_write() in
      fpsimd_cpu_pm_notifier() is changed to __this_cpu_write().  This
      should be fine, since cpu_pm_enter() is supposed to be called only
      with interrupts disabled.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      17eed27b
  2. 14 10月, 2017 1 次提交
    • J
      arm_arch_timer: Expose event stream status · ec5c8e42
      Julien Thierry 提交于
      The arch timer configuration for a CPU might get reset after suspending
      said CPU.
      
      In order to reliably use the event stream in the kernel (e.g. for delays),
      we keep track of the state where we can safely consider the event stream as
      properly configured. After writing to cntkctl, we issue an ISB to ensure
      that subsequent delay loops can rely on the event stream being enabled.
      Signed-off-by: NJulien Thierry <julien.thierry@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      ec5c8e42
  3. 18 9月, 2017 1 次提交
  4. 09 9月, 2017 1 次提交
  5. 05 9月, 2017 1 次提交
  6. 01 9月, 2017 1 次提交
  7. 31 8月, 2017 2 次提交
  8. 26 8月, 2017 1 次提交
    • J
      futex: Remove duplicated code and fix undefined behaviour · 30d6e0a4
      Jiri Slaby 提交于
      There is code duplicated over all architecture's headers for
      futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
      and comparison of the result.
      
      Remove this duplication and leave up to the arches only the needed
      assembly which is now in arch_futex_atomic_op_inuser.
      
      This effectively distributes the Will Deacon's arm64 fix for undefined
      behaviour reported by UBSAN to all architectures. The fix was done in
      commit 5f16a046 (arm64: futex: Fix undefined behaviour with
      FUTEX_OP_OPARG_SHIFT usage). Look there for an example dump.
      
      And as suggested by Thomas, check for negative oparg too, because it was
      also reported to cause undefined behaviour report.
      
      Note that s390 removed access_ok check in d12a2970 ("s390/uaccess:
      remove pointless access_ok() checks") as access_ok there returns true.
      We introduce it back to the helper for the sake of simplicity (it gets
      optimized away anyway).
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> [s390]
      Acked-by: Chris Metcalf <cmetcalf@mellanox.com> [for tile]
      Reviewed-by: NDarren Hart (VMware) <dvhart@infradead.org>
      Reviewed-by: Will Deacon <will.deacon@arm.com> [core/arm64]
      Cc: linux-mips@linux-mips.org
      Cc: Rich Felker <dalias@libc.org>
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: peterz@infradead.org
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: sparclinux@vger.kernel.org
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: linux-s390@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: linux-hexagon@vger.kernel.org
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: linux-snps-arc@lists.infradead.org
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-xtensa@linux-xtensa.org
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: openrisc@lists.librecores.org
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-parisc@vger.kernel.org
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: linux-alpha@vger.kernel.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: "David S. Miller" <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/20170824073105.3901-1-jslaby@suse.cz
      30d6e0a4
  9. 17 8月, 2017 1 次提交
  10. 14 8月, 2017 1 次提交
    • R
      ARM: align .data section · 1abd3502
      Russell King 提交于
      Robert Jarzmik reports that his PXA25x system fails to boot with 4.12,
      failing at __flush_whole_cache in arch/arm/mm/proc-xscale.S:215:
      
         0xc0019e20 <+0>:     ldr     r1, [pc, #788]
         0xc0019e24 <+4>:     ldr     r0, [r1]	<== here
      
      with r1 containing 0xc06f82cd, which is the address of "clean_addr".
      Examination of the System.map shows:
      
      c06f22c8 D user_pmd_table
      c06f22cc d __warned.19178
      c06f22cd d clean_addr
      
      indicating that a .data.unlikely section has appeared just before the
      .data section from proc-xscale.S.  According to objdump -h, it appears
      that our assembly files default their .data alignment to 2**0, which
      is bad news if the preceding .data section size is not power-of-2
      aligned at link time.
      
      Add the appropriate .align directives to all assembly files in arch/arm
      that are missing them where we require an appropriate alignment.
      Reported-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      1abd3502
  11. 11 8月, 2017 2 次提交
    • M
      mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem · 99baac21
      Minchan Kim 提交于
      Nadav reported parallel MADV_DONTNEED on same range has a stale TLB
      problem and Mel fixed it[1] and found same problem on MADV_FREE[2].
      
      Quote from Mel Gorman:
       "The race in question is CPU 0 running madv_free and updating some PTEs
        while CPU 1 is also running madv_free and looking at the same PTEs.
        CPU 1 may have writable TLB entries for a page but fail the pte_dirty
        check (because CPU 0 has updated it already) and potentially fail to
        flush.
      
        Hence, when madv_free on CPU 1 returns, there are still potentially
        writable TLB entries and the underlying PTE is still present so that a
        subsequent write does not necessarily propagate the dirty bit to the
        underlying PTE any more. Reclaim at some unknown time at the future
        may then see that the PTE is still clean and discard the page even
        though a write has happened in the meantime. I think this is possible
        but I could have missed some protection in madv_free that prevents it
        happening."
      
      This patch aims for solving both problems all at once and is ready for
      other problem with KSM, MADV_FREE and soft-dirty story[3].
      
      TLB batch API(tlb_[gather|finish]_mmu] uses [inc|dec]_tlb_flush_pending
      and mmu_tlb_flush_pending so that when tlb_finish_mmu is called, we can
      catch there are parallel threads going on.  In that case, forcefully,
      flush TLB to prevent for user to access memory via stale TLB entry
      although it fail to gather page table entry.
      
      I confirmed this patch works with [4] test program Nadav gave so this
      patch supersedes "mm: Always flush VMA ranges affected by zap_page_range
      v2" in current mmotm.
      
      NOTE:
      
      This patch modifies arch-specific TLB gathering interface(x86, ia64,
      s390, sh, um).  It seems most of architecture are straightforward but
      s390 need to be careful because tlb_flush_mmu works only if
      mm->context.flush_mm is set to non-zero which happens only a pte entry
      really is cleared by ptep_get_and_clear and friends.  However, this
      problem never changes the pte entries but need to flush to prevent
      memory access from stale tlb.
      
      [1] http://lkml.kernel.org/r/20170725101230.5v7gvnjmcnkzzql3@techsingularity.net
      [2] http://lkml.kernel.org/r/20170725100722.2dxnmgypmwnrfawp@suse.de
      [3] http://lkml.kernel.org/r/BD3A0EBE-ECF4-41D4-87FA-C755EA9AB6BD@gmail.com
      [4] https://patchwork.kernel.org/patch/9861621/
      
      [minchan@kernel.org: decrease tlb flush pending count in tlb_finish_mmu]
        Link: http://lkml.kernel.org/r/20170808080821.GA31730@bbox
      Link: http://lkml.kernel.org/r/20170802000818.4760-7-namit@vmware.comSigned-off-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NNadav Amit <namit@vmware.com>
      Reported-by: NNadav Amit <namit@vmware.com>
      Reported-by: NMel Gorman <mgorman@techsingularity.net>
      Acked-by: NMel Gorman <mgorman@techsingularity.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Nadav Amit <nadav.amit@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      99baac21
    • M
      mm: refactor TLB gathering API · 56236a59
      Minchan Kim 提交于
      This patch is a preparatory patch for solving race problems caused by
      TLB batch.  For that, we will increase/decrease TLB flush pending count
      of mm_struct whenever tlb_[gather|finish]_mmu is called.
      
      Before making it simple, this patch separates architecture specific part
      and rename it to arch_tlb_[gather|finish]_mmu and generic part just
      calls it.
      
      It shouldn't change any behavior.
      
      Link: http://lkml.kernel.org/r/20170802000818.4760-5-namit@vmware.comSigned-off-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NNadav Amit <namit@vmware.com>
      Acked-by: NMel Gorman <mgorman@techsingularity.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Nadav Amit <nadav.amit@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      56236a59
  12. 10 8月, 2017 1 次提交
  13. 02 8月, 2017 2 次提交
  14. 24 7月, 2017 1 次提交
    • D
      ARM: 8687/1: signal: Fix unparseable iwmmxt_sigframe in uc_regspace[] · ce184a0d
      Dave Martin 提交于
      In kernels with CONFIG_IWMMXT=y running on non-iWMMXt hardware, the
      signal frame can be left partially uninitialised in such a way
      that userspace cannot parse uc_regspace[] safely.  In particular,
      this means that the VFP registers cannot be located reliably in the
      signal frame when a multi_v7_defconfig kernel is run on the
      majority of platforms.
      
      The cause is that the uc_regspace[] is laid out statically based on
      the kernel config, but the decision of whether to save/restore the
      iWMMXt registers must be a runtime decision.
      
      To minimise breakage of software that may assume a fixed layout,
      this patch emits a dummy block of the same size as iwmmxt_sigframe,
      for non-iWMMXt threads.  However, the magic and size of this block
      are now filled in to help parsers skip over it.  A new DUMMY_MAGIC
      is defined for this purpose.
      
      It is probably legitimate (if non-portable) for userspace to
      manufacture its own sigframe for sigreturn, and there is no obvious
      reason why userspace should be required to insert a DUMMY_MAGIC
      block when running on non-iWMMXt hardware, when omitting it has
      worked just fine forever in other configurations.  So in this case,
      sigreturn does not require this block to be present.
      Reported-by: NEdmund Grimley-Evans <Edmund.Grimley-Evans@arm.com>
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      ce184a0d
  15. 20 7月, 2017 2 次提交
  16. 17 7月, 2017 4 次提交
    • T
      ARM: debug: Use generic 8250 debug_ll for am3517 and am335x · 51ef7003
      Tony Lindgren 提交于
      We want to use generic 8250 debug_ll code to get DEBUG_UNCOMPRESS
      working and to simplify the code. The old debug_ll code is no longer
      needed and the machine ID based detection is no longer used.
      
      Note that for most part there's no need to keep DEBUG_LL enabled.
      We now have CONFIG_SERIAL_EARLYCON working very early as long as
      the kernel cmdline has "earlycon" in it and the board specific dts
      file has chosen configured with with the port using stdout-path.
      
      Cc: Hoeun Ryu <hoeun.ryu@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      51ef7003
    • T
      ARM: debug: Use generic 8250 debug_ll for ti81xx · 2d1f7d2e
      Tony Lindgren 提交于
      We want to use generic 8250 debug_ll code to get DEBUG_UNCOMPRESS
      working and to simplify the code. The old debug_ll code is no longer
      needed and the machine ID based detection is no longer used.
      
      Note that for most part there's no need to keep DEBUG_LL enabled.
      We now have CONFIG_SERIAL_EARLYCON working very early as long as
      the kernel cmdline has "earlycon" in it and the board specific dts
      file has chosen configured with with the port using stdout-path.
      
      Cc: Hoeun Ryu <hoeun.ryu@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      2d1f7d2e
    • T
      ARM: debug: Use generic 8250 debug_ll for omap3/4/5 · fc23beb8
      Tony Lindgren 提交于
      We want to use generic 8250 debug_ll code to get DEBUG_UNCOMPRESS
      working and to simplify the code. The old debug_ll code is no longer
      needed and the machine ID based detection is no longer used.
      
      Note that for most part there's no need to keep DEBUG_LL enabled.
      We now have CONFIG_SERIAL_EARLYCON working very early as long as
      the kernel cmdline has "earlycon" in it and the board specific dts
      file has chosen configured with with the port using stdout-path.
      
      Cc: Hoeun Ryu <hoeun.ryu@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      fc23beb8
    • T
      ARM: debug: Use generic 8250 debug_ll for omap2 and omap3/4/5 common uarts · d2b310b0
      Tony Lindgren 提交于
      We want to use generic 8250 debug_ll code to get DEBUG_UNCOMPRESS
      working and to simplify the code. The old debug_ll code is no longer
      needed and the machine ID based detection is no longer used.
      
      Note that for most part there's no need to keep DEBUG_LL enabled.
      We now have CONFIG_SERIAL_EARLYCON working very early as long as
      the kernel cmdline has "earlycon" in it and the board specific dts
      file has chosen configured with with the port using stdout-path.
      
      Cc: Hoeun Ryu <hoeun.ryu@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d2b310b0
  17. 13 7月, 2017 1 次提交
  18. 11 7月, 2017 1 次提交
    • K
      arm: move ELF_ET_DYN_BASE to 4MB · 6a9af90a
      Kees Cook 提交于
      Now that explicitly executed loaders are loaded in the mmap region, we
      have more freedom to decide where we position PIE binaries in the
      address space to avoid possible collisions with mmap or stack regions.
      
      4MB is chosen here mainly to have parity with x86, where this is the
      traditional minimum load location, likely to avoid historically
      requiring a 4MB page table entry when only a portion of the first 4MB
      would be used (since the NULL address is avoided).
      
      For ARM the position could be 0x8000, the standard ET_EXEC load address,
      but that is needlessly close to the NULL address, and anyone running PIE
      on 32-bit ARM will have an MMU, so the tight mapping is not needed.
      
      Link: http://lkml.kernel.org/r/1498154792-49952-2-git-send-email-keescook@chromium.orgSigned-off-by: NKees Cook <keescook@chromium.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Pratyush Anand <panand@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Daniel Micay <danielmicay@gmail.com>
      Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
      Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Qualys Security Advisory <qsa@qualys.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a9af90a
  19. 10 7月, 2017 1 次提交
  20. 08 7月, 2017 1 次提交
    • T
      arm/syscalls: Check address limit on user-mode return · 73ac5d6a
      Thomas Garnier 提交于
      Ensure the address limit is a user-mode segment before returning to
      user-mode. Otherwise a process can corrupt kernel-mode memory and
      elevate privileges [1].
      
      The set_fs function sets the TIF_SETFS flag to force a slow path on
      return. In the slow path, the address limit is checked to be USER_DS if
      needed.
      
      The TIF_SETFS flag is added to _TIF_WORK_MASK shifting _TIF_SYSCALL_WORK
      for arm instruction immediate support. The global work mask is too big
      to used on a single instruction so adapt ret_fast_syscall.
      
      [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=990Signed-off-by: NThomas Garnier <thgarnie@google.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: kernel-hardening@lists.openwall.com
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Pratyush Anand <panand@redhat.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Will Drewry <wad@chromium.org>
      Cc: linux-api@vger.kernel.org
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Link: http://lkml.kernel.org/r/20170615011203.144108-2-thgarnie@google.com
      73ac5d6a
  21. 04 7月, 2017 2 次提交
  22. 01 7月, 2017 3 次提交
    • K
      randstruct: opt-out externally exposed function pointer structs · 8acdf505
      Kees Cook 提交于
      Some function pointer structures are used externally to the kernel, like
      the paravirt structures. These should never be randomized, so mark them
      as such, in preparation for enabling randstruct's automatic selection
      of all-function-pointer structures.
      
      These markings are verbatim from Brad Spengler/PaX Team's code in the
      last public patch of grsecurity/PaX based on my understanding of the
      code. Changes or omissions from the original code are mine and don't
      reflect the original grsecurity/PaX code.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      8acdf505
    • A
      ARM: Prepare for randomized task_struct · ffa47aa6
      Arnd Bergmann 提交于
      With the new task struct randomization, we can run into a build
      failure for certain random seeds, which will place fields beyond
      the allow immediate size in the assembly:
      
      arch/arm/kernel/entry-armv.S: Assembler messages:
      arch/arm/kernel/entry-armv.S:803: Error: bad immediate value for offset (4096)
      
      Only two constants in asm-offset.h are affected, and I'm changing
      both of them here to work correctly in all configurations.
      
      One more macro has the problem, but is currently unused, so this
      removes it instead of adding complexity.
      Suggested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      [kees: Adjust commit log slightly]
      Signed-off-by: NKees Cook <keescook@chromium.org>
      ffa47aa6
    • V
      ARM: NOMMU: Introduce dma operations for noMMU · 1c51c429
      Vladimir Murzin 提交于
      R/M classes of cpus can have memory covered by MPU which in turn might
      configure RAM as Normal i.e. bufferable and cacheable. It breaks
      dma_alloc_coherent() and friends, since data can stuck in caches now
      or be buffered.
      
      This patch factors out DMA support for NOMMU configuration into
      separate entity which provides dedicated dma_ops. We have to handle
      there several cases:
      - configurations with MMU/MPU setup
      - configurations without MMU/MPU setup
      - special case for M-class, since caches and MPU there are optional
      
      In general we rely on default DMA area for coherent allocations or/and
      per-device memory reserves suitable for coherent DMA, so if such
      regions are set coherent allocations go from there.
      
      In case MMU/MPU was not setup we fallback to normal page allocator for
      DMA memory allocation.
      
      In case we run M-class cpus, for configuration without cache support
      (like Cortex-M3/M4) dma operations are forced to be coherent and wired
      with dma-noop (such decision is made based on cacheid global
      variable); however, if caches are detected there and no DMA coherent
      region is given (either default or per-device), dma is disallowed even
      MPU is not set - it is because M-class implement system memory map
      which defines part of address space as Normal memory.
      Reported-by: NAlexandre Torgue <alexandre.torgue@st.com>
      Reported-by: NAndras Szemzo <sza@esh.hu>
      Tested-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
      Tested-by: NAndras Szemzo <sza@esh.hu>
      Tested-by: NAlexandre TORGUE <alexandre.torgue@st.com>
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
      [hch: removed the dma_supported() implementation that isn't required anymore]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      1c51c429
  23. 29 6月, 2017 1 次提交
  24. 28 6月, 2017 2 次提交
  25. 27 6月, 2017 1 次提交
  26. 23 6月, 2017 1 次提交
  27. 22 6月, 2017 1 次提交
    • M
      kbuild: replace genhdr-y with generated-y · ae3f4151
      Masahiro Yamada 提交于
      Originally, generated-y and genhdr-y had different meaning, like
      follows:
      
      - generated-y: generated headers (other than asm-generic wrappers)
      - header-y   : headers to be exported
      - genhdr-y   : generated headers to be exported (generated-y + header-y)
      
      Since commit fcc8487d ("uapi: export all headers under uapi
      directories"), headers under UAPI directories are all exported.
      So, there is no more difference between generated-y and genhdr-y.
      
      We see two users of genhdr-y, arch/{arm,x86}/include/uapi/asm/Kbuild.
      They generate some headers in arch/{arm,x86}/include/generated/uapi/asm
      directories, which are obviously exported.
      
      Replace them with generated-y, and abolish genhdr-y.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      ae3f4151
  28. 19 6月, 2017 2 次提交
    • M
      ARM: 8679/1: bitops: Align prototypes to generic API · 2d618fee
      Marc Gonzalez 提交于
      include/asm-generic/bitops/find.h declares:
      
      extern unsigned long
      find_first_zero_bit(const unsigned long *addr, unsigned long size);
      
      while arch/arm/include/asm/bitops.h declares:
      
      #define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
      extern int _find_first_zero_bit_le(const void * p, unsigned size);
      
      Align the arm prototypes to the generic API, to have gcc report
      inadequate arguments, such as pointer to u32.
      Signed-off-by: NMarc Gonzalez <marc_gonzalez@sigmadesigns.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      2d618fee
    • A
      ARM: 8678/1: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS · 620176f3
      Abel Vesa 提交于
      The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a
      ftrace operation to specify if registers need to saved/restored by
      the ftrace handler. This is needed by kgraft and possibly other
      ftrace-based tools, and the ARM architecture is currently lacking
      this feature. It would also be the first step to support the
      "Kprobes-on-ftrace" optimization on ARM.
      
      This patch introduces a new ftrace handler that stores the registers
      on the stack before calling the next stage. The registers are restored
      from the stack before going back to the instrumented function.
      
      A side-effect of this patch is to activate the support for
      ftrace_modify_call() as it defines ARCH_SUPPORTS_FTRACE_OPS for the
      ARM architecture.
      Signed-off-by: NAbel Vesa <abelvesa@linux.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      620176f3