Since the definition of struct crng_state is private to random.c, and
primary_crng is neither declared or used elsewhere, there's no reason
for that symbol to have external linkage.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This field is never used, might as well remove it.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Never modified, might as well be put in .rodata.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The intended behavior of function ipmi_hardcode_init_one() is to default
to kcs interface when no type argument is presented when initializing
ipmi with hard coded addresses.
However, the array of char pointers allocated on the stack by function
ipmi_hardcode_init() was not inited to zeroes, so it contained stack
debris.
Consequently, passing the cruft stored in this array to function
ipmi_hardcode_init_one() caused a crash when it was unable to detect
that the char * being passed was nonsense and tried to access the
address specified by the bogus pointer.
The fix is simply to initialize the si_type array to zeroes, so if
there were no type argument given to at the command line, function
ipmi_hardcode_init_one() could properly default to the kcs interface.
Signed-off-by: Tony Camuso <tcamuso@redhat.com>
Message-Id: <1554837603-40299-1-git-send-email-tcamuso@redhat.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
An extra memset was put into a place that cleared the interface
type.
Reported-by: Tony Camuso <tcamuso@redhat.com>
Fixes: 3cd83bac48 ("ipmi: Consolidate the adding of platform devices")
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Add a default quality to hw_random device to be
automatically set as new default entropy. Setting
random quality will decrease the crng init time by
switching to this hardware random source.
Signed-off-by: Lionel Debieve <lionel.debieve@st.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
No remove function implemented yet in the driver.
Without remove function, the pm_runtime implementation
complains when removing and probing again the driver.
Signed-off-by: Lionel Debieve <lionel.debieve@st.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
calc_tpm2_event_size() has an invalid signature because
it returns a 'size_t' where as its signature says that
it returns 'int'.
Cc: <stable@vger.kernel.org>
Fixes: 4d23cc323c ("tpm: add securityfs support for TPM 2.0 firmware event log")
Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: James Morris <james.morris@microsoft.com>
The poll condition should only check response_length,
because reads should only be issued if there is data to read.
The response_read flag only prevents double writes.
The problem was that the write set the response_read to false,
enqued a tpm job, and returned. Then application called poll
which checked the response_read flag and returned EPOLLIN.
Then the application called read, but got nothing.
After all that the async_work kicked in.
Added also mutex_lock around the poll check to prevent
other possible race conditions.
Fixes: 9488585b21 ("tpm: add support for partial reads")
Reported-by: Mantas Mikulėnas <grawity@gmail.com>
Tested-by: Mantas Mikulėnas <grawity@gmail.com>
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: James Morris <james.morris@microsoft.com>
tpm_chip_start/stop() should be also called for TPM 1.x devices on
suspend. Add that functionality back. Do not lock the chip because
it is unnecessary as there are no multiple threads using it when
doing the suspend.
Fixes: a3fbfae82b ("tpm: take TPM chip power gating out of tpm_transmit()")
Reported-by: Paul Zimmerman <pauldzim@gmail.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Domenico Andreoli <domenico.andreoli@linux.com>
Signed-off-by: James Morris <james.morris@microsoft.com>
The n_r3964 line discipline driver was written in a different time, when
SMP machines were rare, and users were trusted to do the right thing.
Since then, the world has moved on but not this code, it has stayed
rooted in the past with its lovely hand-crafted list structures and
loads of "interesting" race conditions all over the place.
After attempting to clean up most of the issues, I just gave up and am
now marking the driver as BROKEN so that hopefully someone who has this
hardware will show up out of the woodwork (I know you are out there!)
and will help with debugging a raft of changes that I had laying around
for the code, but was too afraid to commit as odds are they would break
things.
Many thanks to Jann and Linus for pointing out the initial problems in
this codebase, as well as many reviews of my attempts to fix the issues.
It was a case of whack-a-mole, and as you can see, the mole won.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Check if ioremap fails, and if so, return AE_ERROR.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For regular serial ports we do not initialize value of vtermno
variable. A garbage value is assigned for non console ports.
The value can be observed as a random integer with [1].
[1] vim /sys/kernel/debug/virtio-ports/vport*p*
This patch initialize the value of vtermno for console serial
ports to '1' and regular serial ports are initiaized to '0'.
Reported-by: siliu@redhat.com
Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Newer combinations of the glibc, kernel and openssh can result in long initial
startup times on OMAP devices:
[ 6.671425] systemd-rc-once[102]: Creating ED25519 key; this may take some time ...
[ 142.652491] systemd-rc-once[102]: Creating ED25519 key; done.
due to the blocking getrandom(2) system call:
[ 142.610335] random: crng init done
Set the quality level for the omap hwrng driver allowing the kernel to use the
hwrng as an entropy source at boot.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Pull tpm updates from James Morris:
- Clean up the transmission flow
Cleaned up the whole transmission flow. Locking of the chip is now
done in the level of tpm_try_get_ops() and tpm_put_ops() instead
taking the chip lock inside tpm_transmit(). The nested calls inside
tpm_transmit(), used with the resource manager, have been refactored
out.
Should make easier to perform more complex transactions with the TPM
without making the subsystem a bigger mess (e.g. encrypted channel
patches by James Bottomley).
- PPI 1.3 support
TPM PPI 1.3 introduces an additional optional command parameter that
may be needed for some commands. Display the parameter if the command
requires such a parameter. Only command 23 (SetPCRBanks) needs one.
The PPI request file will show output like this then:
# echo "23 16" > request
# cat request
23 16
# echo "5" > request
# cat request
5
- Extend all PCR banks in IMA
Instead of static PCR banks array, the array of available PCR banks
is now allocated dynamically. The digests sizes are determined
dynamically using a probe PCR read without relying crypto's static
list of hash algorithms.
This should finally make sealing of measurements in IMA safe and
secure.
- TPM 2.0 selftests
Added a test suite to tools/testing/selftests/tpm2 previously outside
of the kernel tree: https://github.com/jsakkine-intel/tpm2-scripts
* 'next-tpm' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (37 commits)
tpm/ppi: Enable submission of optional command parameter for PPI 1.3
tpm/ppi: Possibly show command parameter if TPM PPI 1.3 is used
tpm/ppi: Display up to 101 operations as define for version 1.3
tpm/ppi: rename TPM_PPI_REVISION_ID to TPM_PPI_REVISION_ID_1
tpm/ppi: pass function revision ID to tpm_eval_dsm()
tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()
KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()
tpm: move tpm_chip definition to include/linux/tpm.h
tpm: retrieve digest size of unknown algorithms with PCR read
tpm: rename and export tpm2_digest and tpm2_algorithms
tpm: dynamically allocate the allocated_banks array
tpm: remove @flags from tpm_transmit()
tpm: take TPM chip power gating out of tpm_transmit()
tpm: introduce tpm_chip_start() and tpm_chip_stop()
tpm: remove TPM_TRANSMIT_UNLOCKED flag
tpm: use tpm_try_get_ops() in tpm-sysfs.c.
tpm: remove @space from tpm_transmit()
tpm: move TPM space code out of tpm_transmit()
tpm: move tpm_validate_commmand() to tpm2-space.c
tpm: clean up tpm_try_transmit() error handling flow
...
* Fix a use after free error in a certain error situation.
* Fix some flag handling issues in the SSIF (I2C) IPMI driver.
* A bunch of cleanups, spacing issues, converting pr_xxx to dev_xxx,
use standard UUID handling, and some other minor stuff.
* The IPMI code was creating a platform device if none was supplied.
Instead of doing that, have every source that creates an IPMI
device supply a device struct. This fixes several issues,including
a crash in one situation, and cleans things up a bit.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE/Q1c5nzg9ZpmiCaGYfOMkJGb/4EFAlx+qm8ACgkQYfOMkJGb
/4F8rxAAmzPgNowsV6T0T9ZHg35XRx31vjPyrCZsbzBv0ahSr6mIwoz41iZAz1z8
bGjJJ8LA6oqfG9PsolUMc8RsiHXOlCXR2qpcx7r6N1Ptj/7VNdy9UneIl5UwnxhP
1mGkWJeKYQn3tXVa8PjzfX9kZ3gxcooL9q+0+m2E6O5M/ldzUvWDGXRfoVD+Uy88
RoPd3AeUnaIBDoB42l5a9EzPr+xXVKYSPl7WLEgV4GTwWRANvFP88PSXOenzo35b
G08Yq6+u1M1QY/HJLLtvanHWpkBrHGLr+XTdXKAxKgV40s2flL4xBSfYWF8RFLCW
R74HXwSOSvpZEhROrleaj2GcL1DsJhQj5Q+DsYAIyMJSkavPtFZU2TRL+nOUoe39
wJdS5F0i7qhnNPtj0Iatz9zOwY5apT5vj7/MAEXIQi2t+p1m7ado1kw7CDaQsTOK
ONzhlxCZ6b6rvdpJ7hH8u1AAejRoZ8tq9rAdsKSJvgTPiDrtLDlouPkAQCJpl7Ub
VsByzrXeL2a6yEW9W5V2LH2UXandRAKguzvnYDOEbY5bVOmQmEaoDWTvoC5jRr6K
MRobCgC96UpNgY4SXJSoZunrFjuGJR0CN66BJd52afcxEM/iu50Z8+DJ92KnDjhY
E8XVvC5fXH6EMF1yDIt51GiDyHYQXX1TaNArFuFZWaEJ8e2gT6M=
=LSch
-----END PGP SIGNATURE-----
Merge tag 'for-linus-5.1' of git://github.com/cminyard/linux-ipmi
Pull IPMI updates from Corey Minyard:
"A couple of bug fixes and a bunch of code cleanup:
- Fix a use after free error in a certain error situation.
- Fix some flag handling issues in the SSIF (I2C) IPMI driver.
- A bunch of cleanups, spacing issues, converting pr_xxx to dev_xxx,
use standard UUID handling, and some other minor stuff.
- The IPMI code was creating a platform device if none was supplied.
Instead of doing that, have every source that creates an IPMI
device supply a device struct. This fixes several issues,including
a crash in one situation, and cleans things up a bit"
* tag 'for-linus-5.1' of git://github.com/cminyard/linux-ipmi:
ipmi_si: Potential array underflow in hotmod_handler()
ipmi_si: Remove hacks for adding a dummy platform devices
ipmi_si: Consolidate scanning the platform bus
ipmi_si: Remove hotmod devices on removal and exit
ipmi_si: Remove hardcode IPMI devices by scanning the platform bus
ipmi_si: Switch hotmod to use a platform device
ipmi: Consolidate the adding of platform devices
ipmi_si: Rename addr_type to addr_space to match what it does
ipmi_si: Convert some types into unsigned
ipmi_si: Fix crash when using hard-coded device
ipmi: Use dedicated API for copying a UUID
ipmi: Use defined constant for UUID representation
ipmi:ssif: Change some pr_xxx to dev_xxx calls
ipmi: kcs_bmc: handle devm_kasprintf() failure case
ipmi: Fix return value when a message is truncated
ipmi: clean an indentation issue, remove extraneous space
ipmi: Make the smi watcher be disabled immediately when not needed
ipmi: Fix how the lower layers are told to watch for messages
ipmi: Fix SSIF flag requests
ipmi_si: fix use-after-free of resource->name
Here is the big char/misc driver patch pull request for 5.1-rc1.
The largest thing by far is the new habanalabs driver for their AI
accelerator chip. For now it is in the drivers/misc directory but will
probably move to a new directory soon along with other drivers of this
type.
Other than that, just the usual set of individual driver updates and
fixes. There's an "odd" merge in here from the DRM tree that they asked
me to do as the MEI driver is starting to interact with the i915 driver,
and it needed some coordination. All of those patches have been
properly acked by the relevant subsystem maintainers.
All of these have been in linux-next with no reported issues, most for
quite some time.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXH+dPQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ym1fACgvpZAxjNzoRQJ6f06tc8ujtPk9rUAnR+tCtrZ
9e3l7H76oe33o96Qjhor
=8A2k
-----END PGP SIGNATURE-----
Merge tag 'char-misc-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver updates from Greg KH:
"Here is the big char/misc driver patch pull request for 5.1-rc1.
The largest thing by far is the new habanalabs driver for their AI
accelerator chip. For now it is in the drivers/misc directory but will
probably move to a new directory soon along with other drivers of this
type.
Other than that, just the usual set of individual driver updates and
fixes. There's an "odd" merge in here from the DRM tree that they
asked me to do as the MEI driver is starting to interact with the i915
driver, and it needed some coordination. All of those patches have
been properly acked by the relevant subsystem maintainers.
All of these have been in linux-next with no reported issues, most for
quite some time"
* tag 'char-misc-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (219 commits)
habanalabs: adjust Kconfig to fix build errors
habanalabs: use %px instead of %p in error print
habanalabs: use do_div for 64-bit divisions
intel_th: gth: Fix an off-by-one in output unassigning
habanalabs: fix little-endian<->cpu conversion warnings
habanalabs: use NULL to initialize array of pointers
habanalabs: fix little-endian<->cpu conversion warnings
habanalabs: soft-reset device if context-switch fails
habanalabs: print pointer using %p
habanalabs: fix memory leak with CBs with unaligned size
habanalabs: return correct error code on MMU mapping failure
habanalabs: add comments in uapi/misc/habanalabs.h
habanalabs: extend QMAN0 job timeout
habanalabs: set DMA0 completion to SOB 1007
habanalabs: fix validation of WREG32 to DMA completion
habanalabs: fix mmu cache registers init
habanalabs: disable CPU access on timeouts
habanalabs: add MMU DRAM default page mapping
habanalabs: Dissociate RAZWI info from event types
misc/habanalabs: adjust Kconfig to fix build errors
...
Merge misc updates from Andrew Morton:
- a few misc things
- ocfs2 updates
- most of MM
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (159 commits)
tools/testing/selftests/proc/proc-self-syscall.c: remove duplicate include
proc: more robust bulk read test
proc: test /proc/*/maps, smaps, smaps_rollup, statm
proc: use seq_puts() everywhere
proc: read kernel cpu stat pointer once
proc: remove unused argument in proc_pid_lookup()
fs/proc/thread_self.c: code cleanup for proc_setup_thread_self()
fs/proc/self.c: code cleanup for proc_setup_self()
proc: return exit code 4 for skipped tests
mm,mremap: bail out earlier in mremap_to under map pressure
mm/sparse: fix a bad comparison
mm/memory.c: do_fault: avoid usage of stale vm_area_struct
writeback: fix inode cgroup switching comment
mm/huge_memory.c: fix "orig_pud" set but not used
mm/hotplug: fix an imbalance with DEBUG_PAGEALLOC
mm/memcontrol.c: fix bad line in comment
mm/cma.c: cma_declare_contiguous: correct err handling
mm/page_ext.c: fix an imbalance with kmemleak
mm/compaction: pass pgdat to too_many_isolated() instead of zone
mm: remove zone_lru_lock() function, access ->lru_lock directly
...
As usual, the drivers/tee and drivers/reset subsystems get merged
here, with the expected set of smaller updates and some new hardware
support. The tee subsystem now supports device drivers to be attached
to a tee, the first example here is a random number driver with its
implementation in the secure world.
Three new power domain drivers get added for specific chip families:
- Broadcom BCM283x chips (used in Raspberry Pi)
- Qualcomm Snapdragon phone chips
- Xilinx ZynqMP FPGA SoCs
One new driver is added to talk to the BPMP firmware on NVIDIA
Tegra210
Existing drivers are extended for new SoC variants from NXP,
NVIDIA, Amlogic and Qualcomm.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJcfpKpAAoJEGCrR//JCVInMpYQANwKKWOTm5NHqtf7/ZKBzx6/
Yk7Jj8QLGKrHScnuBZSBvTwv5Cc5O5Ye+tAuGVArOoD2ktXlLZmHZ/ZPFAudT3di
aFYbA44RNhv+O/xOmToDCCjSHm176hwUY0Cs5bFnfx6TcMsdOYIQIG+XQKx/a9zg
3ZBEv7wZqcBArLc0X2Z2/uiVrEIh3wWwXytvw+8TG8ifUfpbDxRUxDlj1JRDpjMu
yX4q8JDhdQvi2FTXbXcEHTdQ6RT11svPM/YxQDxfULRK9aNKf4GZJ4QlwZy+SO7N
cEFxDd4ML/iJ1LjalvtXGkR0xrw9/gOlO3vbB9Uw3EngBDUSQfHmqJet10a14l8q
KcToe3teIB+Z1R+plrt+h5UDJTbVibgZXhU6wIdkDgtF6oTyg1moIbTqNKHgcA3b
HLJv4gFejeluQzJ/3dZHBnkvJo1XFAvGFmFXle0bmJRFtDx73CKnf6MA9N82l2/x
nTn4LTxXIJVKWTWAs1qkrFyIx1gOrpGhiHPQ2JiOPMZLstz3Sr6tiJuWOr+1Ex4/
UlZsD/CrRb+SbPBonpkD+bvzSR+j0M72A7hGmfZcDzainciWgunyXglUlzO/MT24
C6p4R9MZ2Fffoe8pESppabRNUItp8gNsNGI7CY1IK8pgpxLrujw8OnqykpV0VETo
As+6dZrHfPNSuI7udJi5
=+DOl
-----END PGP SIGNATURE-----
Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC driver updates from Arnd Bergmann:
"As usual, the drivers/tee and drivers/reset subsystems get merged
here, with the expected set of smaller updates and some new hardware
support. The tee subsystem now supports device drivers to be attached
to a tee, the first example here is a random number driver with its
implementation in the secure world.
Three new power domain drivers get added for specific chip families:
- Broadcom BCM283x chips (used in Raspberry Pi)
- Qualcomm Snapdragon phone chips
- Xilinx ZynqMP FPGA SoCs
One new driver is added to talk to the BPMP firmware on NVIDIA
Tegra210
Existing drivers are extended for new SoC variants from NXP, NVIDIA,
Amlogic and Qualcomm"
* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (113 commits)
tee: optee: update optee_msg.h and optee_smc.h to dual license
tee: add cancellation support to client interface
dpaa2-eth: configure the cache stashing amount on a queue
soc: fsl: dpio: configure cache stashing destination
soc: fsl: dpio: enable frame data cache stashing per software portal
soc: fsl: guts: make fsl_guts_get_svr() static
hwrng: make symbol 'optee_rng_id_table' static
tee: optee: Fix unsigned comparison with less than zero
hwrng: Fix unsigned comparison with less than zero
tee: fix possible error pointer ctx dereferencing
hwrng: optee: Initialize some structs using memset instead of braces
tee: optee: Initialize some structs using memset instead of braces
soc: fsl: dpio: fix memory leak of a struct qbman on error exit path
clk: tegra: dfll: Make symbol 'tegra210_cpu_cvb_tables' static
soc: qcom: llcc-slice: Fix typos
qcom: soc: llcc-slice: Consolidate some code
qcom: soc: llcc-slice: Clear the global drv_data pointer on error
drivers: soc: xilinx: Add ZynqMP power domain driver
firmware: xilinx: Add APIs to control node status/power
dt-bindings: power: Add ZynqMP power domain bindings
...
Patch series "mm: PG_reserved cleanups and documentation", v2.
I was recently going over all users of PG_reserved. Short story: it is
difficult and sometimes not really clear if setting/checking for
PG_reserved is only a relict from the past. Easy to break things. I
guess I now have a pretty good idea wh things are like that nowadays and
how they evolved.
I had way more cleanups in this series inititally, but some
architectures take PG_reserved as a way to apply a different caching
strategy (for MMIO pages). So I decided to only include the most
obvious changes (that are less likely to break something). So the big
chunk of manual SetPageReserved users are MMIO/DMA related things on
device buffers.
Most notably, for device memory we will hopefully soon stop setting
PG_reserved. Then the documentation has to be updated.
This patch (of 9):
The l1 GATT page table is kept in a special on-chip page with 64
entries. We allocate the l2 page table pages via get_zeroed_page() and
enter them into the table. These l2 pages are modified accordingly when
inserting/removing memory via efficeon_insert_memory and
efficeon_remove_memory.
Apart from that, these pages are not exposed or ioremap'ed. We can stop
setting them reserved (propably copied from generic code).
Link: http://lkml.kernel.org/r/20190114125903.24845-2-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull crypto update from Herbert Xu:
"API:
- Add helper for simple skcipher modes.
- Add helper to register multiple templates.
- Set CRYPTO_TFM_NEED_KEY when setkey fails.
- Require neither or both of export/import in shash.
- AEAD decryption test vectors are now generated from encryption
ones.
- New option CONFIG_CRYPTO_MANAGER_EXTRA_TESTS that includes random
fuzzing.
Algorithms:
- Conversions to skcipher and helper for many templates.
- Add more test vectors for nhpoly1305 and adiantum.
Drivers:
- Add crypto4xx prng support.
- Add xcbc/cmac/ecb support in caam.
- Add AES support for Exynos5433 in s5p.
- Remove sha384/sha512 from artpec7 as hardware cannot do partial
hash"
[ There is a merge of the Freescale SoC tree in order to pull in changes
required by patches to the caam/qi2 driver. ]
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (174 commits)
crypto: s5p - add AES support for Exynos5433
dt-bindings: crypto: document Exynos5433 SlimSSS
crypto: crypto4xx - add missing of_node_put after of_device_is_available
crypto: cavium/zip - fix collision with generic cra_driver_name
crypto: af_alg - use struct_size() in sock_kfree_s()
crypto: caam - remove redundant likely/unlikely annotation
crypto: s5p - update iv after AES-CBC op end
crypto: x86/poly1305 - Clear key material from stack in SSE2 variant
crypto: caam - generate hash keys in-place
crypto: caam - fix DMA mapping xcbc key twice
crypto: caam - fix hash context DMA unmap size
hwrng: bcm2835 - fix probe as platform device
crypto: s5p-sss - Use AES_BLOCK_SIZE define instead of number
crypto: stm32 - drop pointless static qualifier in stm32_hash_remove()
crypto: chelsio - Fixed Traffic Stall
crypto: marvell - Remove set but not used variable 'ivsize'
crypto: ccp - Update driver messages to remove some confusion
crypto: adiantum - add 1536 and 4096-byte test vectors
crypto: nhpoly1305 - add a test vector with len % 16 != 0
crypto: arm/aes-ce - update IV after partial final CTR block
...
BCM63XX (MIPS) does not use device tree, so there cannot be any
of_device_id, causing the driver to fail on probe:
[ 0.904564] bcm2835-rng: probe of bcm63xx-rng failed with error -22
Fix this by checking for match data only if we are probing from device
tree.
Fixes: 8705f24f7b ("hwrng: bcm2835 - Enable BCM2835 RNG to work on BCM63xx platforms")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kzalloc(size, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
Notice that, in this case, variable siz is not necessary, hence
it is removed.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "ival" variable needs to signed so that we don't read before the
start of the str[] array. This would only happen the user passed in a
module parameter that was just comprised of space characters.
Fixes: e80444ae4fc3 ("ipmi_si: Switch hotmod to use a platform device")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Message-Id: <20190222195530.GA306@kadam>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
When a hotmod-added device is removed or when the module is removed,
remove the platform devices that was created for it.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Instead of keeping track of each one, just scan the platform bus
for hardcode devices and remove them.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
It was being done in two different places now that hard-coded devices
use platform devices, and it's about to be three with hotmod switching
to platform devices. So put the code in one place.
This required some rework on some interfaces to make the type space
clean.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
When excuting a command like:
modprobe ipmi_si ports=0xffc0e3 type=bt
The system would get an oops.
The trouble here is that ipmi_si_hardcode_find_bmc() is called before
ipmi_si_platform_init(), but initialization of the hard-coded device
creates an IPMI platform device, which won't be initialized yet.
The real trouble is that hard-coded devices aren't created with
any device, and the fixup is done later. So do it right, create the
hard-coded devices as normal platform devices.
This required adding some new resource types to the IPMI platform
code for passing information required by the hard-coded device
and adding some code to remove the hard-coded platform devices
on module removal.
To enforce the "hard-coded devices passed by the user take priority
over firmware devices" rule, some special code was added to check
and see if a hard-coded device already exists.
Reported-by: Yang Yingliang <yangyingliang@huawei.com>
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: Yang Yingliang <yangyingliang@huawei.com>
Fixes the following sparse warning:
drivers/char/hw_random/optee-rng.c:265:35: warning:
symbol 'optee_rng_id_table' was not declared. Should it be static?
Fixes: 5fe8b1cc6a ("hwrng: add OP-TEE based rng driver")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The return from the call to tee_client_invoke_func can be a
negative error code however this is being assigned to an
unsigned variable 'ret' hence the check is always false.
Fix this by making 'ret' an int.
Detected by Coccinelle ("Unsigned expression compared with zero:
ret < 0")
Fixes: 5fe8b1cc6a ("hwrng: add OP-TEE based rng driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Clang warns:
drivers/char/hw_random/optee-rng.c:80:31: warning: suggest braces around
initialization of subobject [-Wmissing-braces]
struct tee_param param[4] = {0};
^
{}
drivers/char/hw_random/optee-rng.c:177:31: warning: suggest braces
around initialization of subobject [-Wmissing-braces]
struct tee_param param[4] = {0};
^
{}
drivers/char/hw_random/optee-rng.c:212:48: warning: suggest braces
around initialization of subobject [-Wmissing-braces]
struct tee_ioctl_open_session_arg sess_arg = {0};
^
{}
3 warnings generated.
One way to fix these warnings is to add additional braces like Clang
suggests; however, there has been a bit of push back from some
maintainers, who just prefer memset as it is unambiguous, doesn't
depend on a particular compiler version, and properly initializes all
subobjects [1][2]. Do that here so there are no more warnings.
[1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9684@amd.com/
[2]: https://lore.kernel.org/lkml/20181128.215241.702406654469517539.davem@davemloft.net/
Fixes: 5fe8b1cc6a ("hwrng: add OP-TEE based rng driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/369
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- supp_nowait flag for non-blocking tee requests
- The tee bus driver framework
- OP-TEE TEE bus device enumeration support
- An OP-TEE based rng driver
-----BEGIN PGP SIGNATURE-----
iQJOBAABCgA4FiEEcK3MsDvGvFp6zV9ztbC4QZeP7NMFAlxUwVoaHGplbnMud2lr
bGFuZGVyQGxpbmFyby5vcmcACgkQtbC4QZeP7NMzCA//S0fLom4hKSz8hgfpXBxR
0RsOiEBE+LGIfShBx+tj+yzG0DPvRBsa4lbvX/uKdPJk/1giazi0lJn3GPQf0XOU
Lfdb03hyoKknK5AoPm3N8AceyP9FMkT/813Moxrc35FgQV6OvSGGmjtXs+NQ5SbZ
m7YV/zJIkGbNzfRiyN389AtbV95UpNDs7FjTw/d/CZ/U9mRSHAvR1zAUXMgcPpwI
XcdhIfgWe0bPjYsX3EmxCRPM0MKrG1LQDB95dkH6+uKM9Fh2MYb+6P5bXlETM5DI
ruMupkT+iXXLye2pDPZC1G8Czhqy55qYSTCz3fKZt/onhCUghT9W9yUoxZyvvsEP
6Yf7vDjcBVGfUyvdUEpkmjpjejgbzEkZVxvC+9S8PzPzdWqLD6fHAj+IHkq1mjc7
joqRcpfkTqldvcDpBVoN4QchTs/1ERNPvs+XG7auBSkB9tPAIQP72UBxVxnzq4QM
RSJETWND3eylCw08wXrPngbBAejyGDnl2oBnuR0PqVtEWDMiJvkoRl/1F8CxnDM6
aKk2XlslgAQdwnEpN4h1Z+Nnn/KtYoQ3cDHZoGMQ6ktVdUeNvicL1FcbioWCGnI6
mu6pw2i0UKNxFSTLUn8+32Ao9pe4dLsJcOYMZyGQHdnG4M53pCJRRgqh1Bil1s63
4NvqHsa62AUqyRPeQSCj1IU=
=So4a
-----END PGP SIGNATURE-----
Merge tag 'tee-bus-for-5.1' of https://git.linaro.org/people/jens.wiklander/linux-tee into arm/drivers
Introduce TEE bus driver framework
- supp_nowait flag for non-blocking tee requests
- The tee bus driver framework
- OP-TEE TEE bus device enumeration support
- An OP-TEE based rng driver
* tag 'tee-bus-for-5.1' of https://git.linaro.org/people/jens.wiklander/linux-tee:
hwrng: add OP-TEE based rng driver
tee: optee: add TEE bus device enumeration support
tee: add bus driver framework for TEE based devices
tee: add supp_nowait flag in tee_context struct
In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.
This patch fixes the following warnings:
drivers/char/lp.c: In function ‘lp_compat_ioctl’:
drivers/char/lp.c:756:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (!COMPAT_USE_64BIT_TIME) {
^
drivers/char/lp.c:761:2: note: here
case LPSETTIMEOUT_NEW:
^~~~
drivers/char/lp.c: In function ‘lp_ioctl’:
drivers/char/lp.c:728:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (BITS_PER_LONG == 32) {
^
drivers/char/lp.c:733:2: note: here
case LPSETTIMEOUT_NEW:
^~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
Notice that in some cases, the code comment is modified in
accordance with what GCC is expecting to find.
This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch enables a user to specify the additional optional command
parameter by writing it into the request file:
# echo "23 16" > request
# cat request
23 16
For backwards compatibility:
If only 1 parameter is given then we assume this is the operation request
number.
# echo "5" > request
# cat request
5
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: David Safford <david.safford@ge.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
TPM PPI 1.3 introduces an additional optional command parameter
that may be needed for some commands. Display the parameter if the
command requires such a parameter. Only command 23 needs one.
The PPI request file will show output like this then:
# echo "23 16" > request
# cat request
23 16
# echo "5" > request
# cat request
5
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: David Safford <david.safford@ge.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
TPM PPI 1.3 defines operations up to number 101. We need to query up
to this number to show the user what the firmware implements.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: David Safford <david.safford@ge.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
TPM PPI 1.3 introduces a function revision 2 for some functions. So,
rename the existing TPM_PPI_REVISION_ID to TPM_PPI_REVISION_ID_1.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: David Safford <david.safford@ge.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Since we will need to pass different function revision numbers
to tpm_eval_dsm, convert this function now to take the function revision
as an additional parameter.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: David Safford <david.safford@ge.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Currently, tpm_pcr_extend() accepts as an input only a SHA1 digest.
This patch replaces the hash parameter of tpm_pcr_extend() with an array of
tpm_digest structures, so that the caller can provide a digest for each PCR
bank currently allocated in the TPM.
tpm_pcr_extend() will not extend banks for which no digest was provided,
as it happened before this patch, but instead it requires that callers
provide the full set of digests. Since the number of digests will always be
chip->nr_allocated_banks, the count parameter has been removed.
Due to the API change, ima_pcr_extend() and pcrlock() have been modified.
Since the number of allocated banks is not known in advance, the memory for
the digests must be dynamically allocated. To avoid performance degradation
and to avoid that a PCR extend is not done due to lack of memory, the array
of tpm_digest structures is allocated by the users of the TPM driver at
initialization time.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Mimi Zohar <zohar@linux.ibm.com> (on x86 for TPM 1.2 & PTT TPM 2.0)
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
The tpm_chip structure contains the list of PCR banks currently allocated
in the TPM. When support for crypto agility will be added to the TPM
driver, users of the driver have to provide a digest for each allocated
bank to tpm_pcr_extend(). With this patch, they can obtain the PCR bank
algorithms directly from chip->allocated_banks.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Currently, the TPM driver retrieves the digest size from a table mapping
TPM algorithms identifiers to identifiers defined by the crypto subsystem.
If the algorithm is not defined by the latter, the digest size can be
retrieved from the output of the PCR read command.
The patch modifies the definition of tpm_pcr_read() and tpm2_pcr_read() to
pass the desired hash algorithm and obtain the digest size at TPM startup.
Algorithms and corresponding digest sizes are stored in the new structure
tpm_bank_info, member of tpm_chip, so that the information can be used by
other kernel subsystems.
tpm_bank_info contains: the TPM algorithm identifier, necessary to generate
the event log as defined by Trusted Computing Group (TCG); the digest size,
to pad/truncate a digest calculated with a different algorithm; the crypto
subsystem identifier, to calculate the digest of event data.
This patch also protects against data corruption that could happen in the
bus, by checking that the digest size returned by the TPM during a PCR read
matches the size of the algorithm passed to tpm2_pcr_read().
For the initial PCR read, when digest sizes are not yet available, this
patch ensures that the amount of data copied from the output returned by
the TPM does not exceed the size of the array data are copied to.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Rename tpm2_* to tpm_* and move the definitions to include/linux/tpm.h so
that these can be used by other kernel subsystems (e.g. IMA).
Also, set the length of the digest array in tpm_digest to a new constant
named TPM_MAX_DIGEST_SIZE, equal to SHA512_DIGEST_SIZE.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
This patch renames active_banks (member of tpm_chip) to allocated_banks,
stores the number of allocated PCR banks in nr_allocated_banks (new member
of tpm_chip), and replaces the static array with a pointer to a dynamically
allocated array.
tpm2_get_pcr_allocation() determines if a PCR bank is allocated by checking
the mask in the TPML_PCR_SELECTION structure returned by the TPM for
TPM2_Get_Capability(). If a bank is not allocated, the TPM returns that
bank in TPML_PCR_SELECTION, with all bits in the mask set to zero. In this
case, the bank is not included in chip->allocated_banks, to avoid that TPM
driver users unnecessarily calculate a digest for that bank.
One PCR bank with algorithm set to SHA1 is always allocated for TPM 1.x.
As a consequence of the introduction of nr_allocated_banks,
tpm_pcr_extend() does not check anymore if the algorithm stored in tpm_chip
is equal to zero.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Remove @flags from tpm_transmit() API. It is no longer used for
anything.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Call tpm_chip_start() and tpm_chip_stop() in
* tpm_chip_register()
* tpm_class_shutdown()
* tpm_del_char_device()
* tpm_pm_suspend()
* tpm_try_get_ops() and tpm_put_ops()
* tpm2_del_space()
And remove these calls from tpm_transmit(). The core reason for this
change is that in tpm_vtpm_proxy a locality change requires a virtual
TPM command (a command made up just for that driver).
The consequence of this is that this commit removes the remaining nested
calls.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Encapsulate power gating and locality functionality to tpm_chip_start()
and tpm_chip_stop() in order to clean up the branching mess in
tpm_transmit().
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Added locking as part of tpm_try_get_ops() and tpm_put_ops() as they are
anyway used in most of the call sites except in tpmrm_release() where we
take the locks manually.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Use tpm_try_get_ops() in tpm-sysfs.c so that we can consider moving
other decorations (locking, localities, power management for example)
inside it. This direction can be of course taken only after other call
sites for tpm_transmit() have been treated in the same way.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Remove @space from tpm_transmit() API` in order to completely remove the
bound between low-level transmission functionality and TPM spaces. The
only real dependency existing is the amount of data saved before trying
to send a command to the TPM.
It doesn't really matter if we save always a bit more than needed so
this commit changes the amount saved always to be the size of the TPM
header and three handles.
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Prepare and commit TPM space before and after calling tpm_transmit()
instead of doing that inside tpm_transmit(). After this change we can
remove TPM_TRANSMIT_NESTED flag from tpm2_prepare_space() and
tpm2_commit_space() and replace it with TPM_TRANSMIT_UNLOCKED.
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Move tpm_validate_command() to tpm2-space.c and make it part of the
tpm2_prepare_space() flow. Make cc resolution as part of the TPM space
functionality in order to detach it from rest of the tpm_transmit()
flow.
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Move locking, locality handling and power management to tpm_transmit()
in order to simplify the flow.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Encapsulate tpm_transmit() call pattern to tpm_dev_transmit() because it
is identically used from two places. Use unlocked version of
tpm_transmit() so that we are able to move the calls to
tpm2_prepare_space() and tpm2_commit_space() later on to this new
function.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Instead of accessing fields of the command header through offsets to
the raw buffer, it is a better idea to use the header struct pointer
that is already used elsewhere in the function.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Declare struct tpm_header that replaces struct tpm_input_header and
struct tpm_output_header.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
The error logging for tpm2_commit_space() is in a wrong place. This
commit moves it inside that function.
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Do not print partial list of PCRs when tpm1_pcr_read() fails but instead
return 0 from pcrs_show(). This is consistent behavior with other sysfs
functions.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Return zero when tpm_buf_init() fails as we do for other functions in
tpm-sysfs.c.
Fixes: da379f3c1d ("tpm: migrate pubek_show to struct tpm_buf")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Since we pass an initialized struct tpm_buf instance in every call site
now, it is cleaner to pass that directly to the tpm_transmit_cmd() as
the TPM command/response buffer.
Fine-tune a little bit tpm_transmit() and tpm_transmit_cmd() comments
while doing this.
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Set tpm_chip->timeouts_adjusted directly in the update_timeouts
code instead of returning bool. In case of tpm read failing
print warning that the read failed and continue on.
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Currently tpm_transmit_cmd will print an error message if the tpm
returns something other than TPM2_RC_SUCCESS. This means that if the
tpm returns that it is testing an error message will be printed, and
this can cause confusion for the end user. So avoid printing the error
message if TPM2_RC_TESTING is the return code.
Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
TCG defines two structures, TCG_EfiSpecIDEventStruct and TCG_PCR_EVENT2,
which contain variable-sized arrays in the middle of the definition.
Since these structures are not suitable for type casting, this patch
removes structure members after the variable-sized arrays and adds the
_head suffix to the structure name, to indicate that the renamed structures
do not contain all fields defined by TCG.
Lastly, given that variable-sized arrays are now in the last position, and
given that the size of the arrays cannot be determined in advance, this
patch also sets the size of those arrays to zero and removes the definition
of TPM2_ACTIVE_PCR_BANKS.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Nayna Jain <nayna@linux.ibm.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
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: 55a82ab318 ("tpm: add bios measurement log")
Signed-off-by: Jia Zhang <zhang.jia@linux.alibaba.com>
Reviewd-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
The responsibility of tpm1_bios_measurements_start() is to walk over the
first *pos measurements, ensuring the skipped and to-be-read
measurements are not out-of-boundary.
This commit simplifies the loop by employing a do-while loop with
the necessary sanity check.
Signed-off-by: Jia Zhang <zhang.jia@linux.alibaba.com>
Reviewd-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Return -E2BIG when the transfer is incomplete. The upper layer does
not retry, so not doing that is incorrect behaviour.
Cc: stable@vger.kernel.org
Fixes: a2871c62e1 ("tpm: Add support for Atmel I2C TPMs")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
The send() callback should never return length as it does not in every
driver except tpm_crb in the success case. The reason is that the main
transmit functionality only cares about whether the transmit was
successful or not and ignores the count completely.
Suggested-by: Stefan Berger <stefanb@linux.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Tested-by: Alexander Steffen <Alexander.Steffen@infineon.com>
Use guid_copy() instead of memcpy() to hide guid_t implementation details and
to show we expect guid_t in a raw buffer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Instead of magic number use pre-defined constant for UUID binary and
string representations.
While here, drop the implementation details of guid_t type.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[Also converted a "17" in the error string to UUID_SIZE + 1]
Signed-off-by: Corey Minyard <cminyard@mvista.com>
devm_kasprintf() may return NULL if internal allocation failed so this
assignment is not safe. Moved the error exit path and added the !NULL
which then allows the devres manager to take care of cleanup.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes: cd2315d471 ("ipmi: kcs_bmc: don't change device name")
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
The user can ask the message to be returned even if it didn't supply
enough memory for the data, and it will return an error but still
fills in as much data as possible. However, the return value
wasn't being set to an error, it was being overwritten. Create a
second return value for that case.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Trivial fix to clean up an indentation issue, remove space
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The code to tell the lower layer to enable or disable watching for
certain things was lazy in disabling, it waited until a timer tick
to see if a disable was necessary. Not a really big deal, but it
could be improved.
Modify the code to enable and disable watching immediately and don't
do it from the background timer any more.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: Kamlakant Patel <kamlakant.patel@cavium.com>
The IPMI driver has a mechanism to tell the lower layers it needs
to watch for messages, commands, and watchdogs (so it doesn't
needlessly poll). However, it needed some extensions, it needed
a way to tell what is being waited for so it could set the timeout
appropriately.
The update to the lower layer was also being done once a second
at best because it was done in the main timeout handler. However,
if a command is sent and a response message is coming back,
it needed to be started immediately. So modify the code to
update immediately if it needs to be enabled. Disable is still
lazy.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: Kamlakant Patel <kamlakant.patel@cavium.com>
Commit 89986496de ("ipmi: Turn off all activity on an idle ipmi
interface") modified the IPMI code to only request events when the
driver had somethine waiting for events. The SSIF code, however,
was using the event fetch request to also fetch the flags.
Add a timer and the proper handling for the upper layer telling
whether flags fetches are required.
Reported-by: Kamlakant Patel <Kamlakant.Patel@cavium.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: Kamlakant Patel <kamlakant.patel@cavium.com>
* Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to
ST33ZP24_BUFSIZE.
* Rename TPM_BUFSIZE defined in drivers/char/tpm/tpm_i2c_infineon.c to
TPM_I2C_INFINEON_BUFSIZE.
* Rename TPM_RETRY in tpm_i2c_nuvoton to TPM_I2C_RETRIES.
* Remove TPM_HEADER_SIZE from tpm_i2c_nuvoton.
Cc: stable@vger.kernel.org
Fixes: bf38b87108 ("tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy)")
Fixes: aad628c1d9 ("char/tpm: Add new driver for Infineon I2C TIS TPM")
Fixes: 32d33b29ba ("TPM: Retry SaveState command in suspend path")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
The current approach to read first 6 bytes from the response and then tail
of the response, can cause the 2nd memcpy_fromio() to do an unaligned read
(e.g. read 32-bit word from address aligned to a 16-bits), depending on how
memcpy_fromio() is implemented. If this happens, the read will fail and the
memory controller will fill the read with 1's.
This was triggered by 170d13ca3a, which should be probably refined to
check and react to the address alignment. Before that commit, on x86
memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
thing (from tpm_crb's perspective) for us so far, but we should not rely on
that. Thus, it makes sense to fix this also in tpm_crb, not least because
the fix can be then backported to stable kernels and make them more robust
when compiled in differing environments.
Cc: stable@vger.kernel.org
Cc: James Morris <jmorris@namei.org>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Jerry Snitselaar <jsnitsel@redhat.com>
Fixes: 30fc8d138e ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
On ARM SoC's with TrustZone enabled, peripherals like entropy sources
might not be accessible to normal world (linux in this case) and rather
accessible to secure world (OP-TEE in this case) only. So this driver
aims to provides a generic interface to OP-TEE based random number
generator service.
This driver registers on TEE bus to interact with OP-TEE based rng
device/service.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Here are some small char and misc driver fixes to resolve some reported
issues, as well as a number of binderfs fixups that were found after
auditing the filesystem code by Al Viro. As binderfs hasn't been in a
previous release yet, it's good to get these in now before the first
users show up.
All of these have been in linux-next for a bit with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXEr/Iw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymLqACgsYcCs0r/RMqXfvMqJ7beUGq02ioAoNPD0hQh
Z76nfI+21TiuXx24JCfZ
=Fo1U
-----END PGP SIGNATURE-----
Merge tag 'char-misc-5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are some small char and misc driver fixes to resolve some
reported issues, as well as a number of binderfs fixups that were
found after auditing the filesystem code by Al Viro. As binderfs
hasn't been in a previous release yet, it's good to get these in now
before the first users show up.
All of these have been in linux-next for a bit with no reported
issues"
* tag 'char-misc-5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (26 commits)
i3c: master: Fix an error checking typo in 'cdns_i3c_master_probe()'
binderfs: switch from d_add() to d_instantiate()
binderfs: drop lock in binderfs_binder_ctl_create
binderfs: kill_litter_super() before cleanup
binderfs: rework binderfs_binder_device_create()
binderfs: rework binderfs_fill_super()
binderfs: prevent renaming the control dentry
binderfs: remove outdated comment
binderfs: use __u32 for device numbers
binderfs: use correct include guards in header
misc: pvpanic: fix warning implicit declaration
char/mwave: fix potential Spectre v1 vulnerability
misc: ibmvsm: Fix potential NULL pointer dereference
binderfs: fix error return code in binderfs_fill_super()
mei: me: add denverton innovation engine device IDs
mei: me: mark LBG devices as having dma support
mei: dma: silent the reject message
binderfs: handle !CONFIG_IPC_NS builds
binderfs: reserve devices for initial mount
binderfs: rename header to binderfs.h
...
The virtio-rng driver uses a completion called have_data to wait for a
virtio read to be fulfilled by the hypervisor. The completion is reset
before placing a buffer on the virtio queue and completed by the virtio
callback once data has been written into the buffer.
Prior to this commit, the driver called init_completion on this
completion both during probe as well as when registering virtio buffers
as part of a hwrng read operation. The second of these init_completion
calls should instead be reinit_completion because the have_data
completion has already been inited by probe. As described in
Documentation/scheduler/completion.txt, "Calling init_completion() twice
on the same completion object is most likely a bug".
This bug was present in the initial implementation of virtio-rng in
f7f510ec19 ("virtio: An entropy device, as suggested by hpa"). Back
then the have_data completion was a single static completion rather than
a member of one of potentially multiple virtrng_info structs as
implemented later by 08e53fbdb8 ("virtio-rng: support multiple
virtio-rng devices"). The original driver incorrectly used
init_completion rather than INIT_COMPLETION to reset have_data during
read.
Tested by running `head -c48 /dev/random | hexdump` within crosvm, the
Chrome OS virtual machine monitor, and confirming that the virtio-rng
driver successfully produces random bytes from the host.
Signed-off-by: David Tolnay <dtolnay@gmail.com>
Tested-by: David Tolnay <dtolnay@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The IPMI driver was recently modified to use SRCU, but it turns out
this uses a chunk of percpu memory, even if IPMI is never used.
So modify thing to on initialize on the first use. There was already
code to sort of handle this for handling init races, so piggy back
on top of that, and simplify it in the process.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Reported-by: Tejun Heo <tj@kernel.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # 4.18
Some IPMI modules (e.g. ibmpex_msg_handler()) will have ipmi_usr_hdlr
handlers that call ipmi_free_recv_msg() directly. This will essentially
kfree(msg), leading to use-after-free.
This does not happen in the ipmi_devintf module, which will queue the
message and run ipmi_free_recv_msg() later.
BUG: KASAN: use-after-free in deliver_response+0x12f/0x1b0
Read of size 8 at addr ffff888a7bf20018 by task ksoftirqd/3/27
CPU: 3 PID: 27 Comm: ksoftirqd/3 Tainted: G O 4.19.11-amd64-ani99-debug #12.0.1.601133+pv
Hardware name: AppNeta r1000/X11SPW-TF, BIOS 2.1a-AP 09/17/2018
Call Trace:
dump_stack+0x92/0xeb
print_address_description+0x73/0x290
kasan_report+0x258/0x380
deliver_response+0x12f/0x1b0
? ipmi_free_recv_msg+0x50/0x50
deliver_local_response+0xe/0x50
handle_one_recv_msg+0x37a/0x21d0
handle_new_recv_msgs+0x1ce/0x440
...
Allocated by task 9885:
kasan_kmalloc+0xa0/0xd0
kmem_cache_alloc_trace+0x116/0x290
ipmi_alloc_recv_msg+0x28/0x70
i_ipmi_request+0xb4a/0x1640
ipmi_request_settime+0x1b8/0x1e0
...
Freed by task 27:
__kasan_slab_free+0x12e/0x180
kfree+0xe9/0x280
deliver_response+0x122/0x1b0
deliver_local_response+0xe/0x50
handle_one_recv_msg+0x37a/0x21d0
handle_new_recv_msgs+0x1ce/0x440
tasklet_action_common.isra.19+0xc4/0x250
__do_softirq+0x11f/0x51f
Fixes: e86ee2d44b ("ipmi: Rework locking and shutdown for hot remove")
Cc: stable@vger.kernel.org # 4.18
Signed-off-by: Fred Klassen <fklassen@appneta.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
channel and addr->channel are indirectly controlled by user-space,
hence leading to a potential exploitation of the Spectre variant 1
vulnerability.
These issues were detected with the help of Smatch:
drivers/char/ipmi/ipmi_msghandler.c:1381 ipmi_set_my_address() warn: potential spectre issue 'user->intf->addrinfo' [w] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:1401 ipmi_get_my_address() warn: potential spectre issue 'user->intf->addrinfo' [r] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:1421 ipmi_set_my_LUN() warn: potential spectre issue 'user->intf->addrinfo' [w] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:1441 ipmi_get_my_LUN() warn: potential spectre issue 'user->intf->addrinfo' [r] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:2260 check_addr() warn: potential spectre issue 'intf->addrinfo' [r] (local cap)
Fix this by sanitizing channel and addr->channel before using them to
index user->intf->addrinfo and intf->addrinfo, correspondingly.
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/
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The block number was not being compared right, it was off by one
when checking the response.
Some statistics wouldn't be incremented properly in some cases.
Check to see if that middle-part messages always have 31 bytes of
data.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Cc: stable@vger.kernel.org # 4.4
Without ".owner = THIS_MODULE" it is possible to crash the kernel
by unloading the mbcs module while someone works with the file.
Fix this by initializing the ‘struct file_operations' ->owner with
THIS_MODULE.
Signed-off-by: Naveen Kumar Parna <parna.naveenkumar@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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/
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit '3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for
user processes")' introduced a new kernel command line parameter hpet_mmap,
that is required to expose the memory map of the HPET registers to
user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is
broken and never takes effect due to missing '=' character in the __setup()
code of hpet_mmap_enable.
Before this patch:
dmesg output with the kernel command line parameter hpet_mmap=1
[ 0.204152] HPET mmap disabled
dmesg output with the kernel command line parameter hpet_mmap=0
[ 0.204192] HPET mmap disabled
After this patch:
dmesg output with the kernel command line parameter hpet_mmap=1
[ 0.203945] HPET mmap enabled
dmesg output with the kernel command line parameter hpet_mmap=0
[ 0.204652] HPET mmap disabled
Fixes: 3d035f5806 ("drivers/char/hpet.c: allow user controlled mmap for user processes")
Signed-off-by: Buland Singh <bsingh@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no advantage to keep 'struct file_operations.open & .close'
API's. So removed the unnecessary code efi_rtc_open & efi_rtc_close.
Signed-off-by: Naveen Kumar Parna <parna.naveenkumar@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adopt nvram module to reduce code duplication. This means CONFIG_NVRAM
becomes available to PPC64 builds. Previously it was only available to
PPC32 builds because it depended on CONFIG_GENERIC_NVRAM.
The IOC_NVRAM_GET_OFFSET ioctl as implemented on PPC64 validates the
offset returned by pmac_get_partition(). Do the same in the nvram module.
Note that the old PPC32 generic_nvram module lacked this test.
So when CONFIG_PPC32 && CONFIG_PPC_PMAC, the IOC_NVRAM_GET_OFFSET ioctl
would have returned 0 (always). But when CONFIG_PPC64 && CONFIG_PPC_PMAC,
the IOC_NVRAM_GET_OFFSET ioctl would have returned -1 (which is -EPERM)
when the requested partition was not found.
With this patch, the result is now -EINVAL on both PPC32 and PPC64 when
the requested PowerMac NVRAM partition is not found. This is a userspace-
visible change, in the non-existent partition case, which would be in
an error path for an IOC_NVRAM_GET_OFFSET ioctl syscall.
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Switch PPC32 kernels from the generic_nvram module to the nvram module.
Also fix a theoretical bug where CHRP omits the chrp_nvram_init() call
when CONFIG_NVRAM_MODULE=m.
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the powerpc-specific ioctls to the nvram module. This allows the nvram
module to replace the generic_nvram module.
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
