Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 02 11月, 2012 1 次提交
  3. 12 9月, 2012 1 次提交
  5. 05 9月, 2012 1 次提交
  7. 23 8月, 2012 10 次提交
  9. 17 8月, 2012 1 次提交
  11. 10 8月, 2012 2 次提交
    • R
      tpm_tis / PM: Fix unused function warning for CONFIG_PM_SLEEP · 07368d32
      由 Rafael J. Wysocki 提交于 
      According to a compiler warning, the tpm_tis_resume() function is not
used for CONFIG_PM_SLEEP unset, so add a #ifdef to prevent it from
being built in that case.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      07368d32
    • A
      omap-rng: fix use of SIMPLE_DEV_PM_OPS · 59596df6
      由 Arnd Bergmann 提交于 
      omap_rng_suspend and omap_rng_resume are unused if CONFIG_PM is enabled
but CONFIG_PM_SLEEP is disabled. I found this while building all defconfig
files on ARM. It's not clear to me if this is the right solution, but
at least it makes the code consistent again.

Without this patch, building omap1_defconfig results in:

drivers/char/hw_random/omap-rng.c:165:12: warning: 'omap_rng_suspend' defined but not used [-Wunused-function]
drivers/char/hw_random/omap-rng.c:171:12: warning: 'omap_rng_resume' defined but not used [-Wunused-function]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NKevin Hilman <khilman@ti.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
      59596df6
  13. 07 8月, 2012 1 次提交
  15. 30 7月, 2012 4 次提交
  17. 28 7月, 2012 1 次提交
  19. 27 7月, 2012 1 次提交
    • T
      [IA64] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts · a1193655
      由 Tony Luck 提交于 
      The following build error occured during a ia64 build with
swap-over-NFS patches applied.

net/core/sock.c:274:36: error: initializer element is not constant
net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
net/core/sock.c:274:36: error: initializer element is not constant

This is identical to a parisc build error. Fengguang Wu, Mel Gorman
and James Bottomley did all the legwork to track the root cause of
the problem. This fix and entire commit log is shamelessly copied
from them with one extra detail to change a dubious runtime use of
ATOMIC_INIT() to atomic_set() in drivers/char/mspec.c

Dave Anglin says:
> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });

The above line contains two compound literals.  It also uses a designated
initializer to initialize the field enabled.  A compound literal is not a
constant expression.

The location of the above statement isn't fully clear, but if a compound
literal occurs outside the body of a function, the initializer list must
consist of constant expressions.

Cc: <stable@vger.kernel.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>
      a1193655
  21. 25 7月, 2012 1 次提交
    • T
      random: Add comment to random_initialize() · cbc96b75
      由 Tony Luck 提交于 
      Many platforms have per-machine instance data (serial numbers,
asset tags, etc.) squirreled away in areas that are accessed
during early system bringup. Mixing this data into the random
pools has a very high value in providing better random data,
so we should allow (and even encourage) architecture code to
call add_device_randomness() from the setup_arch() paths.

However, this limits our options for internal structure of
the random driver since random_initialize() is not called
until long after setup_arch().

Add a big fat comment to rand_initialize() spelling out
this requirement.
Suggested-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      cbc96b75
  23. 24 7月, 2012 1 次提交
  25. 23 7月, 2012 1 次提交
  27. 19 7月, 2012 1 次提交
  29. 18 7月, 2012 1 次提交
  31. 15 7月, 2012 6 次提交
    • T
      random: add tracepoints for easier debugging and verification · 00ce1db1
      由 Theodore Ts'o 提交于 
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      00ce1db1
    • T
      random: add new get_random_bytes_arch() function · c2557a30
      由 Theodore Ts'o 提交于 
      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: N"Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
      c2557a30
    • T
      random: use the arch-specific rng in xfer_secondary_pool · e6d4947b
      由 Theodore Ts'o 提交于 
      If the CPU supports a hardware random number generator, use it in
xfer_secondary_pool(), where it will significantly improve things and
where we can afford it.

Also, remove the use of the arch-specific rng in
add_timer_randomness(), since the call is significantly slower than
get_cycles(), and we're much better off using it in
xfer_secondary_pool() anyway.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
      e6d4947b
    • L
      random: create add_device_randomness() interface · a2080a67
      由 Linus Torvalds 提交于 
      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: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
      a2080a67
    • T
      random: use lockless techniques in the interrupt path · 902c098a
      由 Theodore Ts'o 提交于 
      The real-time Linux folks don't like add_interrupt_randomness() taking
a spinlock since it is called in the low-level interrupt routine.
This also allows us to reduce the overhead in the fast path, for the
random driver, which is the interrupt collection path.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
      902c098a
    • T
      random: make 'add_interrupt_randomness()' do something sane · 775f4b29
      由 Theodore Ts'o 提交于 
      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: NEric Wustrow <ewust@umich.edu>
Reported-by: NEric Wustrow <ewust@umich.edu>
Reported-by: NNadia Heninger <nadiah@cs.ucsd.edu>
Reported-by: NZakir Durumeric <zakir@umich.edu>
Reported-by: J. Alex Halderman <jhalderm@umich.edu>.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
      775f4b29
  33. 11 7月, 2012 6 次提交