linux-stable.git/drivers/char, branch linux-3.16.y

random: always use batched entropy for get_random_u{32,64}

2020-06-11T18:05:58+00:00

commit 69efea712f5b0489e67d07565aad5c94e09a3e52 upstream.

It turns out that RDRAND is pretty slow. Comparing these two
constructions:

  for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret))
    arch_get_random_long(&ret);

and

  long buf[CHACHA_BLOCK_SIZE / sizeof(long)];
  extract_crng((u8 *)buf);

it amortizes out to 352 cycles per long for the top one and 107 cycles
per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H.

And importantly, the top one has the drawback of not benefiting from the
real rng, whereas the bottom one has all the nice benefits of using our
own chacha rng. As get_random_u{32,64} gets used in more places (perhaps
beyond what it was originally intended for when it was introduced as
get_random_{int,long} back in the md5 monstrosity era), it seems like it
might be a good thing to strengthen its posture a tiny bit. Doing this
should only be stronger and not any weaker because that pool is already
initialized with a bunch of rdrand data (when available). This way, we
get the benefits of the hardware rng as well as our own rng.

Another benefit of this is that we no longer hit pitfalls of the recent
stream of AMD bugs in RDRAND. One often used code pattern for various
things is:

  do {
  	val = get_random_u32();
  } while (hash_table_contains_key(val));

That recent AMD bug rendered that pattern useless, whereas we're really
very certain that chacha20 output will give pretty distributed numbers,
no matter what.

So, this simplification seems better both from a security perspective
and from a performance perspective.

Signed-off-by: Jason A. Donenfeld 
Reviewed-by: Greg Kroah-Hartman 
Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: Only get_random_int() exists here]
Signed-off-by: Ben Hutchings

x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping

2020-06-11T18:05:55+00:00

commit b399151cb48db30ad1e0e93dd40d68c6d007b637 upstream.

x86_mask is a confusing name which is hard to associate with the
processor's stepping.

Additionally, correct an indent issue in lib/cpu.c.

Signed-off-by: Jia Zhang 
[ Updated it to more recent kernels. ]
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: bp@alien8.de
Cc: tony.luck@intel.com
Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16:
 - Drop changes in arch/x86/lib/cpu.c
 - Adjust filenames, context]
Signed-off-by: Ben Hutchings

hwrng: omap3-rom - Call clk_disable_unprepare() on exit only if not idled

2020-02-11T20:03:14+00:00

commit eaecce12f5f0d2c35d278e41e1bc4522393861ab upstream.

When unloading omap3-rom-rng, we'll get the following:

WARNING: CPU: 0 PID: 100 at drivers/clk/clk.c:948 clk_core_disable

This is because the clock may be already disabled by omap3_rom_rng_idle().
Let's fix the issue by checking for rng_idle on exit.

Cc: Aaro Koskinen 
Cc: Adam Ford 
Cc: Pali Rohár 
Cc: Sebastian Reichel 
Cc: Tero Kristo 
Fixes: 1c6b7c2108bd ("hwrng: OMAP3 ROM Random Number Generator support")
Signed-off-by: Tony Lindgren 
Signed-off-by: Herbert Xu 
Signed-off-by: Ben Hutchings

virtio_console: allocate inbufs in add_port() only if it is needed

2019-12-19T15:59:02+00:00

commit d791cfcbf98191122af70b053a21075cb450d119 upstream.

When we hot unplug a virtserialport and then try to hot plug again,
it fails:

(qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait
(qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\
                  chardev=serial0,id=serial0,name=serial0
(qemu) device_del serial0
(qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\
                  chardev=serial0,id=serial0,name=serial0
kernel error:
  virtio-ports vport2p2: Error allocating inbufs
qemu error:
  virtio-serial-bus: Guest failure in adding port 2 for device \
                     virtio-serial0.0

This happens because buffers for the in_vq are allocated when the port is
added but are not released when the port is unplugged.

They are only released when virtconsole is removed (see a7a69ec0d8e4)

To avoid the problem and to be symmetric, we could allocate all the buffers
in init_vqs() as they are released in remove_vqs(), but it sounds like
a waste of memory.

Rather than that, this patch changes add_port() logic to ignore ENOSPC
error in fill_queue(), which means queue has already been filled.

Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset")
Cc: mst@redhat.com
Signed-off-by: Laurent Vivier 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Ben Hutchings

hwrng: core - don't wait on add_early_randomness()

2019-12-10T18:01:22+00:00

commit 78887832e76541f77169a24ac238fccb51059b63 upstream.

add_early_randomness() is called by hwrng_register() when the
hardware is added. If this hardware and its module are present
at boot, and if there is no data available the boot hangs until
data are available and can't be interrupted.

For instance, in the case of virtio-rng, in some cases the host can be
not able to provide enough entropy for all the guests.

We can have two easy ways to reproduce the problem but they rely on
misconfiguration of the hypervisor or the egd daemon:

- if virtio-rng device is configured to connect to the egd daemon of the
host but when the virtio-rng driver asks for data the daemon is not
connected,

- if virtio-rng device is configured to connect to the egd daemon of the
host but the egd daemon doesn't provide data.

The guest kernel will hang at boot until the virtio-rng driver provides
enough data.

To avoid that, call rng_get_data() in non-blocking mode (wait=0)
from add_early_randomness().

Signed-off-by: Laurent Vivier 
Fixes: d9e797261933 ("hwrng: add randomness to system from rng...")
Reviewed-by: Theodore Ts'o 
Signed-off-by: Herbert Xu 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

/dev/mem: Bail out upon SIGKILL.

2019-12-10T18:01:16+00:00

commit 8619e5bdeee8b2c685d686281f2d2a6017c4bc15 upstream.

syzbot found that a thread can stall for minutes inside read_mem() or
write_mem() after that thread was killed by SIGKILL [1]. Reading from
iomem areas of /dev/mem can be slow, depending on the hardware.
While reading 2GB at one read() is legal, delaying termination of killed
thread for minutes is bad. Thus, allow reading/writing /dev/mem and
/dev/kmem to be preemptible and killable.

  [ 1335.912419][T20577] read_mem: sz=4096 count=2134565632
  [ 1335.943194][T20577] read_mem: sz=4096 count=2134561536
  [ 1335.978280][T20577] read_mem: sz=4096 count=2134557440
  [ 1336.011147][T20577] read_mem: sz=4096 count=2134553344
  [ 1336.041897][T20577] read_mem: sz=4096 count=2134549248

Theoretically, reading/writing /dev/mem and /dev/kmem can become
"interruptible". But this patch chose "killable". Future patch will make
them "interruptible" so that we can revert to "killable" if some program
regressed.

[1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Link: https://lore.kernel.org/r/1566825205-10703-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

hpet: Fix division by zero in hpet_time_div()

2019-11-22T15:57:06+00:00

commit 0c7d37f4d9b8446956e97b7c5e61173cdb7c8522 upstream.

The base value in do_div() called by hpet_time_div() is truncated from
unsigned long to uint32_t, resulting in a divide-by-zero exception.

UBSAN: Undefined behaviour in ../drivers/char/hpet.c:572:2
division by zero
CPU: 1 PID: 23682 Comm: syz-executor.3 Not tainted 4.4.184.x86_64+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
 0000000000000000 b573382df1853d00 ffff8800a3287b98 ffffffff81ad7561
 ffff8800a3287c00 ffffffff838b35b0 ffffffff838b3860 ffff8800a3287c20
 0000000000000000 ffff8800a3287bb0 ffffffff81b8f25e ffffffff838b35a0
Call Trace:
 [] __dump_stack lib/dump_stack.c:15 [inline]
 [] dump_stack+0xc1/0x120 lib/dump_stack.c:51
 [] ubsan_epilogue+0x12/0x8d lib/ubsan.c:166
 [] __ubsan_handle_divrem_overflow+0x282/0x2c8 lib/ubsan.c:262
 [] hpet_time_div drivers/char/hpet.c:572 [inline]
 [] hpet_ioctl_common drivers/char/hpet.c:663 [inline]
 [] hpet_ioctl_common.cold+0xa8/0xad drivers/char/hpet.c:577
 [] hpet_ioctl+0xc6/0x180 drivers/char/hpet.c:676
 [] vfs_ioctl fs/ioctl.c:43 [inline]
 [] file_ioctl fs/ioctl.c:470 [inline]
 [] do_vfs_ioctl+0x6e0/0xf70 fs/ioctl.c:605
 [] SYSC_ioctl fs/ioctl.c:622 [inline]
 [] SyS_ioctl+0x94/0xc0 fs/ioctl.c:613
 [] tracesys_phase2+0x90/0x95

The main C reproducer autogenerated by syzkaller,

  syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
  memcpy((void*)0x20000100, "/dev/hpet\000", 10);
  syscall(__NR_openat, 0xffffffffffffff9c, 0x20000100, 0, 0);
  syscall(__NR_ioctl, r[0], 0x40086806, 0x40000000000000);

Fix it by using div64_ul().

Signed-off-by: Kefeng Wang 
Signed-off-by: Zhang HongJun 
Reviewed-by: Arnd Bergmann 
Link: https://lore.kernel.org/r/20190711132757.130092-1-wangkefeng.wang@huawei.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

tpm: Fix off-by-one when reading binary_bios_measurements

2019-07-09T21:04:00+00:00

commit 64494d39ff630a63b5308042b20132b491e3706b upstream.

It is unable to read the entry when it is the only one in
binary_bios_measurements:

00000000  00 00 00 00 08 00 00 00  c4 2f ed ad 26 82 00 cb
00000010  1d 15 f9 78 41 c3 44 e7  9d ae 33 20 00 00 00 00
00000020

This is obviously a firmware problem on my linux machine:

	Manufacturer: Inspur
	Product Name: SA5212M4
	Version: 01

However, binary_bios_measurements should return it any way,
rather than nothing, after all its content is completely
valid.

Fixes: 55a82ab3181b ("tpm: add bios measurement log")
Signed-off-by: Jia Zhang 
Reviewd-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
[bwh: Backported to 3.16:
 - Fix an additional comparison in tpm1_bios_measurements_start()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete

2019-07-09T21:04:00+00:00

commit 442601e87a4769a8daba4976ec3afa5222ca211d upstream.

Return -E2BIG when the transfer is incomplete. The upper layer does
not retry, so not doing that is incorrect behaviour.

Fixes: a2871c62e186 ("tpm: Add support for Atmel I2C TPMs")
Signed-off-by: Jarkko Sakkinen 
Reviewed-by: Stefan Berger 
Reviewed-by: Jerry Snitselaar 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

applicom: Fix potential Spectre v1 vulnerabilities

2019-07-09T21:03:50+00:00

commit d7ac3c6ef5d8ce14b6381d52eb7adafdd6c8bb3c upstream.

IndexCard is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/char/applicom.c:418 ac_write() warn: potential spectre issue 'apbs' [r]
drivers/char/applicom.c:728 ac_ioctl() warn: potential spectre issue 'apbs' [r] (local cap)

Fix this by sanitizing IndexCard before using it to index apbs.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings