talos-obmc-linux/drivers/char, branch dev-4.10

hw_random: timeriomem_rng: Allow setting RNG quality from platform data

2017-07-07T06:40:45+00:00

When a hw_random device's quality is non-zero, it will automatically be used to fill the kernel's entropy pool. Since timeriomem_rng is used by many different devices, the quality needs to be provided by platform data or device tree. Signed-off-by: Rick Altherr Signed-off-by: Herbert Xu (cherry picked from commit 284e76387c38260e834c99b010a68d75fc46b394) Signed-off-by: Joel Stanley

Merge tag 'v4.10.17' into dev-4.10

2017-06-05T02:24:15+00:00

This is the 4.10.17 stable release

ipmi: Fix kernel panic at ipmi_ssif_thread()

2017-05-20T12:31:03+00:00

commit 6de65fcfdb51835789b245203d1bfc8d14cb1e06 upstream. msg_written_handler() may set ssif_info->multi_data to NULL when using ipmitool to write fru. Before setting ssif_info->multi_data to NULL, add new local pointer "data_to_send" and store correct i2c data pointer to it to fix NULL pointer kernel panic and incorrect ssif_info->multi_pos. Signed-off-by: Joeseph Chang Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman

tmp: use pdev for parent device in tpm_chip_alloc

2017-05-14T12:08:19+00:00

commit 2998b02b2fb58f36ccbc318b00513174e9947d8e upstream. The tpm stack uses pdev name convention for the parent device. Fix that also in tpm_chip_alloc(). Fixes: 3897cd9c8d1d ("tpm: Split out the devm stuff from tpmm_chip_alloc")' Signed-off-by: Tomas Winkler Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

tpm: fix RC value check in tpm2_seal_trusted

2017-05-14T12:08:19+00:00

commit 7d761119a914ec0ac05ec2a5378d1f86e680967d upstream. The error code handling is broken as any error code that has the same bits set as TPM_RC_HASH passes. Implemented tpm2_rc_value() helper to parse the error value from FMT0 and FMT1 error codes so that these types of mistakes are prevented in the future. Fixes: 5ca4c20cfd37 ("keys, trusted: select hash algorithm for TPM2 chips") Signed-off-by: Jarkko Sakkinen Reviewed-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman

virtio-console: avoid DMA from stack

2017-04-21T07:32:42+00:00

commit c4baad50297d84bde1a7ad45e50c73adae4a2192 upstream. put_chars() stuffs the buffer it gets into an sg, but that buffer may be on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it manifested as printks getting turned into NUL bytes). Signed-off-by: Omar Sandoval Signed-off-by: Michael S. Tsirkin Reviewed-by: Amit Shah Cc: Ben Hutchings Cc: Brad Spengler Signed-off-by: Greg Kroah-Hartman

mm: Tighten x86 /dev/mem with zeroing reads

2017-04-21T07:32:42+00:00

commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream. Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is disallowed. However, on x86, the first 1MB was always allowed for BIOS and similar things, regardless of it actually being System RAM. It was possible for heap to end up getting allocated in low 1MB RAM, and then read by things like x86info or dd, which would trip hardened usercopy: usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes) This changes the x86 exception for the low 1MB by reading back zeros for System RAM areas instead of blindly allowing them. More work is needed to extend this to mmap, but currently mmap doesn't go through usercopy, so hardened usercopy won't Oops the kernel. Reported-by: Tommi Rantala Tested-by: Tommi Rantala Signed-off-by: Kees Cook Cc: Brad Spengler Signed-off-by: Greg Kroah-Hartman

char: lack of bool string made CONFIG_DEVPORT always on

2017-04-21T07:32:41+00:00

commit f2cfa58b136e4b06a9b9db7af5ef62fbb5992f62 upstream. Without a bool string present, using "# CONFIG_DEVPORT is not set" in defconfig files would not actually unset devport. This esnured that /dev/port was always on, but there are reasons a user may wish to disable it (smaller kernel, attack surface reduction) if it's not being used. Adding a message here in order to make this user visible. Signed-off-by: Max Bires Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

hwrng: timeriomem: Print error when failing to get resource

2017-04-18T06:14:29+00:00

Required for debugging a bad device tree. Signed-off-by: Joel Stanley

random: use chacha20 for get_random_int/long

2017-04-12T10:42:09+00:00

commit f5b98461cb8167ba362ad9f74c41d126b7becea7 upstream. Now that our crng uses chacha20, we can rely on its speedy characteristics for replacing MD5, while simultaneously achieving a higher security guarantee. Before the idea was to use these functions if you wanted random integers that aren't stupidly insecure but aren't necessarily secure either, a vague gray zone, that hopefully was "good enough" for its users. With chacha20, we can strengthen this claim, since either we're using an rdrand-like instruction, or we're using the same crng as /dev/urandom. And it's faster than what was before. We could have chosen to replace this with a SipHash-derived function, which might be slightly faster, but at the cost of having yet another RNG construction in the kernel. By moving to chacha20, we have a single RNG to analyze and verify, and we also already get good performance improvements on all platforms. Implementation-wise, rather than use a generic buffer for both get_random_int/long and memcpy based on the size needs, we use a specific buffer for 32-bit reads and for 64-bit reads. This way, we're guaranteed to always have aligned accesses on all platforms. While slightly more verbose in C, the assembly this generates is a lot simpler than otherwise. Finally, on 32-bit platforms where longs and ints are the same size, we simply alias get_random_int to get_random_long. Signed-off-by: Jason A. Donenfeld Suggested-by: Theodore Ts'o Cc: Theodore Ts'o Cc: Hannes Frederic Sowa Cc: Andy Lutomirski Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman