1. 22 5月, 2014 2 次提交
  2. 21 5月, 2014 1 次提交
  3. 15 5月, 2014 1 次提交
    • L
      x86-64, modify_ldt: Make support for 16-bit segments a runtime option · fa81511b
      Linus Torvalds 提交于
      Checkin:
      
      b3b42ac2 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
      
      disabled 16-bit segments on 64-bit kernels due to an information
      leak.  However, it does seem that people are genuinely using Wine to
      run old 16-bit Windows programs on Linux.
      
      A proper fix for this ("espfix64") is coming in the upcoming merge
      window, but as a temporary fix, create a sysctl to allow the
      administrator to re-enable support for 16-bit segments.
      
      It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
      you hit this issue and care about your old Windows program more than
      you care about a kernel stack address information leak, you can do
      
         echo 1 > /proc/sys/abi/ldt16
      
      as root (add it to your startup scripts), and you should be ok.
      
      The sysctl table is only added if you have COMPAT support enabled on
      x86-64, but I assume anybody who runs old windows binaries very much
      does that ;)
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com
      Cc: <stable@vger.kernel.org>
      fa81511b
  4. 06 5月, 2014 4 次提交
  5. 25 3月, 2014 1 次提交
  6. 21 3月, 2014 2 次提交
  7. 19 3月, 2014 3 次提交
  8. 14 3月, 2014 1 次提交
  9. 19 6月, 2013 1 次提交
  10. 08 6月, 2012 1 次提交
  11. 24 3月, 2012 1 次提交
    • J
      coredump: remove VM_ALWAYSDUMP flag · 909af768
      Jason Baron 提交于
      The motivation for this patchset was that I was looking at a way for a
      qemu-kvm process, to exclude the guest memory from its core dump, which
      can be quite large.  There are already a number of filter flags in
      /proc/<pid>/coredump_filter, however, these allow one to specify 'types'
      of kernel memory, not specific address ranges (which is needed in this
      case).
      
      Since there are no more vma flags available, the first patch eliminates
      the need for the 'VM_ALWAYSDUMP' flag.  The flag is used internally by
      the kernel to mark vdso and vsyscall pages.  However, it is simple
      enough to check if a vma covers a vdso or vsyscall page without the need
      for this flag.
      
      The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
      'VM_NODUMP' flag, which can be set by userspace using new madvise flags:
      'MADV_DONTDUMP', and unset via 'MADV_DODUMP'.  The core dump filters
      continue to work the same as before unless 'MADV_DONTDUMP' is set on the
      region.
      
      The qemu code which implements this features is at:
      
        http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch
      
      In my testing the qemu core dump shrunk from 383MB -> 13MB with this
      patch.
      
      I also believe that the 'MADV_DONTDUMP' flag might be useful for
      security sensitive apps, which might want to select which areas are
      dumped.
      
      This patch:
      
      The VM_ALWAYSDUMP flag is currently used by the coredump code to
      indicate that a vma is part of a vsyscall or vdso section.  However, we
      can determine if a vma is in one these sections by checking it against
      the gate_vma and checking for a non-NULL return value from
      arch_vma_name().  Thus, freeing a valuable vma bit.
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Acked-by: NRoland McGrath <roland@hack.frob.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Avi Kivity <avi@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      909af768
  12. 22 2月, 2012 1 次提交
  13. 21 2月, 2012 1 次提交
    • H
      x32: Add x32 VDSO support · 1a21d4e0
      H. J. Lu 提交于
      Add support for the x32 VDSO.  The x32 VDSO takes advantage of the
      similarity between the x86-64 and the x32 ABIs to contain the same
      content, only the container is different, as the x32 VDSO obviously is
      an x32 shared object.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      1a21d4e0
  14. 24 3月, 2011 3 次提交
  15. 19 6月, 2010 1 次提交
    • J
      x86-64, mm: Initialize VDSO earlier on 64 bits · d7a0380d
      Jiri Slaby 提交于
      When initrd is in use and a driver does request_module() in its
      module_init (i.e. __initcall or device_initcall), a modprobe process
      is created with VDSO mapping. But VDSO is inited even in __initcall,
      i.e. on the same level (at the same time), so it may not be inited
      yet (link order matters).
      
      Move the VDSO initialization code earlier by switching to something
      before rootfs_initcall where initrd is loaded as rootfs. Specifically
      to subsys_initcall. Do it for standard 64-bit path (init_vdso_vars)
      and for compat (sysenter_setup), just in case people have 32-bit
      initrd and ia32 emulation built-in.
      
      i386 (pure 32-bit) is not affected, since sysenter_setup() is called
      from check_bugs()->identify_boot_cpu() in start_kernel() before
      rest_init()->kernel_thread(kernel_init) where even kernel_init() calls
      do_basic_setup()->do_initcalls().
      
      What this patch fixes are early modprobe crashes such as:
      Unpacking initramfs...
      Freeing initrd memory: 9324k freed
      modprobe[368]: segfault at 7fff4429c020 ip 00007fef397e160c \
          sp 00007fff442795c0 error 4 in ld-2.11.2.so[7fef397df000+1f000]
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      LKML-Reference: <1276720242-13365-1-git-send-email-jslaby@suse.cz>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      d7a0380d
  16. 12 11月, 2009 1 次提交
  17. 05 6月, 2009 1 次提交
  18. 25 12月, 2008 1 次提交
    • M
      [S390] arch_setup_additional_pages arguments · fc5243d9
      Martin Schwidefsky 提交于
      arch_setup_additional_pages currently gets two arguments, the binary
      format descripton and an indication if the process uses an executable
      stack or not. The second argument is not used by anybody, it could
      be removed without replacement.
      
      What actually does make sense is to pass an indication if the process
      uses the elf interpreter or not. The glibc code will not use anything
      from the vdso if the process does not use the dynamic linker, so for
      statically linked binaries the architecture backend can choose not
      to map the vdso.
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      fc5243d9
  19. 16 7月, 2008 1 次提交
  20. 11 7月, 2008 1 次提交
  21. 05 5月, 2008 1 次提交
  22. 01 5月, 2008 1 次提交
  23. 17 4月, 2008 2 次提交
  24. 30 1月, 2008 6 次提交
  25. 14 10月, 2007 1 次提交
    • D
      Delete filenames in comments. · 835c34a1
      Dave Jones 提交于
      Since the x86 merge, lots of files that referenced their own filenames
      are no longer correct.  Rather than keep them up to date, just delete
      them, as they add no real value.
      
      Additionally:
      - fix up comment formatting in scx200_32.c
      - Remove a credit from myself in setup_64.c from a time when we had no SCM
      - remove longwinded history from tsc_32.c which can be figured out from
        git.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      835c34a1