From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 399C9C433EF for ; Tue, 1 Feb 2022 18:26:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=AGOjGfZw8xl6YWEUcloUnhnEBZxSgY0fvewNKdkwakE=; b=E/7umiRU6N4MVL 7sa0t7abAs3rAi2eybI7FsNL9PJSTI1F7OieK8AXATQgvcWUNI4qpNb4qVubgWJ2fXcYc1zsV9gtH XB2+Aon9YTSXS4aQQjjlCJl4mzj3YR6alMsPLb3dH2mGWbUsPg6svBeBlup0GnCET6Eq8DTPJF0ZJ zo0hPtuGw0oOgR8TUUnl1smR/uL7o95cIkBha4Xko20u6Dh9iTaXrZKwK6sd9qGJLShMufdJZq183 T7kkojkqfW6CfOkKCAhmz3kS6D8xBzEmy8BW8x8c/983M3S4R6WLuNhSuy0n/Yd8HmCkobz4mIdmA f5fdcjAtRP5TW6c/Uimg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nExqH-00DKwQ-2j; Tue, 01 Feb 2022 18:25:25 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nExqD-00DKvq-VB for linux-arm-kernel@lists.infradead.org; Tue, 01 Feb 2022 18:25:23 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B2C08B82F43; Tue, 1 Feb 2022 18:25:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E235C340EB; Tue, 1 Feb 2022 18:25:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643739919; bh=UopXML1y2+3eR3FHQlQljjrWP2KvD2JcvIaAM9I9cFg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Zm4pLjdryNCBhZ7tCqTmngbvZE2NnC/htU3yhnG6pKfyFgpkIhhGN0nt4tckCxQKF 2QcIAlA7CAYeP7Y4kBChjIH6NIxPzNJahCy/9tzn+C7yvLQfVKL1Cm4l/voV9roQTD 12tEB9dbGu+9Aj3qE8ilHfBNQqukda3r7ENbeIhxniGpiinLrGashH6u9AD2RvxeWd ZdxvvRxajIXXK/1LIhTl5uBu1L6pj2jZCP7g8Fn2IoFkEIrL7TrTD0CqK+pHcDojxb scXngfH4wC9L951MD2YROUQOrrq5Krp06DdVVjQ4H0Y9xxt+SPfnXIkPc2Au7Zzmen YxDRXIgtwCsrw== Date: Tue, 1 Feb 2022 10:25:17 -0800 From: Eric Biggers To: Nathan Huckleberry Cc: linux-crypto@vger.kernel.org, Herbert Xu , "David S. Miller" , linux-arm-kernel@lists.infradead.org, Paul Crowley , Sami Tolvanen Subject: Re: [RFC PATCH 3/7] crypto: hctr2 - Add HCTR2 support Message-ID: References: <20220125014422.80552-1-nhuck@google.com> <20220125014422.80552-4-nhuck@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220201_102522_311416_E5ADB897 X-CRM114-Status: GOOD ( 25.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 26, 2022 at 10:35:42PM -0800, Eric Biggers wrote: > The IV passed to skcipher_request_set_crypt() above needs to be part of the > request context, not part of the stack frame of this function, in case the xctr > implementation is asynchronous which would cause the stack frame to go out of > scope. The x86 implementation operates asynchronously when called in a context > where SIMD instructions are unavailable. > > Perhaps rctx->first_block can be reused, as it's already in the request context? > > Make sure to test your changes with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled, > as that is able to detect this bug (at least when CONFIG_KASAN is also enabled, > which I also highly recommend) since it tests calling the crypto algorithms in a > context where SIMD instructions cannot be used. Here's the bug report I got: > > BUG: KASAN: stack-out-of-bounds in __crypto_xor+0x29e/0x480 crypto/algapi.c:1005 > Read of size 8 at addr ffffc900006775f8 by task kworker/2:1/41 > CPU: 2 PID: 41 Comm: kworker/2:1 Not tainted 5.17.0-rc1-00071-gb35cef9ae599 #8 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.15.0-1 04/01/2014 > Workqueue: cryptd cryptd_queue_worker > Call Trace: > > show_stack+0x3d/0x3f arch/x86/kernel/dumpstack.c:318 > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x49/0x5e lib/dump_stack.c:106 > print_address_description.constprop.0+0x24/0x150 mm/kasan/report.c:255 > __kasan_report.cold+0x7d/0x11a mm/kasan/report.c:442 > kasan_report+0x3c/0x50 mm/kasan/report.c:459 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 > __crypto_xor+0x29e/0x480 crypto/algapi.c:1005 > crypto_xor_cpy include/crypto/algapi.h:182 [inline] > xctr_crypt+0x1f1/0x2f0 arch/x86/crypto/aesni-intel_glue.c:585 > crypto_skcipher_encrypt+0xe2/0x150 crypto/skcipher.c:630 > cryptd_skcipher_encrypt+0x1c2/0x320 crypto/cryptd.c:274 > cryptd_queue_worker+0xe4/0x160 crypto/cryptd.c:181 > process_one_work+0x822/0x14e0 kernel/workqueue.c:2307 > worker_thread+0x590/0xf60 kernel/workqueue.c:2454 > kthread+0x257/0x2f0 kernel/kthread.c:377 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 > > Memory state around the buggy address: > ffffc90000677480: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 > ffffc90000677500: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 00 > >ffffc90000677580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 > ^ > ffffc90000677600: f1 f1 f1 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 00 > ffffc90000677680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ================================================================== > alg: skcipher: hctr2(aes-aesni,xctr-aes-aesni,polyval-pclmulqdqni) encryption test failed (wrong result) on test vector 2, cfg="random: use_digest nosimd src_divs=[100.0%@+3830] iv_offset=45" > ------------[ cut here ]------------ > alg: self-tests for hctr2(aes-aesni,xctr-aes-aesni,polyval-pclmulqdqni) (hctr2(aes)) failed (rc=-22) > WARNING: CPU: 2 PID: 519 at crypto/testmgr.c:5690 alg_test+0x2d9/0x830 crypto/testmgr.c:5690 > > > > diff --git a/crypto/testmgr.c b/crypto/testmgr.c > > index a3a24aa07492..fa8f33210358 100644 > > --- a/crypto/testmgr.c > > +++ b/crypto/testmgr.c > > @@ -4994,6 +4994,12 @@ static const struct alg_test_desc alg_test_descs[] = { > > .suite = { > > .hash = __VECS(ghash_tv_template) > > } > > + }, { > > + .alg = "hctr2(aes)", > > + .test = alg_test_skcipher, > > The .generic_driver field should be filled in here to allow the comparison tests > to run, since the default strategy of forming the generic driver name isn't > valid here; it would result in hctr2(aes-generic), which doesn't work. > Note that with the above two issues fixed, it is still hanging somewhere and never actually finishing the tests. Maybe an infinite loop somewhere? - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel