summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-08-18s390/vfio-ap: no need to check the 'E' and 'I' bits in APQSW after TAPQTony Krowiak
After a ZAPQ is executed to reset a queue, if the queue is not empty or interrupts are still enabled, the vfio_ap driver will wait for the reset operation to complete by repeatedly executing the TAPQ instruction and checking the 'E' and 'I' bits in the APQSW to verify that the queue is empty and interrupts are disabled. This is unnecessary because it is sufficient to check only the response code in the APQSW. If the reset is still in progress, the response code will be 02; however, if the reset has completed successfully, the response code will be 00. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Tested-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Link: https://lore.kernel.org/r/20230815184333.6554-2-akrowiak@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/ipl: refactor deprecated strncpyJustin Stitt
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. Use `strscpy` which has the same behavior as `strncpy` here with the extra safeguard of guaranteeing NUL-termination of destination strings. In it's current form, this may result in silent truncation if the src string has the same size as the destination string. [hca@linux.ibm.com: use strscpy() instead of strscpy_pad()] Link: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings[1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Link: https://lore.kernel.org/r/20230811-arch-s390-kernel-v1-1-7edbeeab3809@google.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/ipl: fix virtual vs physical address confusionAlexander Gordeev
The value of ipl_cert_list_addr boot variable contains a physical address, which is used directly. That works because virtual and physical address spaces are currently the same, but otherwise it is wrong. While at it, fix also a comment for the platform keyring. Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Link: https://lore.kernel.org/r/20230816132942.2540411-1-agordeev@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18s390/zcrypt_ep11misc: support API ordinal 6 with empty pin-blobHolger Dengler
Secure execution guest environments require an empty pinblob in all key generation and unwrap requests. Empty pinblobs are only available in EP11 API ordinal 6 or higher. Add an empty pinblob to key generation and unwrap requests, if the AP secure binding facility is available. In all other cases, stay with the empty pin tag (no pinblob) and the current API ordinals. The EP11 API ordinal also needs to be considered when the pkey module tries to figure out the list of eligible cards for key operations with protected keys in secure execution environment. These changes are transparent to userspace but required for running an secure execution guest with handling key generate and key derive (e.g. secure key to protected key) correct. Especially using EP11 secure keys with the kernel dm-crypt layer requires this patch. Co-developed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-08-18regulator: db8500-prcmu: Remove unused declaration ↵Yue Haibing
power_state_active_is_enabled() Commit 38e968380b27 ("regulators/db8500: split off shared dbx500 code") removed this but not its declaration. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20230818124227.15084-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-18btrfs: fix incorrect splitting in btrfs_drop_extent_map_rangeJosef Bacik
In production we were seeing a variety of WARN_ON()'s in the extent_map code, specifically in btrfs_drop_extent_map_range() when we have to call add_extent_mapping() for our second split. Consider the following extent map layout PINNED [0 16K) [32K, 48K) and then we call btrfs_drop_extent_map_range for [0, 36K), with skip_pinned == true. The initial loop will have start = 0 end = 36K len = 36K we will find the [0, 16k) extent, but since we are pinned we will skip it, which has this code start = em_end; if (end != (u64)-1) len = start + len - em_end; em_end here is 16K, so now the values are start = 16K len = 16K + 36K - 16K = 36K len should instead be 20K. This is a problem when we find the next extent at [32K, 48K), we need to split this extent to leave [36K, 48k), however the code for the split looks like this split->start = start + len; split->len = em_end - (start + len); In this case we have em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52K and now we have an invalid extent_map in the tree that potentially overlaps other entries in the extent map. Even in the non-overlapping case we will have split->start set improperly, which will cause problems with any block related calculations. We don't actually need len in this loop, we can simply use end as our end point, and only adjust start up when we find a pinned extent we need to skip. Adjust the logic to do this, which keeps us from inserting an invalid extent map. We only skip_pinned in the relocation case, so this is relatively rare, except in the case where you are running relocation a lot, which can happen with auto relocation on. Fixes: 55ef68990029 ("Btrfs: Fix btrfs_drop_extent_cache for skip pinned case") CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: David Sterba <dsterba@suse.com>
2023-08-18x86/MCE: Always save CS register on AMD Zen IF Poison errorsYazen Ghannam
The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed. There is no architecturally-defined method to determine this behavior. The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV]. Add a quirk to save the CS register for poison consumption from the IF unit banks. This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230814200853.29258-1-yazen.ghannam@amd.com
2023-08-18pinctrl: renesas: rza2: Add lock around ↵Biju Das
pinctrl_generic{{add,remove}_group,{add,remove}_function} The pinctrl group and function creation/remove calls expect caller to take care of locking. Add lock around these functions. Fixes: b59d0e782706 ("pinctrl: Add RZ/A2 pin and gpio controller") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230815131558.33787-4-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2023-08-18pinctrl: renesas: rzv2m: Fix NULL pointer dereference in ↵Biju Das
rzv2m_dt_subnode_to_map() Fix the below random NULL pointer crash during boot by serializing pinctrl group and function creation/remove calls in rzv2m_dt_subnode_to_map() with mutex lock. Crash logs: pc : __pi_strcmp+0x20/0x140 lr : pinmux_func_name_to_selector+0x68/0xa4 Call trace: __pi_strcmp+0x20/0x140 pinmux_generic_add_function+0x34/0xcc rzv2m_dt_subnode_to_map+0x2e4/0x418 rzv2m_dt_node_to_map+0x15c/0x18c pinctrl_dt_to_map+0x218/0x37c create_pinctrl+0x70/0x3d8 While at it, add a comment for lock. Fixes: 92a9b8252576 ("pinctrl: renesas: Add RZ/V2M pin and gpio controller driver") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230815131558.33787-3-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2023-08-18pinctrl: renesas: rzg2l: Fix NULL pointer dereference in ↵Biju Das
rzg2l_dt_subnode_to_map() Fix the below random NULL pointer crash during boot by serializing pinctrl group and function creation/remove calls in rzg2l_dt_subnode_to_map() with mutex lock. Crash log: pc : __pi_strcmp+0x20/0x140 lr : pinmux_func_name_to_selector+0x68/0xa4 Call trace: __pi_strcmp+0x20/0x140 pinmux_generic_add_function+0x34/0xcc rzg2l_dt_subnode_to_map+0x314/0x44c rzg2l_dt_node_to_map+0x164/0x194 pinctrl_dt_to_map+0x218/0x37c create_pinctrl+0x70/0x3d8 While at it, add comments for bitmap_lock and lock. Fixes: c4c4637eb57f ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver") Tested-by: Chris Paterson <Chris.Paterson2@renesas.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230815131558.33787-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2023-08-18x86/srso: Correct the mitigation status when SMT is disabledBorislav Petkov (AMD)
Specify how is SRSO mitigated when SMT is disabled. Also, correct the SMT check for that. Fixes: e9fbc47b818b ("x86/srso: Disable the mitigation on unaffected configurations") Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/20230814200813.p5czl47zssuej7nv@treble
2023-08-18crypto: fix uninit-value in af_alg_free_resourcesPavel Skripkin
Syzbot was able to trigger use of uninitialized memory in af_alg_free_resources. Bug is caused by missing initialization of rsgl->sgl.need_unpin before adding to rsgl_list. Then in case of extract_iter_to_sg() failure, rsgl is left with uninitialized need_unpin which is read during clean up BUG: KMSAN: uninit-value in af_alg_free_sg crypto/af_alg.c:545 [inline] BUG: KMSAN: uninit-value in af_alg_free_areq_sgls crypto/af_alg.c:778 [inline] BUG: KMSAN: uninit-value in af_alg_free_resources+0x3d1/0xf60 crypto/af_alg.c:1117 af_alg_free_sg crypto/af_alg.c:545 [inline] af_alg_free_areq_sgls crypto/af_alg.c:778 [inline] af_alg_free_resources+0x3d1/0xf60 crypto/af_alg.c:1117 _skcipher_recvmsg crypto/algif_skcipher.c:144 [inline] ... Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3470 [inline] __kmem_cache_alloc_node+0x536/0x8d0 mm/slub.c:3509 __do_kmalloc_node mm/slab_common.c:984 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:998 kmalloc include/linux/slab.h:586 [inline] sock_kmalloc+0x128/0x1c0 net/core/sock.c:2683 af_alg_alloc_areq+0x41/0x2a0 crypto/af_alg.c:1188 _skcipher_recvmsg crypto/algif_skcipher.c:71 [inline] Fixes: c1abe6f570af ("crypto: af_alg: Use extract_iter_to_sg() to create scatterlists") Reported-and-tested-by: syzbot+cba21d50095623218389@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=cba21d50095623218389 Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18mmc: sdhci-esdhc-imx: improve ESDHC_FLAG_ERR010450Giulio Benetti
Errata ERR010450 only shows up if voltage is 1.8V, but if the device is supplied by 3v3 the errata can be ignored. So let's check for if quirk SDHCI_QUIRK2_NO_1_8_V is defined or not before limiting the frequency. Cc: Jim Reinhart <jimr@tekvox.com> Cc: James Autry <jautry@tekvox.com> Cc: Matthew Maron <matthewm@tekvox.com> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com> Acked-by: Haibo Chen <haibo.chen@nxp.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20230811214853.8623-1-giulio.benetti@benettiengineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-08-18crypto: engine - Remove crypto_engine_ctxHerbert Xu
Remove the obsolete crypto_engine_ctx structure. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: zynqmp - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: virtio - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: stm32 - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: jh7110 - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: rk3288 - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: omap - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: keembay - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: sl3516 - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: caam - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: aspeed - Remove non-standard sha512 algorithmsHerbert Xu
Algorithms must never be added to a driver unless there is a generic implementation. These truncated versions of sha512 slipped through. Remove them as they are useless. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: aspeed - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: amlogic - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: sun8i-ss - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: sun8i-ce - Use new crypto_engine_op interfaceHerbert Xu
Use the new crypto_engine_op interface where the callback is stored in the algorithm object. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: engine - Move crypto_engine_ops from request into crypto_algHerbert Xu
Rather than having the callback in the request, move it into the crypto_alg object. This avoids having crypto_engine look into the request context is private to the driver. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: engine - Move struct crypto_engine into internal/engine.hHerbert Xu
Most drivers should not access the internal details of struct crypto_engine. Move it into the internal header file. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: caam - Include internal/engine.hHerbert Xu
Inlucde internal/engine.h because this driver uses directly accesses attributes inside struct crypto_engine. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: omap - Include internal/engine.hHerbert Xu
Inlucde internal/engine.h because this driver uses directly accesses attributes inside struct crypto_engine. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: engine - Create internal/engine.hHerbert Xu
Create crypto/internal/engine.h to house details that should not be used by drivers. It is empty for the time being. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: jh7110 - Include scatterwalk.h for struct scatter_walkHerbert Xu
Include crypto/scatterwalk.h explicitly instead of getting it through random header files. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: engine - Move crypto inclusions out of header fileHerbert Xu
The engine file does not need the actual crypto type definitions so move those header inclusions to where they are actually used. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: jh7110 - Include crypto/hash.h in header fileHerbert Xu
The header file jh7110-cryp uses ahash_request without including crypto/hash.h. Fix that by adding the inclusion. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: engine - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: zynqmp - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: virtio - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: stm32 - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: jh1100 - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: rk3288 - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: omap - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: keembay - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: sl3516 - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: aspeed - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: amlogic - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: sun8i-ss - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: sun8i-ce - Remove prepare/unprepare requestHerbert Xu
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request. Move the code into do_one_request and remove the unused callbacks. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2023-08-18crypto: qcom-rng: Make the core clock optional regardless of ACPI presenceKonrad Dybcio
Some newer SoCs (like SM8450) do not require a clock vote for the PRNG to function. Make it entirely optional and rely on the bindings checker to ensure platforms that need it, consume one. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>