From: Greg Kroah-Hartman Date: Fri, 29 Mar 2024 09:24:03 +0000 (+0100) Subject: 6.1-stable patches X-Git-Tag: v6.7.12~187 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=97b4c913b000503ee7a380a69e315d470a113a08;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: net-tls-handle-backlogging-of-crypto-requests.patch x86-efistub-call-mixed-mode-boot-services-on-the-firmware-s-stack.patch --- diff --git a/queue-6.1/net-tls-handle-backlogging-of-crypto-requests.patch b/queue-6.1/net-tls-handle-backlogging-of-crypto-requests.patch new file mode 100644 index 00000000000..1d798ffb4f5 --- /dev/null +++ b/queue-6.1/net-tls-handle-backlogging-of-crypto-requests.patch @@ -0,0 +1,91 @@ +From 8590541473188741055d27b955db0777569438e3 Mon Sep 17 00:00:00 2001 +From: Jakub Kicinski +Date: Tue, 6 Feb 2024 17:18:21 -0800 +Subject: net: tls: handle backlogging of crypto requests + +From: Jakub Kicinski + +commit 8590541473188741055d27b955db0777569438e3 upstream. + +Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our +requests to the crypto API, crypto_aead_{encrypt,decrypt} can return + -EBUSY instead of -EINPROGRESS in valid situations. For example, when +the cryptd queue for AESNI is full (easy to trigger with an +artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued +to the backlog but still processed. In that case, the async callback +will also be called twice: first with err == -EINPROGRESS, which it +seems we can just ignore, then with err == 0. + +Compared to Sabrina's original patch this version uses the new +tls_*crypt_async_wait() helpers and converts the EBUSY to +EINPROGRESS to avoid having to modify all the error handling +paths. The handling is identical. + +Fixes: a54667f6728c ("tls: Add support for encryption using async offload accelerator") +Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls records") +Co-developed-by: Sabrina Dubroca +Signed-off-by: Sabrina Dubroca +Link: https://lore.kernel.org/netdev/9681d1febfec295449a62300938ed2ae66983f28.1694018970.git.sd@queasysnail.net/ +Signed-off-by: Jakub Kicinski +Reviewed-by: Simon Horman +Signed-off-by: David S. Miller +[Srish: fixed merge-conflict in stable branch linux-6.1.y, +needs to go on top of https://lore.kernel.org/stable/20240307155930.913525-1-lee@kernel.org/] +Signed-off-by: Srish Srinivasan +Signed-off-by: Greg Kroah-Hartman +--- + net/tls/tls_sw.c | 22 ++++++++++++++++++++++ + 1 file changed, 22 insertions(+) + +--- a/net/tls/tls_sw.c ++++ b/net/tls/tls_sw.c +@@ -195,6 +195,17 @@ static void tls_decrypt_done(crypto_comp + struct sock *sk; + int aead_size; + ++ /* If requests get too backlogged crypto API returns -EBUSY and calls ++ * ->complete(-EINPROGRESS) immediately followed by ->complete(0) ++ * to make waiting for backlog to flush with crypto_wait_req() easier. ++ * First wait converts -EBUSY -> -EINPROGRESS, and the second one ++ * -EINPROGRESS -> 0. ++ * We have a single struct crypto_async_request per direction, this ++ * scheme doesn't help us, so just ignore the first ->complete(). ++ */ ++ if (err == -EINPROGRESS) ++ return; ++ + aead_size = sizeof(*aead_req) + crypto_aead_reqsize(aead); + aead_size = ALIGN(aead_size, __alignof__(*dctx)); + dctx = (void *)((u8 *)aead_req + aead_size); +@@ -268,6 +279,10 @@ static int tls_do_decryption(struct sock + } + + ret = crypto_aead_decrypt(aead_req); ++ if (ret == -EBUSY) { ++ ret = tls_decrypt_async_wait(ctx); ++ ret = ret ?: -EINPROGRESS; ++ } + if (ret == -EINPROGRESS) { + if (darg->async) + return 0; +@@ -451,6 +466,9 @@ static void tls_encrypt_done(crypto_comp + struct tls_rec *rec; + struct sock *sk; + ++ if (err == -EINPROGRESS) /* see the comment in tls_decrypt_done() */ ++ return; ++ + rec = container_of(aead_req, struct tls_rec, aead_req); + msg_en = &rec->msg_encrypted; + +@@ -556,6 +574,10 @@ static int tls_do_encryption(struct sock + atomic_inc(&ctx->encrypt_pending); + + rc = crypto_aead_encrypt(aead_req); ++ if (rc == -EBUSY) { ++ rc = tls_encrypt_async_wait(ctx); ++ rc = rc ?: -EINPROGRESS; ++ } + if (!rc || rc != -EINPROGRESS) { + atomic_dec(&ctx->encrypt_pending); + sge->offset -= prot->prepend_size; diff --git a/queue-6.1/series b/queue-6.1/series index 911664b2679..aedfd66d720 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -174,3 +174,5 @@ iio-accel-adxl367-fix-devid-read-after-reset.patch iio-accel-adxl367-fix-i2c-fifo-data-register.patch i2c-i801-avoid-potential-double-call-to-gpiod_remove_lookup_table.patch drm-amd-display-handle-range-offsets-in-vrr-ranges.patch +x86-efistub-call-mixed-mode-boot-services-on-the-firmware-s-stack.patch +net-tls-handle-backlogging-of-crypto-requests.patch diff --git a/queue-6.1/x86-efistub-call-mixed-mode-boot-services-on-the-firmware-s-stack.patch b/queue-6.1/x86-efistub-call-mixed-mode-boot-services-on-the-firmware-s-stack.patch new file mode 100644 index 00000000000..3dc19dd7ee3 --- /dev/null +++ b/queue-6.1/x86-efistub-call-mixed-mode-boot-services-on-the-firmware-s-stack.patch @@ -0,0 +1,77 @@ +From cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Fri, 22 Mar 2024 17:03:58 +0200 +Subject: x86/efistub: Call mixed mode boot services on the firmware's stack + +From: Ard Biesheuvel + +commit cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02 upstream. + +Normally, the EFI stub calls into the EFI boot services using the stack +that was live when the stub was entered. According to the UEFI spec, +this stack needs to be at least 128k in size - this might seem large but +all asynchronous processing and event handling in EFI runs from the same +stack and so quite a lot of space may be used in practice. + +In mixed mode, the situation is a bit different: the bootloader calls +the 32-bit EFI stub entry point, which calls the decompressor's 32-bit +entry point, where the boot stack is set up, using a fixed allocation +of 16k. This stack is still in use when the EFI stub is started in +64-bit mode, and so all calls back into the EFI firmware will be using +the decompressor's limited boot stack. + +Due to the placement of the boot stack right after the boot heap, any +stack overruns have gone unnoticed. However, commit + + 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") + +moved the definition of the boot heap into C code, and now the boot +stack is placed right at the base of BSS, where any overruns will +corrupt the end of the .data section. + +While it would be possible to work around this by increasing the size of +the boot stack, doing so would affect all x86 systems, and mixed mode +systems are a tiny (and shrinking) fraction of the x86 installed base. + +So instead, record the firmware stack pointer value when entering from +the 32-bit firmware, and switch to this stack every time a EFI boot +service call is made. + +Cc: # v6.1+ +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/boot/compressed/efi_mixed.S | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/arch/x86/boot/compressed/efi_mixed.S ++++ b/arch/x86/boot/compressed/efi_mixed.S +@@ -49,6 +49,11 @@ SYM_FUNC_START(startup_64_mixed_mode) + lea efi32_boot_args(%rip), %rdx + mov 0(%rdx), %edi + mov 4(%rdx), %esi ++ ++ /* Switch to the firmware's stack */ ++ movl efi32_boot_sp(%rip), %esp ++ andl $~7, %esp ++ + #ifdef CONFIG_EFI_HANDOVER_PROTOCOL + mov 8(%rdx), %edx // saved bootparams pointer + test %edx, %edx +@@ -260,6 +265,9 @@ SYM_FUNC_START_LOCAL(efi32_entry) + /* Store firmware IDT descriptor */ + sidtl (efi32_boot_idt - 1b)(%ebx) + ++ /* Store firmware stack pointer */ ++ movl %esp, (efi32_boot_sp - 1b)(%ebx) ++ + /* Store boot arguments */ + leal (efi32_boot_args - 1b)(%ebx), %ebx + movl %ecx, 0(%ebx) +@@ -324,5 +332,6 @@ SYM_DATA_END(efi32_boot_idt) + + SYM_DATA_LOCAL(efi32_boot_cs, .word 0) + SYM_DATA_LOCAL(efi32_boot_ds, .word 0) ++SYM_DATA_LOCAL(efi32_boot_sp, .long 0) + SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0, 0) + SYM_DATA(efi_is64, .byte 1)