kernel/git/stable/linux-stable.git/drivers/s390/crypto, branch linux-6.5.y

s390/ap: fix AP bus crash on early config change callback invocation

2023-11-28T17:15:12+00:00

commit e14aec23025eeb1f2159ba34dbc1458467c4c347 upstream. Fix kernel crash in AP bus code caused by very early invocation of the config change callback function via SCLP. After a fresh IML of the machine the crypto cards are still offline and will get switched online only with activation of any LPAR which has the card in it's configuration. A crypto card coming online is reported to the LPAR via SCLP and the AP bus offers a callback function to get this kind of information. However, it may happen that the callback is invoked before the AP bus init function is complete. As the callback triggers a synchronous AP bus scan, the scan may already run but some internal states are not initialized by the AP bus init function resulting in a crash like this: [ 11.635859] Unable to handle kernel pointer dereference in virtual kernel address space [ 11.635861] Failing address: 0000000000000000 TEID: 0000000000000887 [ 11.635862] Fault in home space mode while using kernel ASCE. [ 11.635864] AS:00000000894c4007 R3:00000001fece8007 S:00000001fece7800 P:000000000000013d [ 11.635879] Oops: 0004 ilc:1 [#1] SMP [ 11.635882] Modules linked in: [ 11.635884] CPU: 5 PID: 42 Comm: kworker/5:0 Not tainted 6.6.0-rc3-00003-g4dbf7cdc6b42 #12 [ 11.635886] Hardware name: IBM 3931 A01 751 (LPAR) [ 11.635887] Workqueue: events_long ap_scan_bus [ 11.635891] Krnl PSW : 0704c00180000000 0000000000000000 (0x0) [ 11.635895] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 [ 11.635897] Krnl GPRS: 0000000001000a00 0000000000000000 0000000000000006 0000000089591940 [ 11.635899] 0000000080000000 0000000000000a00 0000000000000000 0000000000000000 [ 11.635901] 0000000081870c00 0000000089591000 000000008834e4e2 0000000002625a00 [ 11.635903] 0000000081734200 0000038000913c18 000000008834c6d6 0000038000913ac8 [ 11.635906] Krnl Code:>0000000000000000: 0000 illegal [ 11.635906] 0000000000000002: 0000 illegal [ 11.635906] 0000000000000004: 0000 illegal [ 11.635906] 0000000000000006: 0000 illegal [ 11.635906] 0000000000000008: 0000 illegal [ 11.635906] 000000000000000a: 0000 illegal [ 11.635906] 000000000000000c: 0000 illegal [ 11.635906] 000000000000000e: 0000 illegal [ 11.635915] Call Trace: [ 11.635916] [<0000000000000000>] 0x0 [ 11.635918] [<000000008834e4e2>] ap_queue_init_state+0x82/0xb8 [ 11.635921] [<000000008834ba1c>] ap_scan_domains+0x6fc/0x740 [ 11.635923] [<000000008834c092>] ap_scan_adapter+0x632/0x8b0 [ 11.635925] [<000000008834c3e4>] ap_scan_bus+0xd4/0x288 [ 11.635927] [<00000000879a33ba>] process_one_work+0x19a/0x410 [ 11.635930] Discipline DIAG cannot be used without z/VM [ 11.635930] [<00000000879a3a2c>] worker_thread+0x3fc/0x560 [ 11.635933] [<00000000879aea60>] kthread+0x120/0x128 [ 11.635936] [<000000008792afa4>] __ret_from_fork+0x3c/0x58 [ 11.635938] [<00000000885ebe62>] ret_from_fork+0xa/0x30 [ 11.635942] Last Breaking-Event-Address: [ 11.635942] [<000000008834c6d4>] ap_wait+0xcc/0x148 This patch improves the ap_bus_force_rescan() function which is invoked by the config change callback by checking if a first initial AP bus scan has been done. If not, the force rescan request is simple ignored. Anyhow it does not make sense to trigger AP bus re-scans even before the very first bus scan is complete. Cc: stable@vger.kernel.org Reviewed-by: Holger Dengler Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman

