From: Riku Voipio <riku.voipio@iki.fi>
To: Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Eric Biggers <ebiggers@kernel.org>,
"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"David S. Miller" <davem@davemloft.net>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/17] Add zinc using existing algorithm implementations
Date: Tue, 26 Mar 2019 09:46:03 +0000 [thread overview]
Message-ID: <20190326094603.nyfi2dsnt6a6u57f@08efd375aeba> (raw)
In-Reply-To: <AM5PR0901MB1155FD05113D6DC79A6274CED25E0@AM5PR0901MB1155.eurprd09.prod.outlook.com>
On Mon, Mar 25, 2019 at 09:10:08AM +0000, Pascal Van Leeuwen wrote:
> As someone who has been working on crypto acceleration hardware for the better
> part of the past 20 years, I feel compelled to respond to this, in defence of
> the crypto API (which we're really happy with ...).
Thanks for joining in.
> We have done plenty of measurements, on both power and performance, to prove
> you wrong there. Typically our HW needs *at least* a full order of a magnitude
> less power to do the actual work. The CPU load for handing the interrupts etc.
> tends to be around 20%. So assuming the CPU goes to sleep for the other 80%
> of the time, the combined solution would need about 1/3rd of the power of a
> CPU only solution. It's one of our biggest selling points.
I actually have the kind of (relatively) low-power system with your crypto
accelerator IP. But it doesn't matter how great performance or energy saving
I would get from using crypto offloading. I will continue to use CPU only
solution for the foreseeable future.
Because of one tiny problem:
The firmware files for eip197(?) crypto accelerator are secrets we are not
allowed download anywhere from.
> Pascal van Leeuwen,
> Silicon IP Architect @ Inside Secure
Riku
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-26 9:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-22 6:27 [PATCH 0/17] Add zinc using existing algorithm implementations Herbert Xu
2019-03-22 6:29 ` [PATCH 1/17] asm: simd context helper API Herbert Xu
2019-03-22 6:29 ` [PATCH 2/17] crypto: chacha20 - Export chacha20 functions without crypto API Herbert Xu
2019-03-22 6:29 ` [PATCH 3/17] zinc: introduce minimal cryptography library Herbert Xu
2019-03-22 6:29 ` [PATCH 5/17] zinc: Add x86 accelerated ChaCha20 Herbert Xu
2019-03-22 6:29 ` [PATCH 6/17] zinc: Add arm accelerated chacha20 Herbert Xu
2019-03-22 6:29 ` [PATCH 7/17] crypto: poly1305 - Export core functions without crypto API Herbert Xu
2019-03-22 6:29 ` [PATCH 8/17] zinc: Add generic C implementation of poly1305 and self-test Herbert Xu
2019-03-22 6:29 ` [PATCH 9/17] zinc: Add x86 accelerated poly1305 Herbert Xu
2019-03-22 6:29 ` [PATCH 12/17] zinc: BLAKE2s x86_64 implementation Herbert Xu
2019-03-22 6:29 ` [PATCH 14/17] zinc: Curve25519 " Herbert Xu
2019-03-22 6:29 ` [PATCH 15/17] zinc: import Bernstein and Schwabe's Curve25519 ARM implementation Herbert Xu
2019-03-22 6:29 ` [PATCH 17/17] security/keys: rewrite big_key crypto to use Zinc Herbert Xu
2019-03-22 6:41 ` [PATCH 0/17] Add zinc using existing algorithm implementations Jason A. Donenfeld
2019-03-22 7:56 ` Ard Biesheuvel
2019-03-22 8:10 ` Jason A. Donenfeld
2019-03-22 17:48 ` Linus Torvalds
2019-03-25 9:10 ` Pascal Van Leeuwen
2019-03-26 9:46 ` Riku Voipio [this message]
2019-04-09 16:14 ` Pascal Van Leeuwen
2019-03-25 10:43 ` Ard Biesheuvel
2019-03-25 10:45 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190326094603.nyfi2dsnt6a6u57f@08efd375aeba \
--to=riku.voipio@iki.fi \
--cc=Jason@zx2c4.com \
--cc=ard.biesheuvel@linaro.org \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pvanleeuwen@insidesecure.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox