Received: by 2002:a19:ef0c:0:0:0:0:0 with SMTP id n12csp980171lfh; Thu, 27 Jan 2022 04:43:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJx4qWzo84UdYi5LPd3PbXpEc20wkjqc7bTS7dRn4U4C0ygm7XrUSrnlldTOstcmJegFu2L3 X-Received: by 2002:a17:907:924d:: with SMTP id kb13mr2749198ejb.507.1643287418524; Thu, 27 Jan 2022 04:43:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643287418; cv=none; d=google.com; s=arc-20160816; b=hYDFYu6vUSZQNwbQiiuyGUMM6i4f45F+zuRxauSspwHTMi03gdOLIRPHoDeFNWvlel Vjzv9i92/67bDR+t6xz+zjIj3ayGXjYPTbFsf7psA1KJrHMDiQwFG2rVzurKZgyONrXX bsjC4cjDBkqehZPA2HfZOfKfvuhL490WIvXlNaHR2H3gYEX2CoCtuOlId2RSvYS0YEs9 3YyXwhSGHroWekBFsvkP0NoDgYOi6W/UjD3h4xbmdXLy+nRUVgQRCg81Dbf2uCTjQoij 4QEmfIxcREZANXlpbtQqIM2Ur6htJLcKltk0jj9ZBngrtF3O3VA+G+IjBWTofFwqP1lh HJ8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=hvYoAuAx6T/gbcbnHtPcgsIEJMMCkGr4n1kZkY2MXIE=; b=S5KABC4p8HGSKboGRJQc3yq1wmthBEJxSJw8s3I436OXZev6n3H87Znimf+zlgLTy0 /LnFmicSbSlZ3XxRczOVd+CK1yRUTmAb9U9sXp5Q+BeBOiixz2JTWCDmum0Eub8DfKnu pimxBnK8m2jmD0TwREHIkm8YcLWYV39/aSq0OGzDcG/RRX83Go5LB0hw3ix6jE/xYOhf 8cZaFKuoL1LpNBAhuvoHvMH03Ddte4U8fVDnvyLDPBDsgyO+6Vz9QyvE5MdvyvMfF/KP cO9sina+OF3J4bk3t6BaTB8KPeVE2VJybjr2St+LEynOpgtrfYGPONKC3ZgCn/fpHFG9 4E4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZG0UHcRC; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sb17si1299983ejc.958.2022.01.27.04.43.04; Thu, 27 Jan 2022 04:43:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZG0UHcRC; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230297AbiA0Gfq (ORCPT + 99 others); Thu, 27 Jan 2022 01:35:46 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:53498 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229650AbiA0Gfq (ORCPT ); Thu, 27 Jan 2022 01:35:46 -0500 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 53A67B82159 for ; Thu, 27 Jan 2022 06:35:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8D86C340E4; Thu, 27 Jan 2022 06:35:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643265344; bh=TndIVlZCQzs4rK12xm23gVMrjaxMHjx7IqXWW7ULvuo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZG0UHcRC96al6rYipz/CRKlZMIXqbPqA6XvQXVdyHpgHzV/2OpPrJkmX0P0D8cYhO fk3GEbA9i+gXRHc/wzY26S0F2DQyG/lI7N7BvdmfjaRcijTeCPWlfuUljffbvZyZQw VBD/1PRBwRF9CG5HSFOllIN2jejEnT+zNyOjpLRX8r15k3mEKHCS9Ni519fM54w1Z6 B+yuA+OZEtxgx10AOpvA/KEzxFKcgU84qHJD2E6WqTStd9PQQ9DsGDnLpStODoPBgm 9m8n8nsEC5RhldEO64K9c9DftIIjzeRZtobp7BOqvugNA51VPcpApFyWflScjjrwYs P4QVDytZZ8ByQ== Date: Wed, 26 Jan 2022 22:35:42 -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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220125014422.80552-4-nhuck@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Jan 24, 2022 at 07:44:18PM -0600, Nathan Huckleberry wrote: > +static int hctr2_hash_tweak(struct skcipher_request *req, u8 *iv) > +{ The iv parameter is unnecessary here, since it can be gotten from req->iv. > +static int hctr2_crypt(struct skcipher_request *req, bool enc) > +{ > + struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req); > + const struct hctr2_tfm_ctx *tctx = crypto_skcipher_ctx(tfm); > + struct hctr2_request_ctx *rctx = skcipher_request_ctx(req); > + u8 digest[POLYVAL_DIGEST_SIZE]; > + int bulk_len = req->cryptlen - BLOCKCIPHER_BLOCK_SIZE; > + int err; > + > + // Requests must be at least one block > + if (req->cryptlen < BLOCKCIPHER_BLOCK_SIZE) > + return -EINVAL; > + > + scatterwalk_map_and_copy(rctx->first_block, req->src, > + 0, BLOCKCIPHER_BLOCK_SIZE, 0); > + rctx->bulk_part_src = scatterwalk_ffwd(rctx->sg_src, req->src, BLOCKCIPHER_BLOCK_SIZE); > + rctx->bulk_part_dst = scatterwalk_ffwd(rctx->sg_dst, req->dst, BLOCKCIPHER_BLOCK_SIZE); > + > + err = hctr2_hash_tweak(req, req->iv); > + if (err) > + return err; > + err = hctr2_hash_message(req, rctx->bulk_part_src, digest); > + if (err) > + return err; > + crypto_xor(digest, rctx->first_block, BLOCKCIPHER_BLOCK_SIZE); > + > + if (enc) > + crypto_cipher_encrypt_one(tctx->blockcipher, rctx->first_block, digest); > + else > + crypto_cipher_decrypt_one(tctx->blockcipher, rctx->first_block, digest); > + > + crypto_xor(digest, rctx->first_block, BLOCKCIPHER_BLOCK_SIZE); > + crypto_xor(digest, tctx->L, BLOCKCIPHER_BLOCK_SIZE); > + > + skcipher_request_set_tfm(&rctx->u.streamcipher_req, tctx->streamcipher); > + skcipher_request_set_crypt(&rctx->u.streamcipher_req, rctx->bulk_part_src, > + rctx->bulk_part_dst, bulk_len, digest); > + skcipher_request_set_callback(&rctx->u.streamcipher_req, > + req->base.flags, > + hctr2_streamcipher_done, req); > + return crypto_skcipher_encrypt(&rctx->u.streamcipher_req) ?: > + hctr2_finish(req); > +} 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. - Eric