s390/ap: re-init AP queues on config on

2023-11-20T10:57:16+00:00

[ Upstream commit 32d1d9204f8db3360be55e65bd182a1a68f93308 ] On a state toggle from config off to config on and on the state toggle from checkstop to not checkstop the queue's internal states was set but the state machine was not nudged. This did not care as on the first enqueue of a request the state machine kick ran. However, within an Secure Execution guest a queue is only chosen by the scheduler when it has been bound. But to bind a queue, it needs to run through the initial states (reset, enable interrupts, ...). So this is like a chicken-and-egg problem and the result was in fact that a queue was unusable after a config off/on toggle. With some slight rework of the handling of these states now the new function _ap_queue_init_state() is called which is the core of the ap_queue_init_state() function but without locking handling. This has the benefit that it can be called on all the places where a (re-)init of the AP queue's state machine is needed. Fixes: 2d72eaf036d2 ("s390/ap: implement SE AP bind, unbind and associate") Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

s390/zcrypt: don't leak memory if dev_set_name() fails

2023-09-19T10:30:19+00:00

[ Upstream commit 6252f47b78031979ad919f971dc8468b893488bd ] When dev_set_name() fails, zcdn_create() doesn't free the newly allocated resources. Do it. Fixes: 00fab2350e6b ("s390/zcrypt: multiple zcrypt device nodes support") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230831110000.24279-1-andriy.shevchenko@linux.intel.com Signed-off-by: Harald Freudenberger Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390/pkey: fix PKEY_TYPE_EP11_AES handling for sysfs attributes

2023-09-13T07:53:00+00:00

