1. 08 1月, 2015 1 次提交
  2. 17 10月, 2014 1 次提交
    • D
      random: add and use memzero_explicit() for clearing data · d4c5efdb
      Daniel Borkmann 提交于
      zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
      memset() calls which clear out sensitive data in extract_{buf,entropy,
      entropy_user}() in random driver are being optimized away by gcc.
      
      Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
      that can be used in such cases where a variable with sensitive data is
      being cleared out in the end. Other use cases might also be in crypto
      code. [ I have put this into lib/string.c though, as it's always built-in
      and doesn't need any dependencies then. ]
      
      Fixes kernel bugzilla: 82041
      
      Reported-by: zatimend@hotmail.co.uk
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      d4c5efdb
  3. 14 10月, 2014 2 次提交
  4. 14 9月, 2014 1 次提交
    • L
      Make ARCH_HAS_FAST_MULTIPLIER a real config variable · 72d93104
      Linus Torvalds 提交于
      It used to be an ad-hoc hack defined by the x86 version of
      <asm/bitops.h> that enabled a couple of library routines to know whether
      an integer multiply is faster than repeated shifts and additions.
      
      This just makes it use the real Kconfig system instead, and makes x86
      (which was the only architecture that did this) select the option.
      
      NOTE! Even for x86, this really is kind of wrong.  If we cared, we would
      probably not enable this for builds optimized for netburst (P4), where
      shifts-and-adds are generally faster than multiplies.  This patch does
      *not* change that kind of logic, though, it is purely a syntactic change
      with no code changes.
      
      This was triggered by the fact that we have other places that really
      want to know "do I want to expand multiples by constants by hand or
      not", particularly the hash generation code.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72d93104
  5. 05 6月, 2014 1 次提交
  6. 23 5月, 2014 1 次提交
    • G
      lib: add glibc style strchrnul() variant · 11d200e9
      Grant Likely 提交于
      The strchrnul() variant helpfully returns a the end of the string
      instead of a NULL if the requested character is not found. This can
      simplify string parsing code since it doesn't need to expicitly check
      for a NULL return. If a valid string pointer is passed in, then a valid
      null terminated string will always come back out.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      11d200e9
  7. 14 2月, 2014 1 次提交
  8. 24 3月, 2012 1 次提交
  9. 08 3月, 2012 1 次提交
  10. 01 3月, 2012 1 次提交
  11. 01 11月, 2011 2 次提交
  12. 19 5月, 2011 1 次提交
  13. 26 4月, 2011 1 次提交
  14. 07 3月, 2010 2 次提交
  15. 15 1月, 2010 1 次提交
  16. 23 12月, 2009 1 次提交
  17. 16 12月, 2009 3 次提交
  18. 19 11月, 2009 1 次提交
  19. 01 5月, 2008 1 次提交
  20. 26 4月, 2007 1 次提交
  21. 12 2月, 2007 1 次提交
  22. 29 10月, 2006 1 次提交
  23. 23 6月, 2006 1 次提交
  24. 11 4月, 2006 3 次提交
  25. 22 3月, 2006 1 次提交
    • A
      [PATCH] multiple exports of strpbrk · f4a641d6
      Andrew Morton 提交于
      Sam's tree includes a new check, which found that we're exporting strpbrk()
      multiple times.
      
      It seems that the convention is that this is exported from the arch files, so
      reove the lib/string.c export.
      
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f4a641d6
  26. 31 10月, 2005 4 次提交
  27. 06 5月, 2005 2 次提交
  28. 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