1. 19 May, 2018 7 commits
  2. 17 May, 2018 1 commit
  3. 16 May, 2018 2 commits
  4. 15 May, 2018 1 commit
    • Josh Poimboeuf's avatar
      objtool: Detect RIP-relative switch table references · 6f5ec299
      Josh Poimboeuf authored
      Typically a switch table can be found by detecting a .rodata access
      followed an indirect jump:
      
          1969:	4a 8b 0c e5 00 00 00 	mov    0x0(,%r12,8),%rcx
          1970:	00
      			196d: R_X86_64_32S	.rodata+0x438
          1971:	e9 00 00 00 00       	jmpq   1976 <dispc_runtime_suspend+0xb6a>
      			1972: R_X86_64_PC32	__x86_indirect_thunk_rcx-0x4
      
      Randy Dunlap reported a case (seen with GCC 4.8) where the .rodata
      access uses RIP-relative addressing:
      
          19bd:	48 8b 3d 00 00 00 00 	mov    0x0(%rip),%rdi        # 19c4 <dispc_runtime_suspend+0xbb8>
      			19c0: R_X86_64_PC32	.rodata+0x45c
          19c4:	e9 00 00 00 00       	jmpq   19c9 <dispc_runtime_suspend+0xbbd>
      			19c5: R_X86_64_PC32	__x86_indirect_thunk_rdi-0x4
      
      In this case the relocation addend needs to be adjusted accordingly in
      order to find the location of the switch table.
      
      The fix is for case 3 (as described in the comments), but also make the
      existing case 1 & 2 checks more precise by only adjusting the addend for
      R_X86_64_PC32 relocations.
      
      This fixes the following warnings:
      
        drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool: dispc_runtime_suspend()+0xbb8: sibling call from callable instruction with modified stack frame
        drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool: dispc_runtime_resume()+0xcc5: sibling call from callable instruction with modified stack frame
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/b6098294fd67afb69af8c47c9883d7a68bf0f8ea.1526305958.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6f5ec299
  5. 14 May, 2018 21 commits
    • Dave Hansen's avatar
      x86/pkeys: Do not special case protection key 0 · 2fa9d1cf
      Dave Hansen authored
      mm_pkey_is_allocated() treats pkey 0 as unallocated.  That is
      inconsistent with the manpages, and also inconsistent with
      mm->context.pkey_allocation_map.  Stop special casing it and only
      disallow values that are actually bad (< 0).
      
      The end-user visible effect of this is that you can now use
      mprotect_pkey() to set pkey=0.
      
      This is a bit nicer than what Ram proposed[1] because it is simpler
      and removes special-casing for pkey 0.  On the other hand, it does
      allow applications to pkey_free() pkey-0, but that's just a silly
      thing to do, so we are not going to protect against it.
      
      The scenario that could happen is similar to what happens if you free
      any other pkey that is in use: it might get reallocated later and used
      to protect some other data.  The most likely scenario is that pkey-0
      comes back from pkey_alloc(), an access-disable or write-disable bit
      is set in PKRU for it, and the next stack access will SIGSEGV.  It's
      not horribly different from if you mprotect()'d your stack or heap to
      be unreadable or unwritable, which is generally very foolish, but also
      not explicitly prevented by the kernel.
      
      1. http://lkml.kernel.org/r/1522112702-27853-1-git-send-email-linuxram@us.ibm.comSigned-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>p
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Cc: stable@vger.kernel.org
      Fixes: 58ab9a08 ("x86/pkeys: Check against max pkey to avoid overflows")
      Link: http://lkml.kernel.org/r/20180509171358.47FD785E@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      2fa9d1cf
    • Dave Hansen's avatar
      x86/pkeys/selftests: Add a test for pkey 0 · 3488a600
      Dave Hansen authored
      Protection key 0 is the default key for all memory and will
      not normally come back from pkey_alloc().  But, you might
      still want pass it to mprotect_pkey().
      
      This check ensures that you can use pkey 0.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171356.9E40B254@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3488a600
    • Dave Hansen's avatar
      x86/pkeys/selftests: Save off 'prot' for allocations · acb25d76
      Dave Hansen authored
      This makes it possible to to tell what 'prot' a given allocation
      is supposed to have.  That way, if we want to change just the
      pkey, we know what 'prot' to pass to mprotect_pkey().
      
      Also, keep a record of the most recent allocation so the tests
      can easily find it.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171354.AA23E228@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      acb25d76
    • Dave Hansen's avatar
      x86/pkeys/selftests: Fix pointer math · 3d64f4ed
      Dave Hansen authored
      We dump out the entire area of the siginfo where the si_pkey_ptr is
      supposed to be.  But, we do some math on the poitner, which is a u32.
      We intended to do byte math, not u32 math on the pointer.
      
      Cast it over to a u8* so it works.
      
      Also, move this block of code to below th si_code check.  It doesn't
      hurt anything, but the si_pkey field is gibberish for other signal
      types.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171352.9BE09819@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3d64f4ed
    • Dave Hansen's avatar
      x86/pkeys: Override pkey when moving away from PROT_EXEC · 0a0b1520
      Dave Hansen authored
      I got a bug report that the following code (roughly) was
      causing a SIGSEGV:
      
      	mprotect(ptr, size, PROT_EXEC);
      	mprotect(ptr, size, PROT_NONE);
      	mprotect(ptr, size, PROT_READ);
      	*ptr = 100;
      
      The problem is hit when the mprotect(PROT_EXEC)
      is implicitly assigned a protection key to the VMA, and made
      that key ACCESS_DENY|WRITE_DENY.  The PROT_NONE mprotect()
      failed to remove the protection key, and the PROT_NONE->
      PROT_READ left the PTE usable, but the pkey still in place
      and left the memory inaccessible.
      
      To fix this, we ensure that we always "override" the pkee
      at mprotect() if the VMA does not have execute-only
      permissions, but the VMA has the execute-only pkey.
      
      We had a check for PROT_READ/WRITE, but it did not work
      for PROT_NONE.  This entirely removes the PROT_* checks,
      which ensures that PROT_NONE now works.
      Reported-by: default avatarShakeel Butt <shakeelb@google.com>
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Cc: stable@vger.kernel.org
      Fixes: 62b5f7d0 ("mm/core, x86/mm/pkeys: Add execute-only protection keys support")
      Link: http://lkml.kernel.org/r/20180509171351.084C5A71@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0a0b1520
    • Dave Hansen's avatar
      x86/pkeys/selftests: Fix pkey exhaustion test off-by-one · f50b4878
      Dave Hansen authored
      In our "exhaust all pkeys" test, we make sure that there
      is the expected number available.  Turns out that the
      test did not cover the execute-only key, but discussed
      it anyway.  It did *not* discuss the test-allocated
      key.
      
      Now that we have a test for the mprotect(PROT_EXEC) case,
      this off-by-one issue showed itself.  Correct the off-by-
      one and add the explanation for the case we missed.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171350.E1656B95@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f50b4878
    • Dave Hansen's avatar
      x86/pkeys/selftests: Add PROT_EXEC test · 6af17cf8
      Dave Hansen authored
      Under the covers, implement executable-only memory with
      protection keys when userspace calls mprotect(PROT_EXEC).
      
      But, we did not have a selftest for that.  Now we do.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171348.9EEE4BEF@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6af17cf8
    • Dave Hansen's avatar
      x86/pkeys/selftests: Factor out "instruction page" · 3fcd2b2d
      Dave Hansen authored
      We currently have an execute-only test, but it is for
      the explicit mprotect_pkey() interface.  We will soon
      add a test for the implicit mprotect(PROT_EXEC)
      enterface.  We need this code in both tests.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171347.C64AB733@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3fcd2b2d
    • Dave Hansen's avatar
      x86/pkeys/selftests: Allow faults on unknown keys · 7e7fd67c
      Dave Hansen authored
      The exec-only pkey is allocated inside the kernel and userspace
      is not told what it is.  So, allow PK faults to occur that have
      an unknown key.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171345.7FC7DA00@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7e7fd67c
    • Dave Hansen's avatar
      x86/pkeys/selftests: Avoid printf-in-signal deadlocks · caf9eb6b
      Dave Hansen authored
      printf() and friends are unusable in signal handlers.  They deadlock.
      The pkey selftest does not do any normal printing in signal handlers,
      only extra debugging.  So, just print the format string so we get
      *some* output when debugging.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171344.C53FD2F3@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      caf9eb6b
    • Dave Hansen's avatar
      x86/pkeys/selftests: Remove dead debugging code, fix dprint_in_signal · a50093d6
      Dave Hansen authored
      There is some noisy debug code at the end of the signal handler.  It was
      disabled by an early, unconditional "return".  However, that return also
      hid a dprint_in_signal=0, which kept dprint_in_signal=1 and effectively
      locked us into permanent dprint_in_signal=1 behavior.
      
      Remove the return and the dead code, fixing dprint_in_signal.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171342.846B9B2E@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a50093d6
    • Dave Hansen's avatar
      x86/pkeys/selftests: Stop using assert() · 86b9eea2
      Dave Hansen authored
      If we use assert(), the program "crashes".  That can be scary to users,
      so stop doing it.  Just exit with a >0 exit code instead.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171340.E63EF7DA@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      86b9eea2
    • Dave Hansen's avatar
      x86/pkeys/selftests: Give better unexpected fault error messages · 55556b0b
      Dave Hansen authored
      do_not_expect_pk_fault() is a helper that we call when we do not expect
      a PK fault to have occurred.  But, it is a function, which means that
      it obscures the line numbers from pkey_assert().  It also gives no
      details.
      
      Replace it with an implementation that gives nice line numbers and
      also lets callers pass in a more descriptive message about what
      happened that caused the unexpected fault.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellermen <mpe@ellerman.id.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180509171338.55D13B64@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      55556b0b
    • Andy Lutomirski's avatar
      x86/selftests: Add mov_to_ss test · 59c2a722
      Andy Lutomirski authored
      This exercises a nasty corner case of the x86 ISA.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/67e08b69817171da8026e0eb3af0214b06b4d74f.1525800455.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      59c2a722
    • Ingo Molnar's avatar
      x86/mpx/selftests: Adjust the self-test to fresh distros that export the MPX ABI · 73bb4d6c
      Ingo Molnar authored
      Fix this warning:
      
        mpx-mini-test.c:422:0: warning: "SEGV_BNDERR" redefined
      
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: akpm@linux-foundation.org
      Cc: dave.hansen@intel.com
      Cc: linux-mm@kvack.org
      Cc: linuxram@us.ibm.com
      Cc: mpe@ellerman.id.au
      Cc: shakeelb@google.com
      Cc: shuah@kernel.org
      Link: http://lkml.kernel.org/r/20180514085908.GA12798@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      73bb4d6c
    • Ingo Molnar's avatar
      x86/pkeys/selftests: Adjust the self-test to fresh distros that export the pkeys ABI · 0fb96620
      Ingo Molnar authored
      Ubuntu 18.04 started exporting pkeys details in header files, resulting
      in build failures and warnings in the pkeys self-tests:
      
        protection_keys.c:232:0: warning: "SEGV_BNDERR" redefined
        protection_keys.c:387:5: error: conflicting types for ‘pkey_get’
        protection_keys.c:409:5: error: conflicting types for ‘pkey_set’
        ...
      
      Fix these namespace conflicts and double definitions, plus also
      clean up the ABI definitions to make it all a bit more readable ...
      
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: akpm@linux-foundation.org
      Cc: dave.hansen@intel.com
      Cc: linux-mm@kvack.org
      Cc: linuxram@us.ibm.com
      Cc: mpe@ellerman.id.au
      Cc: shakeelb@google.com
      Cc: shuah@kernel.org
      Link: http://lkml.kernel.org/r/20180514085623.GB7094@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0fb96620
    • Alexander Potapenko's avatar
      x86/boot/64/clang: Use fixup_pointer() to access '__supported_pte_mask' · 4a09f021
      Alexander Potapenko authored
      Clang builds with defconfig started crashing after the following
      commit:
      
        fb43d6cb ("x86/mm: Do not auto-massage page protections")
      
      This was caused by introducing a new global access in __startup_64().
      
      Code in __startup_64() can be relocated during execution, but the compiler
      doesn't have to generate PC-relative relocations when accessing globals
      from that function. Clang actually does not generate them, which leads
      to boot-time crashes. To work around this problem, every global pointer
      must be adjusted using fixup_pointer().
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Reviewed-by: default avatarDave Hansen <dave.hansen@intel.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: dvyukov@google.com
      Cc: kirill.shutemov@linux.intel.com
      Cc: linux-mm@kvack.org
      Cc: md@google.com
      Cc: mka@chromium.org
      Fixes: fb43d6cb ("x86/mm: Do not auto-massage page protections")
      Link: http://lkml.kernel.org/r/20180509091822.191810-1-glider@google.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4a09f021
    • Josh Poimboeuf's avatar
      objtool: Support GCC 8 switch tables · fd35c88b
      Josh Poimboeuf authored
      With GCC 8, some issues were found with the objtool switch table
      detection.
      
      1) In the .rodata section, immediately after the switch table, there can
         be another object which contains a pointer to the function which had
         the switch statement.  In this case objtool wrongly considers the
         function pointer to be part of the switch table.  Fix it by:
      
         a) making sure there are no pointers to the beginning of the
            function; and
      
         b) making sure there are no gaps in the switch table.
      
         Only the former was needed, the latter adds additional protection for
         future optimizations.
      
      2) In find_switch_table(), case 1 and case 2 are missing the check to
         ensure that the .rodata switch table data is anonymous, i.e. that it
         isn't already associated with an ELF symbol.  Fix it by adding the
         same find_symbol_containing() check which is used for case 3.
      
      This fixes the following warnings with GCC 8:
      
        drivers/block/virtio_blk.o: warning: objtool: virtio_queue_rq()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+72
        net/ipv6/icmp.o: warning: objtool: icmpv6_rcv()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+64
        drivers/usb/core/quirks.o: warning: objtool: quirks_param_set()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+48
        drivers/mtd/nand/raw/nand_hynix.o: warning: objtool: hynix_nand_decode_id()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+24
        drivers/mtd/nand/raw/nand_samsung.o: warning: objtool: samsung_nand_decode_id()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+32
        drivers/gpu/drm/nouveau/nvkm/subdev/top/gk104.o: warning: objtool: gk104_top_oneinit()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+64
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: damian <damian.tometzki@icloud.com>
      Link: http://lkml.kernel.org/r/20180510224849.xwi34d6tzheb5wgw@trebleSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      fd35c88b
    • Josh Poimboeuf's avatar
      objtool: Support GCC 8's cold subfunctions · 13810435
      Josh Poimboeuf authored
      GCC 8 moves a lot of unlikely code out of line to "cold" subfunctions in
      .text.unlikely.  Properly detect the new subfunctions and treat them as
      extensions of the original functions.
      
      This fixes a bunch of warnings like:
      
        kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x33: sibling call from callable instruction with modified stack frame
        kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x290: sibling call from callable instruction with modified stack frame
        kernel/cgroup/cgroup.o: warning: objtool: cgroup_apply_control_enable()+0x25b: sibling call from callable instruction with modified stack frame
        kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x325: sibling call from callable instruction with modified stack frame
      Reported-and-tested-by: default avatardamian <damian.tometzki@icloud.com>
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/0965e7fcfc5f31a276f0c7f298ff770c19b68706.1525923412.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      13810435
    • Josh Poimboeuf's avatar
      objtool: Fix "noreturn" detection for recursive sibling calls · 0afd0d9e
      Josh Poimboeuf authored
      Objtool has some crude logic for detecting static "noreturn" functions
      (aka "dead ends").  This is necessary for being able to correctly follow
      GCC code flow when such functions are called.
      
      It's remotely possible for two functions to call each other via sibling
      calls.  If they don't have RET instructions, objtool's noreturn
      detection logic goes into a recursive loop:
      
        drivers/char/ipmi/ipmi_ssif.o: warning: objtool: return_hosed_msg()+0x0: infinite recursion (objtool bug!)
        drivers/char/ipmi/ipmi_ssif.o: warning: objtool: deliver_recv_msg()+0x0: infinite recursion (objtool bug!)
      
      Instead of reporting an error in this case, consider the functions to be
      non-dead-ends.
      Reported-and-tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: damian <damian.tometzki@icloud.com>
      Link: http://lkml.kernel.org/r/7cc156408c5781a1f62085d352ced1fe39fe2f91.1525923412.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0afd0d9e
    • Ingo Molnar's avatar
      objtool, kprobes/x86: Sync the latest <asm/insn.h> header with... · 4fe875e4
      Ingo Molnar authored
      objtool, kprobes/x86: Sync the latest <asm/insn.h> header with tools/objtool/arch/x86/include/asm/insn.h
      
      The following commit:
      
        ee6a7354: kprobes/x86: Prohibit probing on exception masking instructions
      
      Modified <asm/insn.h>, adding the insn_masking_exception() function.
      
      Sync the tooling version of the header to it, to fix this warning:
      
        Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h'
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
      Cc: Francis Deslauriers <francis.deslauriers@efficios.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Yonghong Song <yhs@fb.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: "David S . Miller" <davem@davemloft.net>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4fe875e4
  6. 13 May, 2018 8 commits