29 Oct, 2018
8 commits
-
Bank0/Bank1 are not in ECC mode, so no need to check.
Each bank contains 8 words, so we check (phy_index > 15).Signed-off-by: Peng Fan
-
Add ULP1 OTP support.
No timing required for ULP1 OTP.
The CTRL_ADDR is 8 bits width.
When finished access to OTP, gate the power to OTP memory to save power.Fix store, when invalid args, not return 0, but return the error values.
To ULP, fuse only support being programmed once, so add a check before
program.Test log:
root@imx6qdlsolo:/sys/fsl_otp# cat HW_OCOTP_GP84
0x0
root@imx6qdlsolo:/sys/fsl_otp# echo 1 > HW_OCOTP_GP84
root@imx6qdlsolo:/sys/fsl_otp# cat HW_OCOTP_GP84
0x1
root@imx6qdlsolo:/sys/fsl_otp# echo 1 > HW_OCOTP_GP84
-sh: echo: write error: Operation not permitted
root@imx6qdlsolo:/sys/fsl_otp# echo fg > HW_OCOTP_GP84
-sh: echo: write error: Invalid argumentSigned-off-by: Peng Fan
-
Support i.MX6SLL OTP.
There are 4 works in bank7/bank8.
When read, use address offset.
When prog, use bank/index, note that bank7/bank8 we treat
them a single bank when prog.Tested GP41 and GP31 read/write on eng sample chip.
Signed-off-by: Peng Fan
(cherry picked from commit f8698b66fcbec7409b738a4c5b05ba87f0342cf8) -
Add ocotp support for i.MX6ULL.
Signed-off-by: Peng Fan
-
ENGR00292341 imx6sl hwrng
Add hwrng support for i.MX6SL.
1. Add RNG driver. This driver originated as fsl-rngc.c. It
has been modified to support device tree. The name has been
changed since it supports both b and c variants of RNG.
2. Added clock and compatible info to the device tree data.
3. Added the entry in the options in the Kconfig for hwrng.(cherry picked from commit 1f3f2c0647b7319c4e23293a61512e4191593513)
[: Edited to apply to 3.14]Signed-off-by: Dan Douglass
Signed-off-by: Victoria Milhoan -
Fix the out of bounds write, and the dereference before
null check.Signed-off-by: Richard Zhu
(cherry picked from commit 775ff0727166535e9b1ba1f70167e6a33fee5f13) -
This is porting of fsl_otp driver from imx_3.14.y to imx_4.1.y.
This patch mainly from the following:
commit:292eff6d2c9064ecf15ed457140c1d743c2ead67
"ENGR00269945: char: add fsl_otp deivce driver"
This is a porting of fsl_otp driver from 3.0.35 kernel to 3.10. It
cleans up the driver a little bit and adds device tree probe support.shawn.guo: cherry-pick commit 850237dccde7 from imx_3.10.y.
commit:057a50039fac872fd19fe6c129a94face4231ae8
"MLK-10979-4 imx: ocotp add i.MX7D support and fix hole"
1. Add i.MX7D support
2. Fix hole addressing.
There is a hole in shadow registers address map of size 0x100
between bank 5 and bank 6 on iMX6QP, iMX6DQ, iMX6SDL, iMX6SX and
iMX6UL. Bank 5 ends at 0x6F0 and Bank 6 starts at 0x800. When reading
the fuses, should account for this hole in address space.Similar hole exists between bank 14 and bank 15 of size 0x80 on
iMX6QP, iMX6DQ, iMX6SDL and iMX6SX.
Note: iMX6SL has only 0-7 banks and there is no hole.
Note: iMX6UL doesn't have this one.When reading, the hole need to be considered to calculated the physical
address offset.
When writing, since only word index for i.MX6 and bank
index for i.MX7, there is no need to take the hole into consideration,
still use the bank/word index from fuse map.
3. Add i.MX6SL i.MX6UL fuse map table.
4. Tested read/write on mx6ul-14x14-ddr3-arm2 and mx7d-12x12-lpddr3-arm2 board.
Tested read on mx6sxsabresd board.Signed-off-by: Shawn Guo
Signed-off-by: Peng Fan -
- add linux sema4 driver.
- use volatile types in sema4 structure.
- align the port definiton a9 is 1, m4 is 2.Signed-off-by: Anson Huang
Signed-off-by: Richard Zhu
26 Sep, 2018
1 commit
-
commit 0745dde62835be7e2afe62fcdb482fcad79cb743 upstream.
The SSIF driver was removing any client that came in through the
platform interface, but it should only remove clients that it
added. On a failure in the probe function, this could result
in the following oops when the driver is removed and the
client gets unregistered twice:CPU: 107 PID: 30266 Comm: rmmod Not tainted 4.18.0+ #80
Hardware name: Cavium Inc. Saber/Saber, BIOS Cavium reference firmware version 7.0 08/04/2018
pstate: 60400009 (nZCv daif +PAN -UAO)
pc : kernfs_find_ns+0x28/0x120
lr : kernfs_find_and_get_ns+0x40/0x60
sp : ffff00002310fb50
x29: ffff00002310fb50 x28: ffff800a8240f800
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000056000000 x24: ffff000009073000
x23: ffff000008998b38 x22: 0000000000000000
x21: ffff800ed86de820 x20: 0000000000000000
x19: ffff00000913a1d8 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 5300737265766972
x13: 643d4d4554535953 x12: 0000000000000030
x11: 0000000000000030 x10: 0101010101010101
x9 : ffff800ea06cc3f9 x8 : 0000000000000000
x7 : 0000000000000141 x6 : ffff000009073000
x5 : ffff800adb706b00 x4 : 0000000000000000
x3 : 00000000ffffffff x2 : 0000000000000000
x1 : ffff000008998b38 x0 : ffff000008356760
Process rmmod (pid: 30266, stack limit = 0x00000000e218418d)
Call trace:
kernfs_find_ns+0x28/0x120
kernfs_find_and_get_ns+0x40/0x60
sysfs_unmerge_group+0x2c/0x6c
dpm_sysfs_remove+0x34/0x70
device_del+0x58/0x30c
device_unregister+0x30/0x7c
i2c_unregister_device+0x84/0x90 [i2c_core]
ssif_platform_remove+0x38/0x98 [ipmi_ssif]
platform_drv_remove+0x2c/0x6c
device_release_driver_internal+0x168/0x1f8
driver_detach+0x50/0xbc
bus_remove_driver+0x74/0xe8
driver_unregister+0x34/0x5c
platform_driver_unregister+0x20/0x2c
cleanup_ipmi_ssif+0x50/0xd82c [ipmi_ssif]
__arm64_sys_delete_module+0x1b4/0x220
el0_svc_handler+0x104/0x160
el0_svc+0x8/0xc
Code: aa1e03e0 aa0203f6 aa0103f7 d503201f (7940e280)
---[ end trace 09f0e34cce8e2d8c ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x23800c38So track the clients that the SSIF driver adds and only remove
those.Reported-by: George Cherian
Signed-off-by: Corey Minyard
Tested-by: George Cherian
Cc: # 4.14.x
Signed-off-by: Greg Kroah-Hartman
20 Sep, 2018
3 commits
-
[ Upstream commit bb853aac2c478ce78116128263801189408ad2a8 ]
Locking the root adapter for __i2c_transfer will deadlock if the
device sits behind a mux-locked I2C mux. Switch to the finer-grained
i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not
sit behind a mux-locked mux, the two locking variants are equivalent.Signed-off-by: Peter Rosin
Reviewed-by: Jarkko Sakkinen
Tested-by: Alexander Steffen
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 1a339b658d9dbe1471f67b78237cf8fa08bbbeb5 ]
An SPI TPM device managed directly on an embedded board using
the SPI bus and some GPIO or similar line as IRQ handler will
pass the IRQn from the TPM device associated with the SPI
device. This is already handled by the SPI core, so make sure
to pass this down to the core as well.(The TPM core habit of using -1 to signal no IRQ is dubious
(as IRQ 0 is NO_IRQ) but I do not want to mess with that
semantic in this patch.)Cc: Mark Brown
Signed-off-by: Linus Walleij
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
commit 627448e85c766587f6fdde1ea3886d6615081c77 upstream.
Fix tpm ptt initialization error:
tpm tpm0: A TPM error (378) occurred get tpm pcr allocation.We cannot use go_idle cmd_ready commands via runtime_pm handles
as with the introduction of localities this is no longer an optional
feature, while runtime pm can be not enabled.
Though cmd_ready/go_idle provides a power saving, it's also a part of
TPM2 protocol and should be called explicitly.
This patch exposes cmd_read/go_idle via tpm class ops and removes
runtime pm support as it is not used by any driver.When calling from nested context always use both flags:
TPM_TRANSMIT_UNLOCKED and TPM_TRANSMIT_RAW. Both are needed to resolve
tpm spaces and locality request recursive calls to tpm_transmit().
TPM_TRANSMIT_RAW should never be used standalone as it will fail
on double locking. While TPM_TRANSMIT_UNLOCKED standalone should be
called from non-recursive locked contexts.New wrappers are added tpm_cmd_ready() and tpm_go_idle() to
streamline tpm_try_transmit code.tpm_crb no longer needs own power saving functions and can drop using
tpm_pm_suspend/resume.This patch cannot be really separated from the locality fix.
Fixes: 888d867df441 (tpm: cmd_ready command can be issued only after granting locality)Cc: stable@vger.kernel.org
Fixes: 888d867df441 (tpm: cmd_ready command can be issued only after granting locality)
Signed-off-by: Tomas Winkler
Tested-by: Jarkko Sakkinen
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman
05 Sep, 2018
1 commit
-
commit 36a11029b07ee30bdc4553274d0efea645ed9d91 upstream.
The userpace expects to read the number of bytes stated in the header.
Returning the size of the buffer instead would be unexpected.Cc: stable@vger.kernel.org
Fixes: 095531f891e6 ("tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented")
Signed-off-by: Ricardo Schwarzmeier
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman
03 Aug, 2018
1 commit
-
commit 81e69df38e2911b642ec121dec319fad2a4782f3 upstream.
Fedora has integrated the jitter entropy daemon to work around slow
boot problems, especially on VM's that don't support virtio-rng:https://bugzilla.redhat.com/show_bug.cgi?id=1572944
It's understandable why they did this, but the Jitter entropy daemon
works fundamentally on the principle: "the CPU microarchitecture is
**so** complicated and we can't figure it out, so it *must* be
random". Yes, it uses statistical tests to "prove" it is secure, but
AES_ENCRYPT(NSA_KEY, COUNTER++) will also pass statistical tests with
flying colors.So if RDRAND is available, mix it into entropy submitted from
userspace. It can't hurt, and if you believe the NSA has backdoored
RDRAND, then they probably have enough details about the Intel
microarchitecture that they can reverse engineer how the Jitter
entropy daemon affects the microarchitecture, and attack its output
stream. And if RDRAND is in fact an honest DRNG, it will immeasurably
improve on what the Jitter entropy daemon might produce.This also provides some protection against someone who is able to read
or set the entropy seed file.Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
Cc: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman
03 Jul, 2018
3 commits
-
commit 3ab2011ea368ec3433ad49e1b9e1c7b70d2e65df upstream.
There is a race condition in tpm_common_write function allowing
two threads on the same /dev/tpm, or two different applications
on the same /dev/tpmrm to overwrite each other commands/responses.
Fixed this by taking the priv->buffer_mutex early in the function.Also converted the priv->data_pending from atomic to a regular size_t
type. There is no need for it to be atomic since it is only touched
under the protection of the priv->buffer_mutex.Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tadeusz Struk
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit 8c81c24758ffbf17cf06c6835d361ffa57be2f0e upstream.
If load context command returns with TPM2_RC_HANDLE or TPM2_RC_REFERENCE_H0
then we have use after free in line 114 and double free in 117.Fixes: 4d57856a21ed2 ("tpm2: add session handle context saving and restoring to the space code")
Cc: stable@vger.kernel.org
Signed-off-by: Tadeusz Struk
Reviewed-by: Jarkko Sakkinen
Signed-off--by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit fe50a7d0393a552e4539da2d31261a59d6415950 upstream.
There was one place where the timeout value for an operation was
not being set, if a capabilities request was done from idle. Move
the timeout value setting to before where that change might be
requested.IMHO the cause here is the invisible returns in the macros. Maybe
that's a job for later, though.Reported-by: Nordmark Claes
Signed-off-by: Corey Minyard
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
21 Jun, 2018
1 commit
-
[ Upstream commit dec60f3a9b7251f2657d743d96ba9a83dca02351 ]
Both ‘uninorth_remove_memory’ and ‘null_cache_flush’ can be made
static. So make them.Silence the following gcc warning (W=1):
drivers/char/agp/uninorth-agp.c:198:5: warning: no previous prototype for ‘uninorth_remove_memory’ [-Wmissing-prototypes]
and
drivers/char/agp/uninorth-agp.c:473:6: warning: no previous prototype for ‘null_cache_flush’ [-Wmissing-prototypes]
Signed-off-by: Mathieu Malaterre
Signed-off-by: Dave Airlie
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
30 May, 2018
2 commits
-
[ Upstream commit 326ed382256475aa4b8b7eae8a2f60689fd25e78 ]
Avoid issue when probing the RNG without
reset if bad status has been detected previouslySigned-off-by: Lionel Debieve
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit f002612b9d86613bc6fde0a444e0095225f6053e ]
This happens when BMC doesn't return any data and the code is trying
to print the value of data[2].Getting following crash:
[ 484.728410] Unable to handle kernel NULL pointer dereference at virtual address 00000002
[ 484.736496] pgd = ffff0000094a2000
[ 484.739885] [00000002] *pgd=00000047fcffe003, *pud=00000047fcffd003, *pmd=0000000000000000
[ 484.748158] Internal error: Oops: 96000005 [#1] SMP
[...]
[ 485.101451] Call trace:
[...]
[ 485.188473] [] msg_done_handler+0x668/0x700 [ipmi_ssif]
[ 485.195249] [] ipmi_ssif_thread+0x110/0x128 [ipmi_ssif]
[ 485.202038] [] kthread+0x108/0x138
[ 485.206994] [] ret_from_fork+0x10/0x30
[ 485.212294] Code: aa1903e1 aa1803e0 b900227f 95fef6a5 (39400aa3)Adding a check to validate the data len before printing data[2] to fix this issue.
Signed-off-by: Kamlakant Patel
Signed-off-by: Corey Minyard
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
02 May, 2018
8 commits
-
commit 5c60300d68da32ca77f7f978039dc72bfc78b06b upstream.
When out of memory and we can't add ctrl vq buffers,
probe fails. Unfortunately the error handling is
out of spec: it calls del_vqs without bothering
to reset the device first.To fix, call the full cleanup function in this case.
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Greg Kroah-Hartman -
commit aa44ec867030a72e8aa127977e37dec551d8df19 upstream.
Will make it reusable for error handling.
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Greg Kroah-Hartman -
commit 61a8950c5c5708cf2068b29ffde94e454e528208 upstream.
We now cleanup all VQs on device removal - no need
to handle the control VQ specially.Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Greg Kroah-Hartman -
commit a7a69ec0d8e4a58be7db88d33cbfa2912807bb2b upstream.
Console driver is out of spec. The spec says:
A driver MUST NOT decrement the available idx on a live
virtqueue (ie. there is no way to “unexpose” buffers).
and it does exactly that by trying to detach unused buffers
without doing a device reset first.Defer detaching the buffers until device unplug.
Of course this means we might get an interrupt for
a vq without an attached port now. Handle that by
discarding the consumed buffer.Reported-by: Tiwei Bie
Fixes: b3258ff1d6 ("virtio: Decrement avail idx on buffer detach")
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Greg Kroah-Hartman -
commit 2855b33514d290c51d52d94e25d3ef942cd4d578 upstream.
an allocated buffer doesn't need to be tied to a vq -
only vq->vdev is ever used. Pass the function the
just what it needs - the vdev.Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Greg Kroah-Hartman -
commit 4e00b339e264802851aff8e73cde7d24b57b18ce upstream.
On systems without sufficient boot randomness, no point spamming dmesg.
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 6c1e851c4edc13a43adb3ea4044e3fc8f43ccf7d upstream.
We can do a sleeping allocation from an irq context when CONFIG_NUMA
is enabled. Fix this by initializing the NUMA crng instances in a
workqueue.Reported-by: Tetsuo Handa
Reported-by: syzbot+9de458f6a5e713ee8c1a@syzkaller.appspotmail.com
Fixes: 8ef35c866f8862df ("random: set up the NUMA crng instances...")
Cc: stable@vger.kernel.org
Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman -
commit 8ef35c866f8862df074a49a93b0309725812dea8 upstream.
Until the primary_crng is fully initialized, don't initialize the NUMA
crng nodes. Otherwise users of /dev/urandom on NUMA systems before
the CRNG is fully initialized can get very bad quality randomness. Of
course everyone should move to getrandom(2) where this won't be an
issue, but there's a lot of legacy code out there. This related to
CVE-2018-1108.Reported-by: Jann Horn
Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly...")
Cc: stable@kernel.org # 4.8+
Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman
29 Apr, 2018
3 commits
-
commit e2fb992d82c626c43ed0566e07c410e56a087af3 upstream.
TPM2 can return TPM2_RC_RETRY to any command and when it does we get
unexpected failures inside the kernel that surprise users (this is
mostly observed in the trusted key handling code). The UEFI 2.6 spec
has advice on how to handle this:The firmware SHALL not return TPM2_RC_RETRY prior to the completion
of the call to ExitBootServices().Implementer’s Note: the implementation of this function should check
the return value in the TPM response and, if it is TPM2_RC_RETRY,
resend the command. The implementation may abort if a sufficient
number of retries has been done.So we follow that advice in our tpm_transmit() code using
TPM2_DURATION_SHORT as the initial wait duration and
TPM2_DURATION_LONG as the maximum wait time. This should fix all the
in-kernel use cases and also means that user space TSS implementations
don't have to have their own retry handling.Signed-off-by: James Bottomley
Cc: stable@vger.kernel.org
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit 65520d46a4adbf7f23bbb6d9b1773513f7bc7821 upstream.
Fix tmp_ -> tpm_ typo and add reference to 'space' parameter
in kdoc for tpm_transmit and tpm_transmit_cmd functions.Signed-off-by: Tomas Winkler
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit 888d867df4417deffc33927e6fc2c6925736fe92 upstream.
The correct sequence is to first request locality and only after
that perform cmd_ready handshake, otherwise the hardware will drop
the subsequent message as from the device point of view the cmd_ready
handshake wasn't performed. Symmetrically locality has to be relinquished
only after going idle handshake has completed, this requires that
go_idle has to poll for the completion and as well locality
relinquish has to poll for completion so it is not overridden
in back to back commands flow.Two wrapper functions are added (request_locality relinquish_locality)
to simplify the error handling.The issue is only visible on devices that support multiple localities.
Fixes: 877c57d0d0ca ("tpm_crb: request and relinquish locality 0")
Signed-off-by: Tomas Winkler
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman
26 Apr, 2018
1 commit
-
[ Upstream commit e749d328b0b450aa78d562fa26a0cd8872325dd9 ]
Fix to return a negative error code from the request_irq() error
handling case instead of 0, as done elsewhere in this function.Fixes: dce143c3381c ("ipmi/powernv: Convert to irq event interface")
Signed-off-by: Wei Yongjun
Reviewed-by: Alexey Kardashevskiy
Signed-off-by: Corey Minyard
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
24 Apr, 2018
6 commits
-
commit d848e5f8e1ebdb227d045db55fe4f825e82965fa upstream.
Add a new ioctl which forces the the crng to be reseeded.
Signed-off-by: Theodore Ts'o
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 0bb29a849a6433b72e249eea7695477b02056e94 upstream.
Reported-by: Jann Horn
Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly...")
Cc: stable@kernel.org # 4.8+
Signed-off-by: Theodore Ts'o
Reviewed-by: Jann Horn
Signed-off-by: Greg Kroah-Hartman -
commit dc12baacb95f205948f64dc936a47d89ee110117 upstream.
add_device_randomness() use of crng_fast_load() was highly
problematic. Some callers of add_device_randomness() can pass in a
large amount of static information. This would immediately promote
the crng_init state from 0 to 1, without really doing much to
initialize the primary_crng's internal state with something even
vaguely unpredictable.Since we don't have the speed constraints of add_interrupt_randomness(),
we can do a better job mixing in the what unpredictability a device
driver or architecture maintainer might see fit to give us, and do it
in a way which does not bump the crng_init_cnt variable.Also, since add_device_randomness() doesn't bump any entropy
accounting in crng_init state 0, mix the device randomness into the
input_pool entropy pool as well. This is related to CVE-2018-1108.Reported-by: Jann Horn
Fixes: ee7998c50c26 ("random: do not ignore early device randomness")
Cc: stable@kernel.org # 4.13+
Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman -
commit 43838a23a05fbd13e47d750d3dfd77001536dd33 upstream.
The crng_init variable has three states:
0: The CRNG is not initialized at all
1: The CRNG has a small amount of entropy, hopefully good enough for
early-boot, non-cryptographical use cases
2: The CRNG is fully initialized and we are sure it is safe for
cryptographic use cases.The crng_ready() function should only return true once we are in the
last state. This addresses CVE-2018-1108.Reported-by: Jann Horn
Fixes: e192be9d9a30 ("random: replace non-blocking pool...")
Cc: stable@kernel.org # 4.8+
Signed-off-by: Theodore Ts'o
Reviewed-by: Jann Horn
Signed-off-by: Greg Kroah-Hartman -
commit 0803d7befa15cab5717d667a97a66214d2a4c083 upstream.
The Acer Acer Veriton X4110G has a TPM device detected as:
tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71)After the first S3 suspend, the following error appears during resume:
tpm tpm0: A TPM error(38) occurred continue selftestAny following S3 suspend attempts will now fail with this error:
tpm tpm0: Error (38) sending savestate before suspend
PM: Device 00:0b failed to suspend: error 38Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is
not in the correct state. This indicates that the platform BIOS
is not sending the usual TPM_Startup command during S3 resume.
>From this point onwards, all TPM commands will fail.The same issue was previously reported on Foxconn 6150BK8MC and
Sony Vaio TX3.The platform behaviour seems broken here, but we should not break
suspend/resume because of this.When the unexpected TPM state is encountered, set a flag to skip the
affected TPM_SaveState command on later suspends.Cc: stable@vger.kernel.org
Signed-off-by: Chris Chiu
Signed-off-by: Daniel Drake
Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23UiQ@mail.gmail.com
Link: https://lkml.org/lkml/2011/3/28/192
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit 9f886f4d1d292442b2f22a0a33321eae821bde40 upstream.
This fixes a harmless UBSAN where root could potentially end up
causing an overflow while bumping the entropy_total field (which is
ignored once the entropy pool has been initialized, and this generally
is completed during the boot sequence).This is marginal for the stable kernel series, but it's a really
trivial patch, and it fixes UBSAN warning that might cause security
folks to get overly excited for no reason.Signed-off-by: Theodore Ts'o
Reported-by: Chen Feng
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
12 Apr, 2018
1 commit
-
[ Upstream commit 095531f891e627e408606f2da4008d3d53e6748a ]
According to the TPM Library Specification, a TPM device must do a command
header validation before processing and return a TPM_RC_COMMAND_CODE code
if the command is not implemented.So user-space will expect to handle that response as an error. But if the
in-kernel resource manager is used (/dev/tpmrm?), an -EINVAL errno code is
returned instead if the command isn't implemented. This confuses userspace
since it doesn't expect that error value.This also isn't consistent with the behavior when not using TPM spaces and
accessing the TPM directly (/dev/tpm?). In this case, the command is sent
to the TPM even when not implemented and the TPM responds with an error.Instead of returning an -EINVAL errno code when the tpm_validate_command()
function fails, synthesize a TPM command response so user-space can get a
TPM_RC_COMMAND_CODE as expected when a chip doesn't implement the command.The TPM only sets 12 of the 32 bits in the TPM_RC response, so the TSS and
TAB specifications define that higher layers in the stack should use some
of the unused 20 bits to specify from which level of the stack the error
is coming from.Since the TPM_RC_COMMAND_CODE response code is sent by the kernel resource
manager, set the error level to the TAB/RM layer so user-space is aware of
this.Suggested-by: Jason Gunthorpe
Signed-off-by: Javier Martinez Canillas
Reviewed-by: William Roberts
Reviewed-by: Philip Tricca
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
08 Apr, 2018
1 commit
-
commit b5b38200ebe54879a7264cb6f33821f61c586a7e upstream.
Successes in probe_kernel_read() would mask failures in copy_to_user()
during read_mem().Reported-by: Brad Spengler
Fixes: 22ec1a2aea73 ("/dev/mem: Add bounce buffer for copy-out")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook
Signed-off-by: Greg Kroah-Hartman