[ Upstream commit b9352e4b9b9eff949bcc6907b8569b3a1d992f1e ] Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced a new PKEY_TYPE_EP11_AES securekey type as a supplement to the existing PKEY_TYPE_EP11 (which won't work in environments with session-bound keys). The pkey EP11 securekey attributes use PKEY_TYPE_EP11_AES (instead of PKEY_TYPE_EP11) keyblobs, to make the generated keyblobs usable also in environments, where session-bound keys are required. There should be no negative impacts to userspace because the internal structure of the keyblobs is opaque. The increased size of the generated keyblobs is reflected by the changed size of the attributes. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_VERIFYKEY2 IOCTL

2023-09-13T07:53:00+00:00

[ Upstream commit 745742dbca11a1b63684ec7032a81aaedcf51fb0 ] Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced a new PKEY_TYPE_EP11_AES type for the PKEY_VERIFYKEY2 IOCTL to verify keyblobs of this type. Unfortunately, all PKEY_VERIFYKEY2 IOCTL requests with keyblobs of this type return with an error (-EINVAL). Fix PKEY_TYPE_EP11_AES handling in PKEY_VERIFYKEY2 IOCTL, so that userspace can verify keyblobs of this type. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_KBLOB2PROTK[23]

2023-09-13T07:53:00+00:00

[ Upstream commit d1fdfb0b2f339cf882c0b5431084a1950b8b73b9 ] Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced a new PKEY_TYPE_EP11_AES type for the PKEY_KBLOB2PROTK2 and a new IOCTL, PKEY_KBLOB2PROTK3, which both allows userspace to convert opaque securekey blobs of this type into protectedkey blobs. Unfortunately, all PKEY_KBLOB2PROTK2 and PKEY_KBLOB2PROTK3 IOCTL requests with this keyblobs of this type return with an error (-EINVAL). Fix PKEY_TYPE_EP11_AES handling in PKEY_KBLOB2PROTK2 and PKEY_KBLOB2PROTK3 IOCTLs, so that userspace can convert PKEY_TYPE_EP11_AES keyblobs into protectedkey blobs. Add a helper function to decode the start and size of the internal header as well as start and size of the keyblob payload of an existing keyblob. Also validate the length of header and keyblob, as well as the keyblob magic. Introduce another helper function, which handles a raw key wrapping request and do the keyblob decoding in the calling function. Remove all other header-related calculations. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_CLR2SECK2 IOCTL

2023-09-13T07:53:00+00:00

[ Upstream commit da2863f15945de100b95c72d5656541d30956c5d ] Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced PKEY_TYPE_EP11_AES for the PKEY_CLR2SECK2 IOCTL to convert an AES clearkey into a securekey of this type. Unfortunately, all PKEY_CLR2SECK2 IOCTL requests with type PKEY_TYPE_EP11_AES return with an error (-EINVAL). Fix the handling for PKEY_TYPE_EP11_AES in PKEY_CLR2SECK2 IOCTL, so that userspace can convert clearkey blobs into PKEY_TYPE_EP11_AES securekey blobs. Cc: stable@vger.kernel.org # v5.10+ Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens Stable-dep-of: d1fdfb0b2f33 ("s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_KBLOB2PROTK[23]") Signed-off-by: Sasha Levin

s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_GENSECK2 IOCTL

2023-09-13T07:53:00+00:00

[ Upstream commit fb249ce7f7bfd8621a38e4ad401ba74b680786d4 ] Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced PKEY_TYPE_EP11_AES for the PKEY_GENSECK2 IOCTL, to enable userspace to generate securekey blobs of this type. Unfortunately, all PKEY_GENSECK2 IOCTL requests for PKEY_TYPE_EP11_AES return with an error (-EINVAL). Fix the handling for PKEY_TYPE_EP11_AES in PKEY_GENSECK2 IOCTL, so that userspace can generate securekey blobs of this type. The start of the header and the keyblob, as well as the length need special handling, depending on the internal keyversion. Add a helper function that splits an uninitialized buffer into start and size of the header as well as start and size of the payload, depending on the requested keyversion. Do the header-related calculations and the raw genkey request handling in separate functions. Use the raw genkey request function for internal purposes. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390/pkey: fix/harmonize internal keyblob headers

2023-09-13T07:53:00+00:00

[ Upstream commit 37a08f010b7c423b5e4c9ed3b187d21166553007 ] Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced PKEY_TYPE_EP11_AES as a supplement to PKEY_TYPE_EP11. All pkeys have an internal header/payload structure, which is opaque to the userspace. The header structures for PKEY_TYPE_EP11 and PKEY_TYPE_EP11_AES are nearly identical and there is no reason, why different structures are used. In preparation to fix the keyversion handling in the broken PKEY IOCTLs, the same header structure is used for PKEY_TYPE_EP11 and PKEY_TYPE_EP11_AES. This reduces the number of different code paths and increases the readability. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin

s390/zcrypt: fix reply buffer calculations for CCA replies

2023-07-20T14:48:56+00:00

The length information for available buffer space for CCA replies is covered with two fields in the T6 header prepended on each CCA reply: fromcardlen1 and fromcardlen2. The sum of these both values must not exceed the AP bus limit for this card (24KB for CEX8, 12KB CEX7 and older) minus the always present headers. The current code adjusted the fromcardlen2 value in case of exceeding the AP bus limit when there was a non-zero value given from userspace. Some tests now showed that this was the wrong assumption. Instead the userspace value given for this field should always be trusted and if the sum of the two fields exceeds the AP bus limit for this card the first field fromcardlen1 should be adjusted instead. So now the calculation is done with this new insight in mind. Also some additional checks for overflow have been introduced and some comments to provide some documentation for future maintainers of this complicated calculation code. Furthermore the 128 bytes of fix overhead which is used in the current code is not correct. Investigations showed that for a reply always the same two header structs are prepended before a possible payload. So this is also fixed with this patch. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens