Message ID | 20230612210442.1805962-1-heiko.stuebner@vrull.eu |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp135193vqr; Mon, 12 Jun 2023 14:11:33 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6BlSk9b1E2QmIwUNeBH9xEzkNrfvcTx+vDPQt7jwzDpIFwy/sEBwPtLnpbI63f6fwRiNeO X-Received: by 2002:a17:907:6ea4:b0:96a:8c13:8dc0 with SMTP id sh36-20020a1709076ea400b0096a8c138dc0mr12560041ejc.37.1686604293199; Mon, 12 Jun 2023 14:11:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686604293; cv=none; d=google.com; s=arc-20160816; b=GxB0/rv+TZZISfidJgSeqvsZxbC0ss8v0jvx5Fm2/4G78kTaIN81P6K8rYGrPxSBzG D0PwXI0+Kzgyavatp+Aal/MON6aLGpv2izc8V7P0EXuxvuHnqoVqkIjLCjrRo7kz4zI7 rDl6oypHJ0LHAOfoCoYc2UnDgHCV4d6GVWfyc0+ml72iELOhXQF9NeMeJRQ9LSBgHt2a IoR1iJRdPSm1nTmKPjADCoTETMpMjmel6SrVGfXg/Hv/4NUifuYNDvFONBMgK3lldx0d ug6pccebA1BfduhXmlnqLCJ20OJESSd819wSu3shjOGoA+HNRykmB8uYvLGF9ctmuy4s q2Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=eviVgkS9NlVMOucxjdeY237DiPBE3HgqYjm7UGiykhs=; b=rva+28HAQYTB2e6WFZR3DEtHFIxnOVh5pSciKQzpyCRkMo4/F26pQ+jNi1/Syg+rCg RE1GCta46Jba4gfRvzTJxS+vasydACGF2OyWA4KDM+/5nlX/ttt19i2uQOgVc5sEWT9l P4JTJRmCMhOegdYfcu6cBt0WLyBmB+wgb17xY7UJDjUcmOr1mjUOdbLqoA4bWWyFLiDu fT9O9T2SFveId3B9dJL/cqwiTNn4/891vQCQiX9qgkA62bQoD6Ig+NPALQCBVKkGSph1 RmZXoXljvm4Qw9Apqec7OeehQvxUTZXRPzSu87oxtHIgcIsKT3uI3pJ2U80VE20oVbSt 6YPA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ha13-20020a170906a88d00b009745124453csi5408095ejb.815.2023.06.12.14.11.07; Mon, 12 Jun 2023 14:11:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239400AbjFLVJE (ORCPT <rfc822;rust.linux@gmail.com> + 99 others); Mon, 12 Jun 2023 17:09:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238277AbjFLVHz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 12 Jun 2023 17:07:55 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C350698; Mon, 12 Jun 2023 14:05:01 -0700 (PDT) Received: from i53875b22.versanet.de ([83.135.91.34] helo=phil.lan) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <heiko@sntech.de>) id 1q8oia-0005fR-KP; Mon, 12 Jun 2023 23:04:52 +0200 From: Heiko Stuebner <heiko@sntech.de> To: palmer@dabbelt.com, paul.walmsley@sifive.com Cc: heiko@sntech.de, aou@eecs.berkeley.edu, herbert@gondor.apana.org.au, davem@davemloft.net, conor.dooley@microchip.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, christoph.muellner@vrull.eu, Heiko Stuebner <heiko.stuebner@vrull.eu> Subject: [PATCH v5 0/4] Implement GCM ghash using Zbc and Zbkb extensions Date: Mon, 12 Jun 2023 23:04:38 +0200 Message-Id: <20230612210442.1805962-1-heiko.stuebner@vrull.eu> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_SCC_BODY_TEXT_LINE,T_SPF_HELO_TEMPERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768532783786831794?= X-GMAIL-MSGID: =?utf-8?q?1768532783786831794?= |
Series |
Implement GCM ghash using Zbc and Zbkb extensions
|
|
Message
Heiko Stübner
June 12, 2023, 9:04 p.m. UTC
From: Heiko Stuebner <heiko.stuebner@vrull.eu>
This was originally part of my vector crypto series, but was part
of a separate openssl merge request implementing GCM ghash as using
non-vector extensions.
As that pull-request
https://github.com/openssl/openssl/pull/20078
got merged recently into openssl, we could also check if this could
go into the kernel as well and provide a base for further accelerated
cryptographic support.
Changes in v5:
- rebased on top of 6.4-based riscv/next
- code from openssl is now dual-licensed under Apache + BSD
see https://github.com/openssl/openssl/pull/20649
- separate init functions instead of creating them with macros (Nathan)
Changes in v4:
- rebase on top of riscv/for-next
- split out the scalar crypto implementation from the vector series
- refresh code from openSSL to match exactly
- Remove RFC label, as Zbc and Zbkb are ratified and
the cryptographic code was merged into openSSL
changes in v3:
- rebase on top of 6.3-rc2
- rebase on top of vector-v14 patchset
- add the missing Co-developed-by mentions to showcase
the people that did the actual openSSL crypto code
changes in v2:
- rebased on 6.2 + zbb series, so don't include already
applied changes anymore
- refresh code picked from openssl as that side matures
- more algorithms (SHA512, AES, SM3, SM4)
Heiko Stuebner (4):
RISC-V: add Zbc extension detection
RISC-V: add Zbkb extension detection
RISC-V: hook new crypto subdir into build-system
RISC-V: crypto: add accelerated GCM GHASH implementation
arch/riscv/Kbuild | 1 +
arch/riscv/Kconfig | 22 ++
arch/riscv/crypto/Kconfig | 18 ++
arch/riscv/crypto/Makefile | 18 ++
arch/riscv/crypto/ghash-riscv64-glue.c | 296 +++++++++++++++++
arch/riscv/crypto/ghash-riscv64-zbc.pl | 427 +++++++++++++++++++++++++
arch/riscv/crypto/riscv.pm | 258 +++++++++++++++
arch/riscv/include/asm/hwcap.h | 2 +
arch/riscv/kernel/cpu.c | 2 +
arch/riscv/kernel/cpufeature.c | 2 +
crypto/Kconfig | 3 +
11 files changed, 1049 insertions(+)
create mode 100644 arch/riscv/crypto/Kconfig
create mode 100644 arch/riscv/crypto/Makefile
create mode 100644 arch/riscv/crypto/ghash-riscv64-glue.c
create mode 100644 arch/riscv/crypto/ghash-riscv64-zbc.pl
create mode 100644 arch/riscv/crypto/riscv.pm
Comments
Hi Heiko, On Mon, Jun 12, 2023 at 11:04:38PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner <heiko.stuebner@vrull.eu> > > This was originally part of my vector crypto series, but was part > of a separate openssl merge request implementing GCM ghash as using > non-vector extensions. > > As that pull-request > https://github.com/openssl/openssl/pull/20078 > got merged recently into openssl, we could also check if this could > go into the kernel as well and provide a base for further accelerated > cryptographic support. I'm still a bit skeptical of the usefulness of a standalone "ghash" implementation, when in practice it will only be used as part of "gcm(aes)". Directly implementing "gcm(aes)" (instead of relying on crypto/gcm.c to compose "ghash" and "ctr(aes)") also allows some performance optimizations. I asked about this on v4 (https://lore.kernel.org/linux-crypto/ZCSG71bRuTzVutdm@gmail.com/), but I didn't receive a response. Any thoughts on this? - Eric
Hi Eric, Am Dienstag, 13. Juni 2023, 05:02:16 CEST schrieb Eric Biggers: > Hi Heiko, > > On Mon, Jun 12, 2023 at 11:04:38PM +0200, Heiko Stuebner wrote: > > From: Heiko Stuebner <heiko.stuebner@vrull.eu> > > > > This was originally part of my vector crypto series, but was part > > of a separate openssl merge request implementing GCM ghash as using > > non-vector extensions. > > > > As that pull-request > > https://github.com/openssl/openssl/pull/20078 > > got merged recently into openssl, we could also check if this could > > go into the kernel as well and provide a base for further accelerated > > cryptographic support. > > I'm still a bit skeptical of the usefulness of a standalone "ghash" > implementation, when in practice it will only be used as part of "gcm(aes)". > Directly implementing "gcm(aes)" (instead of relying on crypto/gcm.c to compose > "ghash" and "ctr(aes)") also allows some performance optimizations. > > I asked about this on v4 > (https://lore.kernel.org/linux-crypto/ZCSG71bRuTzVutdm@gmail.com/), > but I didn't receive a response. > > Any thoughts on this? somehow I always seem to overlook this when adapting the series :-( I guess for me the main gcm was always a stepping stone to get started and extend later. This is my first rodeo with crypto stuff in the kernel, so this looks like a manageable chunk and as can be seen by the discussion we had about licensing brings enough topics on its own :-) . Heiko