Skip to content
Snippets Groups Projects
  1. Apr 09, 2013
  2. Apr 07, 2013
  3. Apr 05, 2013
  4. Apr 03, 2013
  5. Apr 02, 2013
    • Paul Moore's avatar
      x86: remove the x32 syscall bitmask from syscall_get_nr() · 8b4b9f27
      Paul Moore authored
      
      Commit fca460f9 simplified the x32
      implementation by creating a syscall bitmask, equal to 0x40000000, that
      could be applied to x32 syscalls such that the masked syscall number
      would be the same as a x86_64 syscall.  While that patch was a nice
      way to simplify the code, it went a bit too far by adding the mask to
      syscall_get_nr(); returning the masked syscall numbers can cause
      confusion with callers that expect syscall numbers matching the x32
      ABI, e.g. unmasked syscall numbers.
      
      This patch fixes this by simply removing the mask from syscall_get_nr()
      while preserving the other changes from the original commit.  While
      there are several syscall_get_nr() callers in the kernel, most simply
      check that the syscall number is greater than zero, in this case this
      patch will have no effect.  Of those remaining callers, they appear
      to be few, seccomp and ftrace, and from my testing of seccomp without
      this patch the original commit definitely breaks things; the seccomp
      filter does not correctly filter the syscalls due to the difference in
      syscall numbers in the BPF filter and the value from syscall_get_nr().
      Applying this patch restores the seccomp BPF filter functionality on
      x32.
      
      I've tested this patch with the seccomp BPF filters as well as ftrace
      and everything looks reasonable to me; needless to say general usage
      seemed fine as well.
      
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Link: http://lkml.kernel.org/r/20130215172143.12549.10292.stgit@localhost
      
      
      Cc: <stable@vger.kernel.org>
      Cc: Will Drewry <wad@chromium.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      8b4b9f27
    • Heiko Carstens's avatar
      s390/mm: provide emtpy check_pgt_cache() function · 765a0cac
      Heiko Carstens authored
      
      All architectures need to provide a check_pgt_cache() function. The s390 one
      got lost somewhere.
      So reintroduce it to prevent future compile errors e.g. if Thomas Gleixner's
      idle loop rework patches get merged.
      
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      765a0cac
    • Heiko Carstens's avatar
      s390/uaccess: fix page table walk · ea81531d
      Heiko Carstens authored
      
      When translating user space addresses to kernel addresses the follow_table()
      function had two bugs:
      
      - PROT_NONE mappings could be read accessed via the kernel mapping. That is
        e.g. putting a filename into a user page, then protecting the page with
        PROT_NONE and afterwards issuing the "open" syscall with a pointer to
        the filename would incorrectly succeed.
      
      - when walking the page tables it used the pgd/pud/pmd/pte primitives which
        with dynamic page tables give no indication which real level of page tables
        is being walked (region2, region3, segment or page table). So in case of an
        exception the translation exception code passed to __handle_fault() is not
        necessarily correct.
        This is not really an issue since __handle_fault() doesn't evaluate the code.
        Only in case of e.g. a SIGBUS this code gets passed to user space. If user
        space can do something sane with the value is a different question though.
      
      To fix these issues don't use any Linux primitives. Only walk the page tables
      like the hardware would do it, however we leave quite some checks away since
      we know that we only have full size page tables and each index is within bounds.
      
      In theory this should fix all issues...
      
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Reviewed-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      ea81531d
  6. Mar 31, 2013
  7. Mar 30, 2013
  8. Mar 29, 2013
  9. Mar 28, 2013
Loading