1. 15 4月, 2015 3 次提交
    • K
      s390: redefine randomize_et_dyn for ELF_ET_DYN_BASE · c6f5b001
      Kees Cook 提交于
      In preparation for moving ET_DYN randomization into the ELF loader (which
      requires a static ELF_ET_DYN_BASE), this redefines s390's existing ET_DYN
      randomization in a call to arch_mmap_rnd(). This refactoring results in
      the same ET_DYN randomization on s390.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c6f5b001
    • K
      mm: expose arch_mmap_rnd when available · 2b68f6ca
      Kees Cook 提交于
      When an architecture fully supports randomizing the ELF load location,
      a per-arch mmap_rnd() function is used to find a randomized mmap base.
      In preparation for randomizing the location of ET_DYN binaries
      separately from mmap, this renames and exports these functions as
      arch_mmap_rnd(). Additionally introduces CONFIG_ARCH_HAS_ELF_RANDOMIZE
      for describing this feature on architectures that support it
      (which is a superset of ARCH_BINFMT_ELF_RANDOMIZE_PIE, since s390
      already supports a separated ET_DYN ASLR from mmap ASLR without the
      ARCH_BINFMT_ELF_RANDOMIZE_PIE logic).
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Hector Marco-Gisbert <hecmargi@upv.es>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      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: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: "David A. Long" <dave.long@linaro.org>
      Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Arun Chandran <achandran@mvista.com>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: Min-Hua Chen <orca.chen@gmail.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Alex Smith <alex@alex-smith.me.uk>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Vineeth Vijayan <vvijayan@mvista.com>
      Cc: Jeff Bailey <jeffbailey@google.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Behan Webster <behanw@converseincode.com>
      Cc: Ismael Ripoll <iripoll@upv.es>
      Cc: Jan-Simon Mller <dl9pf@gmx.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b68f6ca
    • K
      s390: standardize mmap_rnd() usage · 8e89a356
      Kees Cook 提交于
      In preparation for splitting out ET_DYN ASLR, this refactors the use of
      mmap_rnd() to be used similarly to arm and x86, and extracts the
      checking of PF_RANDOMIZE.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8e89a356
  2. 19 2月, 2015 1 次提交
    • M
      s390/mm: align 64-bit PIE binaries to 4GB · 4ba2815d
      Martin Schwidefsky 提交于
      The base address (STACK_TOP / 3 * 2) for a 64-bit program is two thirds
      into the 4GB segment at 0x2aa00000000. The randomization added on z13
      can eat another 1GB of the remaining 1.33GB to the next 4GB boundary.
      In the worst case 300MB are left for the executable + bss which may
      cross into the next 4GB segment. This is bad for branch prediction,
      therefore align the base address to 4GB to give the program more room
      before it crosses the 4GB boundary.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      4ba2815d
  3. 22 1月, 2015 1 次提交
  4. 13 11月, 2013 1 次提交
  5. 04 11月, 2013 1 次提交
    • M
      s390/mm,tlb: correct tlb flush on page table upgrade · 10607864
      Martin Schwidefsky 提交于
      The IDTE instruction used to flush TLB entries for a specific address
      space uses the address-space-control element (ASCE) to identify
      affected TLB entries. The upgrade of a page table adds a new top
      level page table which changes the ASCE. The TLB entries associated
      with the old ASCE need to be flushed and the ASCE for the address space
      needs to be replaced synchronously on all CPUs which currently use it.
      The concept of a lazy ASCE update with an exception handler is broken.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      10607864
  6. 11 7月, 2013 1 次提交
  7. 14 2月, 2013 1 次提交
  8. 26 7月, 2012 1 次提交
  9. 20 7月, 2012 1 次提交
    • H
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens 提交于
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  10. 23 3月, 2012 1 次提交
  11. 27 2月, 2012 1 次提交
  12. 30 10月, 2011 1 次提交
  13. 12 1月, 2011 5 次提交
  14. 14 1月, 2010 1 次提交
  15. 12 6月, 2009 1 次提交
  16. 18 3月, 2009 2 次提交
    • M
      [S390] make page table upgrade work again · 0fb1d9bc
      Martin Schwidefsky 提交于
      After TASK_SIZE now gives the current size of the address space the
      upgrade of a 64 bit process from 3 to 4 levels of page table  needs
      to use the arch_mmap_check hook to catch large mmap lengths. The
      get_unmapped_area* functions need to check for -ENOMEM from the
      arch_get_unmapped_area*, upgrade the page table and retry.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      0fb1d9bc
    • M
      [S390] make page table walking more robust · f481bfaf
      Martin Schwidefsky 提交于
      Make page table walking on s390 more robust. The current code requires
      that the pgd/pud/pmd/pte loop is only done for address ranges that are
      below the end address of the last vma of the address space. But this
      is not always true, e.g. the generic page table walker does not guarantee
      this. Change TASK_SIZE/TASK_SIZE_OF to reflect the current size of the
      address space. This makes the generic page table walker happy but it
      breaks the upgrade of a 3 level page table to a 4 level page table.
      To make the upgrade work again another fix is required.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f481bfaf
  17. 10 2月, 2008 1 次提交
    • M
      [S390] dynamic page tables. · 6252d702
      Martin Schwidefsky 提交于
      Add support for different number of page table levels dependent
      on the highest address used for a process. This will cause a 31 bit
      process to use a two level page table instead of the four level page
      table that is the default after the pud has been introduced. Likewise
      a normal 64 bit process will use three levels instead of four. Only
      if a process runs out of the 4 tera bytes which can be addressed with
      a three level page table the fourth level is dynamically added. Then
      the process can use up to 8 peta byte.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      6252d702
  18. 07 1月, 2006 1 次提交
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4