1. 19 Jul, 2012 1 commit
  2. 15 Jul, 2012 3 commits
    • Theodore Ts'o's avatar
      random: add new get_random_bytes_arch() function · c2557a30
      Theodore Ts'o authored
      Create a new function, get_random_bytes_arch() which will use the
      architecture-specific hardware random number generator if it is
      present.  Change get_random_bytes() to not use the HW RNG, even if it
      is avaiable.
      
      The reason for this is that the hw random number generator is fast (if
      it is present), but it requires that we trust the hardware
      manufacturer to have not put in a back door.  (For example, an
      increasing counter encrypted by an AES key known to the NSA.)
      
      It's unlikely that Intel (for example) was paid off by the US
      Government to do this, but it's impossible for them to prove otherwise
      --- especially since Bull Mountain is documented to use AES as a
      whitener.  Hence, the output of an evil, trojan-horse version of
      RDRAND is statistically indistinguishable from an RDRAND implemented
      to the specifications claimed by Intel.  Short of using a tunnelling
      electronic microscope to reverse engineer an Ivy Bridge chip and
      disassembling and analyzing the CPU microcode, there's no way for us
      to tell for sure.
      
      Since users of get_random_bytes() in the Linux kernel need to be able
      to support hardware systems where the HW RNG is not present, most
      time-sensitive users of this interface have already created their own
      cryptographic RNG interface which uses get_random_bytes() as a seed.
      So it's much better to use the HW RNG to improve the existing random
      number generator, by mixing in any entropy returned by the HW RNG into
      /dev/random's entropy pool, but to always _use_ /dev/random's entropy
      pool.
      
      This way we get almost of the benefits of the HW RNG without any
      potential liabilities.  The only benefits we forgo is the
      speed/performance enhancements --- and generic kernel code can't
      depend on depend on get_random_bytes() having the speed of a HW RNG
      anyway.
      
      For those places that really want access to the arch-specific HW RNG,
      if it is available, we provide get_random_bytes_arch().
      Signed-off-by: Theodore Ts'o's avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      c2557a30
    • Linus Torvalds's avatar
      random: create add_device_randomness() interface · a2080a67
      Linus Torvalds authored
      Add a new interface, add_device_randomness() for adding data to the
      random pool that is likely to differ between two devices (or possibly
      even per boot).  This would be things like MAC addresses or serial
      numbers, or the read-out of the RTC. This does *not* add any actual
      entropy to the pool, but it initializes the pool to different values
      for devices that might otherwise be identical and have very little
      entropy available to them (particularly common in the embedded world).
      
      [ Modified by tytso to mix in a timestamp, since there may be some
        variability caused by the time needed to detect/configure the hardware
        in question. ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: Theodore Ts'o's avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      a2080a67
    • Theodore Ts'o's avatar
      random: make 'add_interrupt_randomness()' do something sane · 775f4b29
      Theodore Ts'o authored
      We've been moving away from add_interrupt_randomness() for various
      reasons: it's too expensive to do on every interrupt, and flooding the
      CPU with interrupts could theoretically cause bogus floods of entropy
      from a somewhat externally controllable source.
      
      This solves both problems by limiting the actual randomness addition
      to just once a second or after 64 interrupts, whicever comes first.
      During that time, the interrupt cycle data is buffered up in a per-cpu
      pool.  Also, we make sure the the nonblocking pool used by urandom is
      initialized before we start feeding the normal input pool.  This
      assures that /dev/urandom is returning unpredictable data as soon as
      possible.
      
      (Based on an original patch by Linus, but significantly modified by
      tytso.)
      Tested-by: default avatarEric Wustrow <ewust@umich.edu>
      Reported-by: default avatarEric Wustrow <ewust@umich.edu>
      Reported-by: default avatarNadia Heninger <nadiah@cs.ucsd.edu>
      Reported-by: default avatarZakir Durumeric <zakir@umich.edu>
      Reported-by: J. Alex Halderman <jhalderm@umich.edu>.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: Theodore Ts'o's avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      775f4b29
  3. 07 Aug, 2011 1 commit
    • David S. Miller's avatar
      net: Compute protocol sequence numbers and fragment IDs using MD5. · 6e5714ea
      David S. Miller authored
      Computers have become a lot faster since we compromised on the
      partial MD4 hash which we use currently for performance reasons.
      
      MD5 is a much safer choice, and is inline with both RFC1948 and
      other ISS generators (OpenBSD, Solaris, etc.)
      
      Furthermore, only having 24-bits of the sequence number be truly
      unpredictable is a very serious limitation.  So the periodic
      regeneration and 8-bit counter have been removed.  We compute and
      use a full 32-bit sequence number.
      
      For ipv6, DCCP was found to use a 32-bit truncated initial sequence
      number (it needs 43-bits) and that is fixed here as well.
      Reported-by: default avatarDan Kaminsky <dan@doxpara.com>
      Tested-by: Willy Tarreau's avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e5714ea
  4. 31 Jul, 2011 1 commit
    • H. Peter Anvin's avatar
      random: Add support for architectural random hooks · 63d77173
      H. Peter Anvin authored
      Add support for architecture-specific hooks into the kernel-directed
      random number generator interfaces.  This patchset does not use the
      architecture random number generator interfaces for the
      userspace-directed interfaces (/dev/random and /dev/urandom), thus
      eliminating the need to distinguish between them based on a pool
      pointer.
      
      Changes in version 3:
      - Moved the hooks from extract_entropy() to get_random_bytes().
      - Changes the hooks to inlines.
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      63d77173
  5. 22 Jul, 2011 1 commit
  6. 27 May, 2010 1 commit
    • Joe Eykholt's avatar
      lib/random32: export pseudo-random number generator for modules · 5960164f
      Joe Eykholt authored
      This patch moves the definition of struct rnd_state and the inline
      __seed() function to linux/random.h.  It renames the static __random32()
      function to prandom32() and exports it for use in modules.
      
      prandom32() is useful as a privately-seeded pseudo random number generator
      that can give the same result every time it is initialized.
      
      For FCoE FC-BB-6 VN2VN mode self-selected unique FC address generation, we
      need an pseudo-random number generator seeded with the 64-bit world-wide
      port name.  A truly random generator or one seeded with randomness won't
      do because the same sequence of numbers should be generated each time we
      boot or the link comes up.
      
      A prandom32_seed() inline function is added to the header file.  It is
      inlined not for speed, but so the function won't be expanded in the base
      kernel, but only in the module that uses it.
      Signed-off-by: default avatarJoe Eykholt <jeykholt@cisco.com>
      Acked-by: default avatarMatt Mackall <mpm@selenic.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5960164f
  7. 30 Jan, 2009 1 commit
  8. 03 Jan, 2009 1 commit
  9. 12 Dec, 2008 1 commit
    • Ingo Molnar's avatar
      sparse irqs: handle !GENIRQ platforms · 0ebb26e7
      Ingo Molnar authored
      Impact: build fix
      
      fix:
      
       In file included from /home/mingo/tip/arch/m68k/amiga/amiints.c:39:
       /home/mingo/tip/include/linux/interrupt.h:21: error: expected identifier or '('
       /home/mingo/tip/arch/m68k/amiga/amiints.c: In function 'amiga_init_IRQ':
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      0ebb26e7
  10. 08 Dec, 2008 1 commit
    • Yinghai Lu's avatar
      sparse irq_desc[] array: core kernel and x86 changes · 0b8f1efa
      Yinghai Lu authored
      Impact: new feature
      
      Problem on distro kernels: irq_desc[NR_IRQS] takes megabytes of RAM with
      NR_CPUS set to large values. The goal is to be able to scale up to much
      larger NR_IRQS value without impacting the (important) common case.
      
      To solve this, we generalize irq_desc[NR_IRQS] to an (optional) array of
      irq_desc pointers.
      
      When CONFIG_SPARSE_IRQ=y is used, we use kzalloc_node to get irq_desc,
      this also makes the IRQ descriptors NUMA-local (to the site that calls
      request_irq()).
      
      This gets rid of the irq_cfg[] static array on x86 as well: irq_cfg now
      uses desc->chip_data for x86 to store irq_cfg.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      0b8f1efa
  11. 12 Feb, 2007 1 commit
  12. 03 Dec, 2006 1 commit
  13. 17 Oct, 2006 1 commit
  14. 03 Jan, 2006 2 commits
  15. 29 Aug, 2005 1 commit
  16. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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