Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 8月, 2012 2 次提交
    • J
      TTY: ttyprintk, don't touch behind tty->write_buf · ee8b593a
      由 Jiri Slaby 提交于 
      If a user provides a buffer larger than a tty->write_buf chunk and
passes '\r' at the end of the buffer, we touch an out-of-bound memory.

Add a check there to prevent this.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: stable@vger.kernel.org (everything maintained past v2.6.37)
Cc: Samo Pogacnik <samo_pogacnik@t-2.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ee8b593a
    • J
      TTY: ttyprintk, unregister tty driver on failure · f06fb543
      由 Jiri Slaby 提交于 
      When the tty_printk driver fails to create a node in sysfs, the system
crashes. It is because the driver registers a tty driver and frees it
without deregistering it first. The fix is easy: add a call to
tty_unregister_driver to the fail path.

This is very unlikely to happen in usual environment => no need for
stable.

The crash occurs at some place where we iterate over tty drivers
first. It may look like this:
BUG: unable to handle kernel paging request at ffffffffffffff84
IP: [<ffffffff81278d56>] tty_open+0xd6/0x650
PGD 1a0d067 PUD 1a0e067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU 0
Pid: 1183, comm: boot.localnet Tainted: G        W    3.5.0-rc7-next-20120716+ #369 Bochs Bochs
RIP: 0010:[<ffffffff81278d56>]  [<ffffffff81278d56>] tty_open+0xd6/0x650
RSP: 0018:ffff8800162b3b98  EFLAGS: 00010207
RAX: 0000000000000000 RBX: ffff880016ba6200 RCX: 0000000000002208
RDX: 0000000000000000 RSI: 00000000000000d0 RDI: ffffffff81a35080
RBP: ffff8800162b3c08 R08: ffffffff81276f42 R09: 0000000000400040
R10: ffff8800161dc005 R11: ffff8800188ee048 R12: 0000000000000000
R13: ffffffffffffff58 R14: 0000000000400040 R15: 0000000000008000
FS:  00007f3684abd700(0000) GS:ffff880018e00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffff84 CR3: 000000001503e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process boot.localnet (pid: 1183, threadinfo ffff8800162b2000, task ffff8800188c5880)
Stack:
 ffff8800162b3c08 ffffffff81363d63 ffffffff81a62940 ffff8800189b4e88
 ffff8800188c5880 ffffffff81123180 0000000000000000 ffffffff18b20600
 0000000000000000 ffff8800189b4e88 ffff880016ba6200 ffff880018b20600
Call Trace:
 [<ffffffff81363d63>] ? kobj_lookup+0x103/0x160
 [<ffffffff81123180>] ? mount_fs+0x110/0x110
 [<ffffffff81123a9c>] chrdev_open+0x9c/0x1a0
 [<ffffffff81123a00>] ? cdev_put+0x30/0x30
 [<ffffffff8111de76>] do_dentry_open.isra.19+0x1e6/0x270
 [<ffffffff8111df65>] finish_open+0x65/0xa0
 [<ffffffff8112dc9e>] do_last.isra.52+0x26e/0xd80
 [<ffffffff8112b163>] ? inode_permission+0x13/0x50
 [<ffffffff8112b203>] ? link_path_walk+0x63/0x940
 [<ffffffff8112e85b>] path_openat+0xab/0x3d0
 [<ffffffff8112ef5d>] do_filp_open+0x3d/0xa0
 [<ffffffff8113ba72>] ? alloc_fd+0xd2/0x120
 [<ffffffff8111eee3>] do_sys_open+0xf3/0x1d0
 [<ffffffff8111efdc>] sys_open+0x1c/0x20
 [<ffffffff815b5fe2>] system_call_fastpath+0x16/0x1b
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Samo Pogacnik <samo_pogacnik@t-2.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f06fb543
  3. 30 7月, 2012 4 次提交
  5. 28 7月, 2012 1 次提交
  7. 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
  9. 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
  11. 24 7月, 2012 1 次提交
  13. 23 7月, 2012 1 次提交
  15. 20 7月, 2012 1 次提交
  17. 19 7月, 2012 1 次提交
  19. 18 7月, 2012 2 次提交
  21. 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
  23. 11 7月, 2012 8 次提交
  25. 07 7月, 2012 1 次提交
  27. 01 7月, 2012 1 次提交
  29. 27 6月, 2012 1 次提交
  31. 26 6月, 2012 1 次提交
  33. 21 6月, 2012 2 次提交
  35. 13 6月, 2012 5 次提交