Re: PROBLEM: unable to decrypt LUKS partition since v4.9-rc6 (bisected)
On Mon, Nov 21, 2016 at 03:34:00PM +0800, Herbert Xu wrote: > On Mon, Nov 21, 2016 at 07:56:38AM +0100, Patrick Steinhardt wrote: > > > > I'm using cryptsetup 1.7.2 via the kernel's crypto API. Since > > version v4.9-rc6, I'm unable to decrypt my LUKS partitions > > (aes-xts-plain64, sha512). cryptsetup simply aborts with the > > message "No such passphrase available" after inputting the > > passphrase. > > > > After bisecting the issue, this points to commit a8348bc (crypto: > > algif_hash - Fix NULL hash crash with shash, 2016-11-17). After > > reverting this particular commit, everything works correctly > > again. > > Sorry, I screwed up that patch. Please try the following fix. > Thanks! [snip] Thanks for the fast response. Your patch fixes the problem. Regards Patrick signature.asc Description: PGP signature
Re: PROBLEM: unable to decrypt LUKS partition since v4.9-rc6 (bisected)
On Mon, Nov 21, 2016 at 07:56:38AM +0100, Patrick Steinhardt wrote:
>
> I'm using cryptsetup 1.7.2 via the kernel's crypto API. Since
> version v4.9-rc6, I'm unable to decrypt my LUKS partitions
> (aes-xts-plain64, sha512). cryptsetup simply aborts with the
> message "No such passphrase available" after inputting the
> passphrase.
>
> After bisecting the issue, this points to commit a8348bc (crypto:
> algif_hash - Fix NULL hash crash with shash, 2016-11-17). After
> reverting this particular commit, everything works correctly
> again.
Sorry, I screwed up that patch. Please try the following fix.
Thanks!
---8<---
crypto: algif_hash - Fix result clobbering in recvmsg
Recently an init call was added to hash_recvmsg so as to reset
the hash state in case a sendmsg call was never made.
Unfortunately this ended up clobbering the result if the previous
sendmsg was done with a MSG_MORE flag. This patch fixes it by
excluding that case when we make the init call.
Fixes: a8348bca2944 ("algif_hash - Fix NULL hash crash with shash")
Reported-by: Patrick Steinhardt
Signed-off-by: Herbert Xu
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 05e21b4..d19b09c 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -214,7 +214,7 @@ static int hash_recvmsg(struct socket *sock, struct msghdr
*msg, size_t len,
ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
- if (!result) {
+ if (!result && !ctx->more) {
err = af_alg_wait_for_completion(
crypto_ahash_init(&ctx->req),
&ctx->completion);
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PROBLEM: unable to decrypt LUKS partition since v4.9-rc6 (bisected)
Hi, I'm using cryptsetup 1.7.2 via the kernel's crypto API. Since version v4.9-rc6, I'm unable to decrypt my LUKS partitions (aes-xts-plain64, sha512). cryptsetup simply aborts with the message "No such passphrase available" after inputting the passphrase. After bisecting the issue, this points to commit a8348bc (crypto: algif_hash - Fix NULL hash crash with shash, 2016-11-17). After reverting this particular commit, everything works correctly again. Please let me know if you need additional information. Regards Patrick signature.asc Description: PGP signature
Re: vmalloced stacks and scatterwalk_map_and_copy()
[Adding Thorsten to help keep this from getting lost] On Thu, Nov 3, 2016 at 1:30 PM, Andy Lutomirski wrote: > On Thu, Nov 3, 2016 at 11:16 AM, Eric Biggers wrote: >> Hello, >> >> I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto >> code >> in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y: >> >> /* carry flag will be set if starting x was >= PAGE_OFFSET */ >> VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x)); >> >> The problem is the following code in scatterwalk_map_and_copy() in >> crypto/scatterwalk.c, which tries to determine if the buffer passed in >> aliases >> the physical memory of the first segment of the scatterlist: >> >> if (sg_page(sg) == virt_to_page(buf) && >> sg->offset == offset_in_page(buf)) >> return; > > ... > >> >> Currently I think the best solution would be to require that callers to >> scatterwalk_map_and_copy() do not alias their source and destination. Then >> the >> alias check could be removed. This check has only been there since v4.2 >> (commit >> 74412fd5d71b6), so I'd hope not many callers rely on the behavior. I'm not >> sure >> exactly which ones do, though. >> >> Thoughts on this? > > The relevant commit is: > > commit 74412fd5d71b6eda0beb302aa467da000f0d530c > Author: Herbert Xu > Date: Thu May 21 15:11:12 2015 +0800 > > crypto: scatterwalk - Check for same address in map_and_copy > > This patch adds a check for in scatterwalk_map_and_copy to avoid > copying from the same address to the same address. This is going > to be used for IV copying in AEAD IV generators. > > There is no provision for partial overlaps. > > This patch also uses the new scatterwalk_ffwd instead of doing > it by hand in scatterwalk_map_and_copy. > > Signed-off-by: Herbert Xu > > Herbert, can you clarify this? The check seems rather bizarre -- > you're doing an incomplete check for aliasing and skipping the whole > copy if the beginning aliases. In any event the stack *can't* > reasonably alias the scatterlist because a scatterlist can't safely > point to the stack. Is there any code that actually relies on the > aliasing-detecting behavior? > > Also, Herbert, it seems like the considerable majority of the crypto > code is acting on kernel virtual memory addresses and does software > processing. Would it perhaps make sense to add a kvec-based or > iov_iter-based interface to the crypto code? I bet it would be quite > a bit faster and it would make crypto on stack buffers work directly. Ping, everyone! It's getting quite close to 4.9 release time. Is there an actual bug here? Because, if so, we need to fix it. My preference is to just delete the weird aliasing check, but it would be really nice to know if that check is needed for some reason. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
On 20 November 2016 at 11:42, Ard Biesheuvel wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>
> Relative performance compared to the respective generic C versions:
>
> | SHA256-scalar | SHA256-NEON* | SHA512 |
> +-+--+--+
> Cortex-A53 | 1.63x | 1.63x| 2.34x |
> Cortex-A57 | 1.43x | 1.59x| 1.95x |
> Cortex-A73 | 1.26x | 1.56x| ?|
>
> The core crypto code was authored by Andy Polyakov of the OpenSSL
> project, in collaboration with whom the upstream code was adapted so
> that this module can be built from the same version of sha512-armv8.pl.
>
> The version in this patch was taken from OpenSSL commit 32bbb62ea634
> ("sha/asm/sha512-armv8.pl: fix big-endian support in __KERNEL__ case.")
>
> * The core SHA algorithm is fundamentally sequential, but there is a
> secondary transformation involved, called the schedule update, which
> can be performed independently. The NEON version of SHA-224/SHA-256
> only implements this part of the algorithm using NEON instructions,
> the sequential part is always done using scalar instructions.
>
> Signed-off-by: Ard Biesheuvel
> ---
Missing changelog:
v4: fixed the big-endian build; this required an upstream change (even
though upstream was not actually broken, since it explicitly defines
__ARMEB__ on AArch64 big-endian builds), so this patch is now based
on a more recent upstream OpenSSL commit (the __ILP32__ #ifdefs are
still present but never active)
v3: at Will's request, the generated assembly files are now included
as .S_shipped files, for which generic build rules are defined
already.
Note that sizeable patches like this one have caused issues in the past with
patchwork, so for Herbert's convenience, the patch can be pulled from
http://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git, branch
arm64-sha256 (based on today's cryptodev)
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
