1. 07 9月, 2016 1 次提交
    • K
      usercopy: fold builtin_const check into inline function · 81409e9e
      Kees Cook 提交于
      Instead of having each caller of check_object_size() need to remember to
      check for a const size parameter, move the check into check_object_size()
      itself. This actually matches the original implementation in PaX, though
      this commit cleans up the now-redundant builtin_const() calls in the
      various architectures.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      81409e9e
  2. 03 8月, 2016 1 次提交
    • A
      signal: consolidate {TS,TLF}_RESTORE_SIGMASK code · 7e781418
      Andy Lutomirski 提交于
      In general, there's no need for the "restore sigmask" flag to live in
      ti->flags.  alpha, ia64, microblaze, powerpc, sh, sparc (64-bit only),
      tile, and x86 use essentially identical alternative implementations,
      placing the flag in ti->status.
      
      Replace those optimized implementations with an equally good common
      implementation that stores it in a bitfield in struct task_struct and
      drop the custom implementations.
      
      Additional architectures can opt in by removing their
      TIF_RESTORE_SIGMASK defines.
      
      Link: http://lkml.kernel.org/r/8a14321d64a28e40adfddc90e18a96c086a6d6f9.1468522723.git.luto@kernel.orgSigned-off-by: NAndy Lutomirski <luto@kernel.org>
      Tested-by: Michael Ellerman <mpe@ellerman.id.au>	[powerpc]
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7e781418
  3. 27 7月, 2016 2 次提交
    • K
      mm: Hardened usercopy · f5509cc1
      Kees Cook 提交于
      This is the start of porting PAX_USERCOPY into the mainline kernel. This
      is the first set of features, controlled by CONFIG_HARDENED_USERCOPY. The
      work is based on code by PaX Team and Brad Spengler, and an earlier port
      from Casey Schaufler. Additional non-slab page tests are from Rik van Riel.
      
      This patch contains the logic for validating several conditions when
      performing copy_to_user() and copy_from_user() on the kernel object
      being copied to/from:
      - address range doesn't wrap around
      - address range isn't NULL or zero-allocated (with a non-zero copy size)
      - if on the slab allocator:
        - object size must be less than or equal to copy size (when check is
          implemented in the allocator, which appear in subsequent patches)
      - otherwise, object must not span page allocations (excepting Reserved
        and CMA ranges)
      - if on the stack
        - object must not extend before/after the current process stack
        - object must be contained by a valid stack frame (when there is
          arch/build support for identifying stack frames)
      - object must not overlap with kernel text
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Tested-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Tested-by: NMichael Ellerman <mpe@ellerman.id.au>
      f5509cc1
    • K
      mm: Implement stack frame object validation · 0f60a8ef
      Kees Cook 提交于
      This creates per-architecture function arch_within_stack_frames() that
      should validate if a given object is contained by a kernel stack frame.
      Initial implementation is on x86.
      
      This is based on code from PaX.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      0f60a8ef
  4. 15 1月, 2016 1 次提交
    • V
      kmemcg: account certain kmem allocations to memcg · 5d097056
      Vladimir Davydov 提交于
      Mark those kmem allocations that are known to be easily triggered from
      userspace as __GFP_ACCOUNT/SLAB_ACCOUNT, which makes them accounted to
      memcg.  For the list, see below:
      
       - threadinfo
       - task_struct
       - task_delay_info
       - pid
       - cred
       - mm_struct
       - vm_area_struct and vm_region (nommu)
       - anon_vma and anon_vma_chain
       - signal_struct
       - sighand_struct
       - fs_struct
       - files_struct
       - fdtable and fdtable->full_fds_bits
       - dentry and external_name
       - inode for all filesystems. This is the most tedious part, because
         most filesystems overwrite the alloc_inode method.
      
      The list is far from complete, so feel free to add more objects.
      Nevertheless, it should be close to "account everything" approach and
      keep most workloads within bounds.  Malevolent users will be able to
      breach the limit, but this was possible even with the former "account
      everything" approach (simply because it did not account everything in
      fact).
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NVladimir Davydov <vdavydov@virtuozzo.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5d097056
  5. 05 6月, 2014 1 次提交
    • V
      mm: get rid of __GFP_KMEMCG · 52383431
      Vladimir Davydov 提交于
      Currently to allocate a page that should be charged to kmemcg (e.g.
      threadinfo), we pass __GFP_KMEMCG flag to the page allocator.  The page
      allocated is then to be freed by free_memcg_kmem_pages.  Apart from
      looking asymmetrical, this also requires intrusion to the general
      allocation path.  So let's introduce separate functions that will
      alloc/free pages charged to kmemcg.
      
      The new functions are called alloc_kmem_pages and free_kmem_pages.  They
      should be used when the caller actually would like to use kmalloc, but
      has to fall back to the page allocator for the allocation is large.
      They only differ from alloc_pages and free_pages in that besides
      allocating or freeing pages they also charge them to the kmem resource
      counter of the current memory cgroup.
      
      [sfr@canb.auug.org.au: export kmalloc_order() to modules]
      Signed-off-by: NVladimir Davydov <vdavydov@parallels.com>
      Acked-by: NGreg Thelen <gthelen@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Cc: Glauber Costa <glommer@gmail.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      52383431
  6. 18 4月, 2014 1 次提交
  7. 25 9月, 2013 2 次提交
  8. 19 12月, 2012 1 次提交
    • G
      fork: protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs · 2ad306b1
      Glauber Costa 提交于
      Because those architectures will draw their stacks directly from the page
      allocator, rather than the slab cache, we can directly pass __GFP_KMEMCG
      flag, and issue the corresponding free_pages.
      
      This code path is taken when the architecture doesn't define
      CONFIG_ARCH_THREAD_INFO_ALLOCATOR (only ia64 seems to), and has
      THREAD_SIZE >= PAGE_SIZE.  Luckily, most - if not all - of the remaining
      architectures fall in this category.
      
      This will guarantee that every stack page is accounted to the memcg the
      process currently lives on, and will have the allocations to fail if they
      go over limit.
      
      For the time being, I am defining a new variant of THREADINFO_GFP, not to
      mess with the other path.  Once the slab is also tracked by memcg, we can
      get rid of that flag.
      
      Tested to successfully protect against :(){ :|:& };:
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Acked-by: NFrederic Weisbecker <fweisbec@redhat.com>
      Acked-by: NKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Reviewed-by: NMichal Hocko <mhocko@suse.cz>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: JoonSoo Kim <js1304@gmail.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Suleiman Souhlal <suleiman@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2ad306b1
  9. 02 6月, 2012 3 次提交
  10. 08 5月, 2012 1 次提交
  11. 23 5月, 2011 1 次提交
  12. 02 2月, 2011 1 次提交
  13. 18 9月, 2010 1 次提交
  14. 06 4月, 2009 1 次提交
    • D
      futex: add requeue_pi functionality · 52400ba9
      Darren Hart 提交于
      PI Futexes and their underlying rt_mutex cannot be left ownerless if
      there are pending waiters as this will break the PI boosting logic, so
      the standard requeue commands aren't sufficient.  The new commands
      properly manage pi futex ownership by ensuring a futex with waiters
      has an owner at all times.  This will allow glibc to properly handle
      pi mutexes with pthread_condvars.
      
      The approach taken here is to create two new futex op codes:
      
      FUTEX_WAIT_REQUEUE_PI:
      Tasks will use this op code to wait on a futex (such as a non-pi waitqueue)
      and wake after they have been requeued to a pi futex.  Prior to returning to
      userspace, they will acquire this pi futex (and the underlying rt_mutex).
      
      futex_wait_requeue_pi() is the result of a high speed collision between
      futex_wait() and futex_lock_pi() (with the first part of futex_lock_pi() being
      done by futex_proxy_trylock_atomic() on behalf of the top_waiter).
      
      FUTEX_REQUEUE_PI (and FUTEX_CMP_REQUEUE_PI):
      This call must be used to wake tasks waiting with FUTEX_WAIT_REQUEUE_PI,
      regardless of how many tasks the caller intends to wake or requeue.
      pthread_cond_broadcast() should call this with nr_wake=1 and
      nr_requeue=INT_MAX.  pthread_cond_signal() should call this with nr_wake=1 and
      nr_requeue=0.  The reason being we need both callers to get the benefit of the
      futex_proxy_trylock_atomic() routine.  futex_requeue() also enqueues the
      top_waiter on the rt_mutex via rt_mutex_start_proxy_lock().
      Signed-off-by: NDarren Hart <dvhltc@us.ibm.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      52400ba9
  15. 06 9月, 2008 1 次提交
  16. 30 4月, 2008 3 次提交
  17. 17 4月, 2008 1 次提交
  18. 02 2月, 2008 1 次提交
    • T
      futex: Add bitset conditional wait/wakeup functionality · cd689985
      Thomas Gleixner 提交于
      To allow the implementation of optimized rw-locks in user space, glibc
      needs a possibility to select waiters for wakeup depending on a bitset
      mask.
      
      This requires two new futex OPs: FUTEX_WAIT_BITS and FUTEX_WAKE_BITS
      These OPs are basically the same as FUTEX_WAIT and FUTEX_WAKE plus an
      additional argument - a bitset. Further the FUTEX_WAIT_BITS OP is
      expecting an absolute timeout value instead of the relative one, which
      is used for the FUTEX_WAIT OP.
      
      FUTEX_WAIT_BITS calls into the kernel with a bitset. The bitset is
      stored in the futex_q structure, which is used to enqueue the waiter
      into the hashed futex waitqueue.
      
      FUTEX_WAKE_BITS also calls into the kernel with a bitset. The wakeup
      function logically ANDs the bitset with the bitset stored in each
      waiters futex_q structure. If the result is zero (i.e. none of the set
      bits in the bitsets is matching), then the waiter is not woken up. If
      the result is not zero (i.e. one of the set bits in the bitsets is
      matching), then the waiter is woken.
      
      The bitset provided by the caller must be non zero. In case the
      provided bitset is zero the kernel returns EINVAL.
      
      Internaly the new OPs are only extensions to the existing FUTEX_WAIT
      and FUTEX_WAKE functions. The existing OPs hand a bitset with all bits
      set into the futex_wait() and futex_wake() functions.
      Signed-off-by: NThomas Gleixner <tgxl@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cd689985
  19. 30 1月, 2008 1 次提交
  20. 05 12月, 2007 1 次提交
    • S
      futex: fix for futex_wait signal stack corruption · ce6bd420
      Steven Rostedt 提交于
      David Holmes found a bug in the -rt tree with respect to
      pthread_cond_timedwait. After trying his test program on the latest git
      from mainline, I found the bug was there too.  The bug he was seeing
      that his test program showed, was that if one were to do a "Ctrl-Z" on a
      process that was in the pthread_cond_timedwait, and then did a "bg" on
      that process, it would return with a "-ETIMEDOUT" but early. That is,
      the timer would go off early.
      
      Looking into this, I found the source of the problem. And it is a rather
      nasty bug at that.
      
      Here's the relevant code from kernel/futex.c: (not in order in the file)
      
      [...]
      smlinkage long sys_futex(u32 __user *uaddr, int op, u32 val,
                                struct timespec __user *utime, u32 __user *uaddr2,
                                u32 val3)
      {
              struct timespec ts;
              ktime_t t, *tp = NULL;
              u32 val2 = 0;
              int cmd = op & FUTEX_CMD_MASK;
      
              if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI)) {
                      if (copy_from_user(&ts, utime, sizeof(ts)) != 0)
                              return -EFAULT;
                      if (!timespec_valid(&ts))
                              return -EINVAL;
      
                      t = timespec_to_ktime(ts);
                      if (cmd == FUTEX_WAIT)
                              t = ktime_add(ktime_get(), t);
                      tp = &t;
              }
      [...]
              return do_futex(uaddr, op, val, tp, uaddr2, val2, val3);
      }
      
      [...]
      
      long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,
                      u32 __user *uaddr2, u32 val2, u32 val3)
      {
              int ret;
              int cmd = op & FUTEX_CMD_MASK;
              struct rw_semaphore *fshared = NULL;
      
              if (!(op & FUTEX_PRIVATE_FLAG))
                      fshared = &current->mm->mmap_sem;
      
              switch (cmd) {
              case FUTEX_WAIT:
                      ret = futex_wait(uaddr, fshared, val, timeout);
      
      [...]
      
      static int futex_wait(u32 __user *uaddr, struct rw_semaphore *fshared,
                            u32 val, ktime_t *abs_time)
      {
      [...]
                     struct restart_block *restart;
                      restart = &current_thread_info()->restart_block;
                      restart->fn = futex_wait_restart;
                      restart->arg0 = (unsigned long)uaddr;
                      restart->arg1 = (unsigned long)val;
                      restart->arg2 = (unsigned long)abs_time;
                      restart->arg3 = 0;
                      if (fshared)
                              restart->arg3 |= ARG3_SHARED;
                      return -ERESTART_RESTARTBLOCK;
      [...]
      
      static long futex_wait_restart(struct restart_block *restart)
      {
              u32 __user *uaddr = (u32 __user *)restart->arg0;
              u32 val = (u32)restart->arg1;
              ktime_t *abs_time = (ktime_t *)restart->arg2;
              struct rw_semaphore *fshared = NULL;
      
              restart->fn = do_no_restart_syscall;
              if (restart->arg3 & ARG3_SHARED)
                      fshared = &current->mm->mmap_sem;
              return (long)futex_wait(uaddr, fshared, val, abs_time);
      }
      
      So when the futex_wait is interrupt by a signal we break out of the
      hrtimer code and set up or return from signal. This code does not return
      back to userspace, so we set up a RESTARTBLOCK.  The bug here is that we
      save the "abs_time" which is a pointer to the stack variable "ktime_t t"
      from sys_futex.
      
      This returns and unwinds the stack before we get to call our signal. On
      return from the signal we go to futex_wait_restart, where we update all
      the parameters for futex_wait and call it. But here we have a problem
      where abs_time is no longer valid.
      
      I verified this with print statements, and sure enough, what abs_time
      was set to ends up being garbage when we get to futex_wait_restart.
      
      The solution I did to solve this (with input from Linus Torvalds)
      was to add unions to the restart_block to allow system calls to
      use the restart with specific parameters.  This way the futex code now
      saves the time in a 64bit value in the restart block instead of storing
      it on the stack.
      
      Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64
      in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
      Not sure what that is there for.  If this turns out to be a problem, I've
      tested this with using "unsigned int" for u32 and "unsigned long long" for
      u64 and it worked just the same. I'm using u32 and u64 just to be
      consistent with what the futex code uses.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ce6bd420
  21. 14 11月, 2005 1 次提交
  22. 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