1. 15 9月, 2016 2 次提交
  2. 14 9月, 2016 1 次提交
  3. 24 8月, 2016 2 次提交
  4. 10 8月, 2016 3 次提交
    • V
      x86/build: Reduce the W=1 warnings noise when compiling x86 syscall tables · 5e44258d
      Valdis Kletnieks 提交于
      Building an X86_64 kernel with W=1 throws a total of 9,948 lines of warnings of
      this form for both 32-bit and 64-bit syscall tables. Given that the entire rest
      of the build for my config only generates 8,375 lines of output, this is a big
      reduction in the warnings generated.
      
      The warnings follow this pattern:
      
        ./arch/x86/include/generated/asm/syscalls_32.h:885:21: warning: initialized field overwritten [-Woverride-init]
         __SYSCALL_I386(379, compat_sys_pwritev2, )
                           ^
        arch/x86/entry/syscall_32.c:13:46: note: in definition of macro '__SYSCALL_I386'
         #define __SYSCALL_I386(nr, sym, qual) [nr] = sym,
                                                    ^~~
        ./arch/x86/include/generated/asm/syscalls_32.h:885:21: note: (near initialization for 'ia32_sys_call_table[379]')
         __SYSCALL_I386(379, compat_sys_pwritev2, )
                           ^
        arch/x86/entry/syscall_32.c:13:46: note: in definition of macro '__SYSCALL_I386'
         #define __SYSCALL_I386(nr, sym, qual) [nr] = sym,
      
      Since we intentionally build the syscall tables this way, ignore that one
      warning in the two files.
      Signed-off-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh 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/7464.1470021890@turing-police.cc.vt.eduSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5e44258d
    • B
      x86/entry: Clarify the RF saving/restoring situation with SYSCALL/SYSRET · 3e035305
      Borislav Petkov 提交于
      Clarify why exactly RF cannot be restored properly by SYSRET to avoid
      confusion.
      
      No functionality change.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NAndy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh 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/20160803171429.GA2590@nazgul.tnicSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3e035305
    • A
      x86, kasan, ftrace: Put APIC interrupt handlers into .irqentry.text · 469f0023
      Alexander Potapenko 提交于
      Dmitry Vyukov has reported unexpected KASAN stackdepot growth:
      
        https://github.com/google/kasan/issues/36
      
      ... which is caused by the APIC handlers not being present in .irqentry.text:
      
      When building with CONFIG_FUNCTION_GRAPH_TRACER=y or CONFIG_KASAN=y, put the
      APIC interrupt handlers into the .irqentry.text section. This is needed
      because both KASAN and function graph tracer use __irqentry_text_start and
      __irqentry_text_end to determine whether a function is an IRQ entry point.
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NAlexander Potapenko <glider@google.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: aryabinin@virtuozzo.com
      Cc: kasan-dev@googlegroups.com
      Cc: kcc@google.com
      Cc: rostedt@goodmis.org
      Link: http://lkml.kernel.org/r/1468575763-144889-1-git-send-email-glider@google.com
      [ Minor edits. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      469f0023
  5. 04 8月, 2016 2 次提交
  6. 01 8月, 2016 2 次提交
  7. 27 7月, 2016 1 次提交
  8. 25 7月, 2016 1 次提交
  9. 19 7月, 2016 1 次提交
  10. 15 7月, 2016 4 次提交
  11. 14 7月, 2016 1 次提交
  12. 10 7月, 2016 2 次提交
  13. 08 7月, 2016 2 次提交
    • B
      x86/asm/entry: Make thunk's restore a local label · 9a7e7b57
      Borislav Petkov 提交于
      No need to have it appear in objdump output.
      
      No functionality change.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh 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/20160708141016.GH3808@pd.tnicSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9a7e7b57
    • D
      x86/vdso: Add mremap hook to vm_special_mapping · b059a453
      Dmitry Safonov 提交于
      Add possibility for 32-bit user-space applications to move
      the vDSO mapping.
      
      Previously, when a user-space app called mremap() for the vDSO
      address, in the syscall return path it would land on the previous
      address of the vDSOpage, resulting in segmentation violation.
      
      Now it lands fine and returns to userspace with a remapped vDSO.
      
      This will also fix the context.vdso pointer for 64-bit, which does
      not affect the user of vDSO after mremap() currently, but this
      may change in the future.
      
      As suggested by Andy, return -EINVAL for mremap() that would
      split the vDSO image: that operation cannot possibly result in
      a working system so reject it.
      
      Renamed and moved the text_mapping structure declaration inside
      map_vdso(), as it used only there and now it complements the
      vvar_mapping variable.
      
      There is still a problem for remapping the vDSO in glibc
      applications: the linker relocates addresses for syscalls
      on the vDSO page, so you need to relink with the new
      addresses.
      
      Without that the next syscall through glibc may fail:
      
        Program received signal SIGSEGV, Segmentation fault.
        #0  0xf7fd9b80 in __kernel_vsyscall ()
        #1  0xf7ec8238 in _exit () from /usr/lib32/libc.so.6
      Signed-off-by: NDmitry Safonov <dsafonov@virtuozzo.com>
      Acked-by: NAndy Lutomirski <luto@kernel.org>
      Cc: 0x7f454c46@gmail.com
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20160628113539.13606-2-dsafonov@virtuozzo.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b059a453
  14. 15 6月, 2016 3 次提交
  15. 14 6月, 2016 1 次提交
  16. 08 6月, 2016 1 次提交
    • E
      GCC plugin infrastructure · 6b90bd4b
      Emese Revfy 提交于
      This patch allows to build the whole kernel with GCC plugins. It was ported from
      grsecurity/PaX. The infrastructure supports building out-of-tree modules and
      building in a separate directory. Cross-compilation is supported too.
      Currently the x86, arm, arm64 and uml architectures enable plugins.
      
      The directory of the gcc plugins is scripts/gcc-plugins. You can use a file or a directory
      there. The plugins compile with these options:
       * -fno-rtti: gcc is compiled with this option so the plugins must use it too
       * -fno-exceptions: this is inherited from gcc too
       * -fasynchronous-unwind-tables: this is inherited from gcc too
       * -ggdb: it is useful for debugging a plugin (better backtrace on internal
          errors)
       * -Wno-narrowing: to suppress warnings from gcc headers (ipa-utils.h)
       * -Wno-unused-variable: to suppress warnings from gcc headers (gcc_version
          variable, plugin-version.h)
      
      The infrastructure introduces a new Makefile target called gcc-plugins. It
      supports all gcc versions from 4.5 to 6.0. The scripts/gcc-plugin.sh script
      chooses the proper host compiler (gcc-4.7 can be built by either gcc or g++).
      This script also checks the availability of the included headers in
      scripts/gcc-plugins/gcc-common.h.
      
      The gcc-common.h header contains frequently included headers for GCC plugins
      and it has a compatibility layer for the supported gcc versions.
      
      The gcc-generate-*-pass.h headers automatically generate the registration
      structures for GIMPLE, SIMPLE_IPA, IPA and RTL passes.
      
      Note that 'make clean' keeps the *.so files (only the distclean or mrproper
      targets clean all) because they are needed for out-of-tree modules.
      
      Based on work created by the PaX Team.
      Signed-off-by: NEmese Revfy <re.emese@gmail.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      6b90bd4b
  17. 24 5月, 2016 1 次提交
  18. 19 5月, 2016 1 次提交
    • J
      x86/entry/64: Fix stack return address retrieval in thunk · d4bf7078
      Josh Poimboeuf 提交于
      With CONFIG_FRAME_POINTER enabled, a thunk can pass a bad return address
      value to the called function.  '9*8(%rsp)' actually gets the frame
      pointer, not the return address.
      
      The only users of the 'put_ret_addr_in_rdi' option are two functions
      which trace the enabling and disabling of interrupts, so this bug can
      result in bad debug or tracing information with CONFIG_IRQSOFF_TRACER or
      CONFIG_PROVE_LOCKING.
      
      Fix this by implementing the suggestion of Linus: explicitly push
      the frame pointer all the time and constify the stack offsets that
      way. This is both correct and easier to read.
      Reported-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      [ Extended the changelog a bit. ]
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 058fb732 ("x86/asm/entry: Create stack frames in thunk functions")
      Link: http://lkml.kernel.org/r/20160517180606.v5o7wcgdni7443ol@trebleSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d4bf7078
  19. 12 5月, 2016 1 次提交
  20. 05 5月, 2016 2 次提交
  21. 03 5月, 2016 1 次提交
    • D
      x86/asm/entry/32: Simplify pushes of zeroed pt_regs->REGs · 778843f9
      Denys Vlasenko 提交于
      Use of a temporary R8 register here seems to be unnecessary.
      
      "push %r8" is a two-byte insn (it needs REX prefix to specify R8),
      "push $0" is two-byte too. It seems just using the latter would be
      no worse.
      
      Thus, code had an unnecessary "xorq %r8,%r8" insn.
      It probably costs nothing in execution time here since we are probably
      limited by store bandwidth at this point, but still.
      
      Run-tested under QEMU: 32-bit calls still work:
      
       / # ./test_syscall_vdso32
       [RUN]	Executing 6-argument 32-bit syscall via VDSO
       [OK]	Arguments are preserved across syscall
       [NOTE]	R11 has changed:0000000000200ed7 - assuming clobbered by SYSRET insn
       [OK]	R8..R15 did not leak kernel data
       [RUN]	Executing 6-argument 32-bit syscall via INT 80
       [OK]	Arguments are preserved across syscall
       [OK]	R8..R15 did not leak kernel data
       [RUN]	Running tests under ptrace
       [RUN]	Executing 6-argument 32-bit syscall via VDSO
       [OK]	Arguments are preserved across syscall
       [NOTE]	R11 has changed:0000000000200ed7 - assuming clobbered by SYSRET insn
       [OK]	R8..R15 did not leak kernel data
       [RUN]	Executing 6-argument 32-bit syscall via INT 80
       [OK]	Arguments are preserved across syscall
       [OK]	R8..R15 did not leak kernel data
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      Acked-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Drewry <wad@chromium.org>
      Cc: linux-kernel@vger.kernel.org
      Link: http://lkml.kernel.org/r/1462201010-16846-1-git-send-email-dvlasenk@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      778843f9
  22. 29 4月, 2016 1 次提交
  23. 20 4月, 2016 1 次提交
  24. 19 4月, 2016 1 次提交
  25. 13 4月, 2016 2 次提交