1. 06 2月, 2007 2 次提交
    • G
      [S390] noexec protection · c1821c2e
      Gerald Schaefer 提交于
      This provides a noexec protection on s390 hardware. Our hardware does
      not have any bits left in the pte for a hw noexec bit, so this is a
      different approach using shadow page tables and a special addressing
      mode that allows separate address spaces for code and data.
      
      As a special feature of our "secondary-space" addressing mode, separate
      page tables can be specified for the translation of data addresses
      (storage operands) and instruction addresses. The shadow page table is
      used for the instruction addresses and the standard page table for the
      data addresses.
      The shadow page table is linked to the standard page table by a pointer
      in page->lru.next of the struct page corresponding to the page that
      contains the standard page table (since page->private is not really
      private with the pte_lock and the page table pages are not in the LRU
      list).
      Depending on the software bits of a pte, it is either inserted into
      both page tables or just into the standard (data) page table. Pages of
      a vma that does not have the VM_EXEC bit set get mapped only in the
      data address space. Any try to execute code on such a page will cause a
      page translation exception. The standard reaction to this is a SIGSEGV
      with two exceptions: the two system call opcodes 0x0a77 (sys_sigreturn)
      and 0x0aad (sys_rt_sigreturn) are allowed. They are stored by the
      kernel to the signal stack frame. Unfortunately, the signal return
      mechanism cannot be modified to use an SA_RESTORER because the
      exception unwinding code depends on the system call opcode stored
      behind the signal stack frame.
      
      This feature requires that user space is executed in secondary-space
      mode and the kernel in home-space mode, which means that the addressing
      modes need to be switched and that the noexec protection only works
      for user space.
      After switching the addressing modes, we cannot use the mvcp/mvcs
      instructions anymore to copy between kernel and user space. A new
      mvcos instruction has been added to the z9 EC/BC hardware which allows
      to copy between arbitrary address spaces, but on older hardware the
      page tables need to be walked manually.
      Signed-off-by: NGerald Schaefer <geraldsc@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c1821c2e
    • J
      [S390] move crypto options and some cleanup. · 86aa9fc2
      Jan Glauber 提交于
      This patch moves the config options for the s390 crypto instructions
      to the standard "Hardware crypto devices" menu. In addition some
      cleanup has been done: use a flag for supported keylengths, add a
      warning about machien limitation, return ENOTSUPP in case the
      hardware has no support, remove superfluous printks and update
      email addresses.
      Signed-off-by: NJan Glauber <jan.glauber@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      86aa9fc2
  2. 16 12月, 2006 1 次提交
  3. 08 12月, 2006 1 次提交
  4. 06 11月, 2006 1 次提交
    • H
      [S390] revert add_active_range() usage patch. · bcc8bcb1
      Heiko Carstens 提交于
      Commit 7676bef9 breaks DCSS support on
      s390. DCSS needs initialized struct pages to work. With the usage of
      add_active_range() only the struct pages for physically present pages
      are initialized.
      This could be fixed if the DCSS driver would initiliaze the struct pages
      itself, but this doesn't work too. This is because the mem_map array
      does not include holes after the last present memory area and therefore
      there is nothing that could be initialized.
      To fix this and to avoid some dirty hacks revert this patch for now.
      Will be added later when we move to a virtual mem_map.
      
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Adrian Bunk <bunk@stusta.de>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      bcc8bcb1
  5. 19 10月, 2006 1 次提交
  6. 06 10月, 2006 1 次提交
  7. 05 10月, 2006 2 次提交
  8. 20 9月, 2006 1 次提交
  9. 27 7月, 2006 1 次提交
  10. 11 4月, 2006 1 次提交
  11. 12 2月, 2006 1 次提交
  12. 02 2月, 2006 1 次提交
  13. 07 1月, 2006 5 次提交
  14. 18 9月, 2005 1 次提交
  15. 30 7月, 2005 1 次提交
  16. 26 6月, 2005 1 次提交
  17. 01 5月, 2005 1 次提交
  18. 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