1. 22 5月, 2017 2 次提交
    • L
      Clean up x86 unsafe_get/put_user() type handling · 334a023e
      Linus Torvalds 提交于
      Al noticed that unsafe_put_user() had type problems, and fixed them in
      commit a7cc722f ("fix unsafe_put_user()"), which made me look more
      at those functions.
      
      It turns out that unsafe_get_user() had a type issue too: it limited the
      largest size of the type it could handle to "unsigned long".  Which is
      fine with the current users, but doesn't match our existing normal
      get_user() semantics, which can also handle "u64" even when that does
      not fit in a long.
      
      While at it, also clean up the type cast in unsafe_put_user().  We
      actually want to just make it an assignment to the expected type of the
      pointer, because we actually do want warnings from types that don't
      convert silently.  And it makes the code more readable by not having
      that one very long and complex line.
      
      [ This patch might become stable material if we ever end up back-porting
        any new users of the unsafe uaccess code, but as things stand now this
        doesn't matter for any current existing uses. ]
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      334a023e
    • A
      fix unsafe_put_user() · a7cc722f
      Al Viro 提交于
      __put_user_size() relies upon its first argument having the same type as what
      the second one points to; the only other user makes sure of that and
      unsafe_put_user() should do the same.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      a7cc722f
  2. 30 3月, 2017 1 次提交
  3. 29 3月, 2017 1 次提交
  4. 06 3月, 2017 2 次提交
  5. 06 12月, 2016 1 次提交
  6. 28 9月, 2016 1 次提交
    • A
      x86: separate extable.h, switch sections.h to it · 45caf470
      Al Viro 提交于
      drivers/platform/x86/dell-smo8800.c is touched due to the following obscenity:
      drivers/platform/x86/dell-smo8800.c ->
      	linux/interrupt.h ->
      		linux/hardirq.h ->
      			asm/hardirq.h ->
      				linux/irq.h ->
      					asm/hw_irq.h ->
      						asm/sections.h ->
      							asm/uaccess.h
      is the only chain of includes pulling asm/uaccess.h there.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      45caf470
  7. 16 9月, 2016 1 次提交
  8. 07 9月, 2016 1 次提交
    • K
      x86/uaccess: force copy_*_user() to be inlined · e6971009
      Kees Cook 提交于
      As already done with __copy_*_user(), mark copy_*_user() as __always_inline.
      Without this, the checks for things like __builtin_const_p() won't work
      consistently in either hardened usercopy nor the recent adjustments for
      detecting usercopy overflows at compile time.
      
      The change in kernel text size is detectable, but very small:
      
       text      data     bss     dec      hex     filename
      12118735  5768608 14229504 32116847 1ea106f vmlinux.before
      12120207  5768608 14229504 32118319 1ea162f vmlinux.after
      Signed-off-by: NKees Cook <keescook@chromium.org>
      e6971009
  9. 31 8月, 2016 1 次提交
    • J
      mm/usercopy: get rid of CONFIG_DEBUG_STRICT_USER_COPY_CHECKS · 0d025d27
      Josh Poimboeuf 提交于
      There are three usercopy warnings which are currently being silenced for
      gcc 4.6 and newer:
      
      1) "copy_from_user() buffer size is too small" compile warning/error
      
         This is a static warning which happens when object size and copy size
         are both const, and copy size > object size.  I didn't see any false
         positives for this one.  So the function warning attribute seems to
         be working fine here.
      
         Note this scenario is always a bug and so I think it should be
         changed to *always* be an error, regardless of
         CONFIG_DEBUG_STRICT_USER_COPY_CHECKS.
      
      2) "copy_from_user() buffer size is not provably correct" compile warning
      
         This is another static warning which happens when I enable
         __compiletime_object_size() for new compilers (and
         CONFIG_DEBUG_STRICT_USER_COPY_CHECKS).  It happens when object size
         is const, but copy size is *not*.  In this case there's no way to
         compare the two at build time, so it gives the warning.  (Note the
         warning is a byproduct of the fact that gcc has no way of knowing
         whether the overflow function will be called, so the call isn't dead
         code and the warning attribute is activated.)
      
         So this warning seems to only indicate "this is an unusual pattern,
         maybe you should check it out" rather than "this is a bug".
      
         I get 102(!) of these warnings with allyesconfig and the
         __compiletime_object_size() gcc check removed.  I don't know if there
         are any real bugs hiding in there, but from looking at a small
         sample, I didn't see any.  According to Kees, it does sometimes find
         real bugs.  But the false positive rate seems high.
      
      3) "Buffer overflow detected" runtime warning
      
         This is a runtime warning where object size is const, and copy size >
         object size.
      
      All three warnings (both static and runtime) were completely disabled
      for gcc 4.6 with the following commit:
      
        2fb0815c ("gcc4: disable __compiletime_object_size for GCC 4.6+")
      
      That commit mistakenly assumed that the false positives were caused by a
      gcc bug in __compiletime_object_size().  But in fact,
      __compiletime_object_size() seems to be working fine.  The false
      positives were instead triggered by #2 above.  (Though I don't have an
      explanation for why the warnings supposedly only started showing up in
      gcc 4.6.)
      
      So remove warning #2 to get rid of all the false positives, and re-enable
      warnings #1 and #3 by reverting the above commit.
      
      Furthermore, since #1 is a real bug which is detected at compile time,
      upgrade it to always be an error.
      
      Having done all that, CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is no longer
      needed.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Nilay Vaish <nilayvaish@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0d025d27
  10. 09 8月, 2016 1 次提交
    • L
      unsafe_[get|put]_user: change interface to use a error target label · 1bd4403d
      Linus Torvalds 提交于
      When I initially added the unsafe_[get|put]_user() helpers in commit
      5b24a7a2 ("Add 'unsafe' user access functions for batched
      accesses"), I made the mistake of modeling the interface on our
      traditional __[get|put]_user() functions, which return zero on success,
      or -EFAULT on failure.
      
      That interface is fairly easy to use, but it's actually fairly nasty for
      good code generation, since it essentially forces the caller to check
      the error value for each access.
      
      In particular, since the error handling is already internally
      implemented with an exception handler, and we already use "asm goto" for
      various other things, we could fairly easily make the error cases just
      jump directly to an error label instead, and avoid the need for explicit
      checking after each operation.
      
      So switch the interface to pass in an error label, rather than checking
      the error value in the caller.  Best do it now before we start growing
      more users (the signal handling code in particular would be a good place
      to use the new interface).
      
      So rather than
      
      	if (unsafe_get_user(x, ptr))
      		... handle error ..
      
      the interface is now
      
      	unsafe_get_user(x, ptr, label);
      
      where an error during the user mode fetch will now just cause a jump to
      'label' in the caller.
      
      Right now the actual _implementation_ of this all still ends up being a
      "if (err) goto label", and does not take advantage of any exception
      label tricks, but for "unsafe_put_user()" in particular it should be
      fairly straightforward to convert to using the exception table model.
      
      Note that "unsafe_get_user()" is much harder to convert to a clever
      exception table model, because current versions of gcc do not allow the
      use of "asm goto" (for the exception) with output values (for the actual
      value to be fetched).  But that is hopefully not a limitation in the
      long term.
      
      [ Also note that it might be a good idea to switch unsafe_get_user() to
        actually _return_ the value it fetches from user space, but this
        commit only changes the error handling semantics ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1bd4403d
  11. 27 7月, 2016 1 次提交
  12. 15 7月, 2016 2 次提交
  13. 21 5月, 2016 1 次提交
  14. 12 5月, 2016 1 次提交
    • M
      x86/extable: ensure entries are swapped completely when sorting · 50c73890
      Mathias Krause 提交于
      The x86 exception table sorting was changed in commit 29934b0f
      ("x86/extable: use generic search and sort routines") to use the arch
      independent code in lib/extable.c.  However, the patch was mangled
      somehow on its way into the kernel from the last version posted at [1].
      The committed version kind of attempted to incorporate the changes of
      commit 548acf19 ("x86/mm: Expand the exception table logic to allow
      new handling options") as in _completely_ _ignoring_ the x86 specific
      'handler' member of struct exception_table_entry.  This effectively
      broke the sorting as entries will only partly be swapped now.
      
      Fortunately, the x86 Kconfig selects BUILDTIME_EXTABLE_SORT, so the
      exception table doesn't need to be sorted at runtime. However, in case
      that ever changes, we better not break the exception table sorting just
      because of that.
      
      [ Ard Biesheuvel points out that BUILDTIME_EXTABLE_SORT applies to the
        core image only, but we still rely on the sorting routines for modules
        in that case - Linus ]
      
      Fix this by providing a swap_ex_entry_fixup() macro that takes care of
      the 'handler' member.
      
      [1] https://lkml.org/lkml/2016/1/27/232Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Fixes: 29934b0f ("x86/extable: use generic search and sort routines")
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      50c73890
  15. 11 5月, 2016 1 次提交
    • M
      x86/extable: Ensure entries are swapped completely when sorting · 67d7a982
      Mathias Krause 提交于
      The x86 exception table sorting was changed in this recent commit:
      
        29934b0f ("x86/extable: use generic search and sort routines")
      
      ... to use the arch independent code in lib/extable.c. However, the
      patch was mangled somehow on its way into the kernel from the last
      version posted at:
      
        https://lkml.org/lkml/2016/1/27/232
      
      The committed version kind of attempted to incorporate the changes of
      contemporary commit done in the x86 tree:
      
        548acf19 ("x86/mm: Expand the exception table logic to allow new handling options")
      
      ... as in _completely_ _ignoring_ the x86 specific 'handler' member of
      struct exception_table_entry. This effectively broke the sorting as
      entries will only be partly swapped now.
      
      Fortunately, the x86 Kconfig selects BUILDTIME_EXTABLE_SORT, so the
      exception table doesn't need to be sorted at runtime. However, in case
      that ever changes, we better not break the exception table sorting just
      because of that.
      
      Fix this by providing a swap_ex_entry_fixup() macro that takes care of
      the 'handler' member.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Link: http://lkml.kernel.org/r/1462914422-2911-1-git-send-email-minipli@googlemail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      67d7a982
  16. 13 4月, 2016 3 次提交
  17. 23 3月, 2016 1 次提交
  18. 24 2月, 2016 1 次提交
  19. 18 2月, 2016 1 次提交
  20. 18 12月, 2015 2 次提交
    • L
      Add 'unsafe' user access functions for batched accesses · 5b24a7a2
      Linus Torvalds 提交于
      The naming is meant to discourage random use: the helper functions are
      not really any more "unsafe" than the traditional double-underscore
      functions (which need the address range checking), but they do need even
      more infrastructure around them, and should not be used willy-nilly.
      
      In addition to checking the access range, these user access functions
      require that you wrap the user access with a "user_acess_{begin,end}()"
      around it.
      
      That allows architectures that implement kernel user access control
      (x86: SMAP, arm64: PAN) to do the user access control in the wrapping
      user_access_begin/end part, and then batch up the actual user space
      accesses using the new interfaces.
      
      The main (and hopefully only) use for these are for core generic access
      helpers, initially just the generic user string functions
      (strnlen_user() and strncpy_from_user()).
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5b24a7a2
    • L
      x86: reorganize SMAP handling in user space accesses · 11f1a4b9
      Linus Torvalds 提交于
      This reorganizes how we do the stac/clac instructions in the user access
      code.  Instead of adding the instructions directly to the same inline
      asm that does the actual user level access and exception handling, add
      them at a higher level.
      
      This is mainly preparation for the next step, where we will expose an
      interface to allow users to mark several accesses together as being user
      space accesses, but it does already clean up some code:
      
       - the inlined trivial cases of copy_in_user() now do stac/clac just
         once over the accesses: they used to do one pair around the user
         space read, and another pair around the write-back.
      
       - the {get,put}_user_ex() macros that are used with the catch/try
         handling don't do any stac/clac at all, because that happens in the
         try/catch surrounding them.
      
      Other than those two cleanups that happened naturally from the
      re-organization, this should not make any difference. Yet.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      11f1a4b9
  21. 23 11月, 2015 1 次提交
  22. 07 10月, 2015 2 次提交
  23. 19 5月, 2015 1 次提交
  24. 13 1月, 2015 1 次提交
  25. 28 12月, 2013 2 次提交
  26. 17 12月, 2013 1 次提交
  27. 26 10月, 2013 2 次提交
    • J
      x86: Unify copy_to_user() and add size checking to it · 7a3d9b0f
      Jan Beulich 提交于
      Similarly to copy_from_user(), where the range check is to
      protect against kernel memory corruption, copy_to_user() can
      benefit from such checking too: Here it protects against kernel
      information leaks.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Cc: <arjan@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/5265059502000078000FC4F6@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      7a3d9b0f
    • J
      x86: Unify copy_from_user() size checking · 3df7b41a
      Jan Beulich 提交于
      Commits 4a312769 ("x86: Turn the
      copy_from_user check into an (optional) compile time warning")
      and 63312b6a ("x86: Add a
      Kconfig option to turn the copy_from_user warnings into errors")
      touched only the 32-bit variant of copy_from_user(), whereas the
      original commit 9f0cf4ad ("x86:
      Use __builtin_object_size() to validate the buffer size for
      copy_from_user()") also added the same code to the 64-bit one.
      
      Further the earlier conversion from an inline WARN() to the call
      to copy_from_user_overflow() went a little too far: When the
      number of bytes to be copied is not a constant (e.g. [looking at
      3.11] in drivers/net/tun.c:__tun_chr_ioctl() or
      drivers/pci/pcie/aer/aer_inject.c:aer_inject_write()), the
      compiler will always have to keep the funtion call, and hence
      there will always be a warning. By using __builtin_constant_p()
      we can avoid this.
      
      And then this slightly extends the effect of
      CONFIG_DEBUG_STRICT_USER_COPY_CHECKS in that apart from
      converting warnings to errors in the constant size case, it
      retains the (possibly wrong) warnings in the non-constant size
      case, such that if someone is prepared to get a few false
      positives, (s)he'll be able to recover the current behavior
      (except that these diagnostics now will never be converted to
      errors).
      
      Since the 32-bit variant (intentionally) didn't call
      might_fault(), the unification results in this being called
      twice now. Adding a suitable #ifdef would be the alternative if
      that's a problem.
      
      I'd like to point out though that with
      __compiletime_object_size() being restricted to gcc before 4.6,
      the whole construct is going to become more and more pointless
      going forward. I would question however that commit
      2fb0815c ("gcc4: disable
      __compiletime_object_size for GCC 4.6+") was really necessary,
      and instead this should have been dealt with as is done here
      from the beginning.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/5265056D02000078000FC4F3@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3df7b41a
  28. 30 8月, 2013 2 次提交
  29. 13 2月, 2013 2 次提交