From: "Jason A. Donenfeld" <Jason@zx2c4.com> To: Herbert Xu <herbert@gondor.apana.org.au> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>, Eric Biggers <ebiggers@kernel.org>, Linux Crypto Mailing List <linux-crypto@vger.kernel.org>, linux-fscrypt@vger.kernel.org, linux-arm-kernel@lists.infradead.org, LKML <linux-kernel@vger.kernel.org>, Paul Crowley <paulcrowley@google.com>, Greg Kaiser <gkaiser@google.com>, Samuel Neves <samuel.c.p.neves@gmail.com>, Tomer Ashur <tomer.ashur@esat.kuleuven.be>, Martin Willi <martin@strongswan.org> Subject: Re: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Date: Tue, 20 Nov 2018 17:24:41 +0100 [thread overview] Message-ID: <CAHmME9oPGkvEmqvfbav-AOf_P=Z4zWYxvqD3a3QhuOSh_OWd_A@mail.gmail.com> (raw) In-Reply-To: <20181120141850.zjmfwcari5kykk6y@gondor.apana.org.au> On Tue, Nov 20, 2018 at 3:19 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > Yes. In fact it's used for FIPS certification testing. > Sure, nobody sane should be doing it. But when it comes to > government certification... :) The kernel does not aim toward any FIPS certification, and we're not going to start bloating our designs to fulfill this. It's never been a goal. Maybe ask Ted to add a FIPS mode to random.c and see what happens... When you start arguing "because FIPS!" as your justification, you really hit a head scratcher. > They've already paid for the indirect > function call so why make them go through yet another run-time > branch? The indirect function call in the crypto API is the performance hit. The branch in Zinc is not, as the predictor does the correct thing every single time. I'm not able to distinguish between the two looking at the performance measurements between it being there and the branch being commented out. Give me a few more days to finish v9's latest required changes for chacha12, and then I'll submit a revision that I think should address the remaining technical objections raised over the last several months we've been discussing this. Regards, Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason@zx2c4.com (Jason A. Donenfeld) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Date: Tue, 20 Nov 2018 17:24:41 +0100 [thread overview] Message-ID: <CAHmME9oPGkvEmqvfbav-AOf_P=Z4zWYxvqD3a3QhuOSh_OWd_A@mail.gmail.com> (raw) In-Reply-To: <20181120141850.zjmfwcari5kykk6y@gondor.apana.org.au> On Tue, Nov 20, 2018 at 3:19 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > Yes. In fact it's used for FIPS certification testing. > Sure, nobody sane should be doing it. But when it comes to > government certification... :) The kernel does not aim toward any FIPS certification, and we're not going to start bloating our designs to fulfill this. It's never been a goal. Maybe ask Ted to add a FIPS mode to random.c and see what happens... When you start arguing "because FIPS!" as your justification, you really hit a head scratcher. > They've already paid for the indirect > function call so why make them go through yet another run-time > branch? The indirect function call in the crypto API is the performance hit. The branch in Zinc is not, as the predictor does the correct thing every single time. I'm not able to distinguish between the two looking at the performance measurements between it being there and the branch being commented out. Give me a few more days to finish v9's latest required changes for chacha12, and then I'll submit a revision that I think should address the remaining technical objections raised over the last several months we've been discussing this. Regards, Jason
next prev parent reply other threads:[~2018-11-21 2:54 UTC|newest] Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-05 23:25 [RFC PATCH v3 00/15] crypto: Adiantum support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 01/15] crypto: chacha20-generic - add HChaCha20 library function Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 02/15] crypto: chacha20-generic - don't unnecessarily use atomic walk Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 03/15] crypto: chacha20-generic - add XChaCha20 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 04/15] crypto: chacha20-generic - refactor to allow varying number of rounds Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 05/15] crypto: chacha - add XChaCha12 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 06/15] crypto: arm/chacha20 - limit the preemption-disabled section Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 07/15] crypto: arm/chacha20 - add XChaCha20 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-06 12:41 ` Ard Biesheuvel 2018-11-06 12:41 ` Ard Biesheuvel 2018-11-06 12:41 ` Ard Biesheuvel 2018-11-05 23:25 ` [RFC PATCH v3 08/15] crypto: arm/chacha20 - refactor to allow varying number of rounds Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-06 12:46 ` Ard Biesheuvel 2018-11-06 12:46 ` Ard Biesheuvel 2018-11-06 12:46 ` Ard Biesheuvel 2018-11-05 23:25 ` [RFC PATCH v3 09/15] crypto: arm/chacha - add XChaCha12 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 10/15] crypto: poly1305 - use structures for key and accumulator Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-06 14:28 ` Ard Biesheuvel 2018-11-06 14:28 ` Ard Biesheuvel 2018-11-06 14:28 ` Ard Biesheuvel 2018-11-12 18:58 ` Eric Biggers 2018-11-12 18:58 ` Eric Biggers 2018-11-12 18:58 ` Eric Biggers 2018-11-16 6:02 ` Herbert Xu 2018-11-16 6:02 ` Herbert Xu 2018-11-16 6:02 ` Herbert Xu 2018-11-17 0:17 ` Eric Biggers 2018-11-17 0:17 ` Eric Biggers 2018-11-17 0:17 ` Eric Biggers 2018-11-17 0:30 ` Ard Biesheuvel 2018-11-17 0:30 ` Ard Biesheuvel 2018-11-17 0:30 ` Ard Biesheuvel 2018-11-18 13:46 ` Jason A. Donenfeld 2018-11-18 13:46 ` Jason A. Donenfeld 2018-11-19 5:24 ` [RFC PATCH] zinc chacha20 generic implementation using crypto API code Herbert Xu 2018-11-19 6:13 ` Jason A. Donenfeld 2018-11-19 6:13 ` Jason A. Donenfeld 2018-11-19 6:22 ` Herbert Xu 2018-11-19 6:22 ` Herbert Xu 2018-11-19 22:54 ` Eric Biggers 2018-11-19 22:54 ` Eric Biggers 2018-11-19 23:15 ` Jason A. Donenfeld 2018-11-19 23:15 ` Jason A. Donenfeld 2018-11-19 23:23 ` Eric Biggers 2018-11-19 23:23 ` Eric Biggers 2018-11-19 23:31 ` Jason A. Donenfeld 2018-11-19 23:31 ` Jason A. Donenfeld 2018-11-20 3:06 ` Herbert Xu 2018-11-20 3:06 ` Herbert Xu 2018-11-20 3:08 ` Jason A. Donenfeld 2018-11-20 3:08 ` Jason A. Donenfeld 2018-11-20 6:02 ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Herbert Xu 2018-11-20 6:02 ` Herbert Xu 2018-11-20 6:04 ` [v2 PATCH 1/4] crypto: chacha20 - Export chacha20 functions without crypto API Herbert Xu 2018-11-20 6:04 ` Herbert Xu 2018-11-20 6:04 ` [v2 PATCH 2/4] zinc: ChaCha20 generic C implementation and selftest Herbert Xu 2018-11-20 6:04 ` [v2 PATCH 3/4] zinc: Add x86 accelerated ChaCha20 Herbert Xu 2018-11-20 6:04 ` Herbert Xu 2018-11-20 6:04 ` [v2 PATCH 4/4] zinc: ChaCha20 x86_64 implementation Herbert Xu 2018-11-20 10:32 ` [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc Ard Biesheuvel 2018-11-20 10:32 ` Ard Biesheuvel 2018-11-20 10:32 ` Ard Biesheuvel 2018-11-20 14:18 ` Herbert Xu 2018-11-20 14:18 ` Herbert Xu 2018-11-20 14:18 ` Herbert Xu 2018-11-20 16:24 ` Jason A. Donenfeld [this message] 2018-11-20 16:24 ` Jason A. Donenfeld 2018-11-20 18:51 ` Theodore Y. Ts'o 2018-11-20 18:51 ` Theodore Y. Ts'o 2018-11-21 7:55 ` Herbert Xu 2018-11-21 7:55 ` Herbert Xu 2018-11-20 16:18 ` Jason A. Donenfeld 2018-11-20 16:18 ` Jason A. Donenfeld 2018-11-21 6:01 ` Herbert Xu 2018-11-21 6:01 ` Herbert Xu 2018-11-05 23:25 ` [RFC PATCH v3 11/15] crypto: poly1305 - add Poly1305 core API Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 12/15] crypto: nhpoly1305 - add NHPoly1305 support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 13/15] crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305 Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 14/15] crypto: adiantum - add Adiantum support Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-05 23:25 ` [RFC PATCH v3 15/15] fscrypt: " Eric Biggers 2018-11-05 23:25 ` Eric Biggers 2018-11-08 6:47 ` [RFC PATCH v3 00/15] crypto: " Martin Willi 2018-11-08 6:47 ` Martin Willi
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='CAHmME9oPGkvEmqvfbav-AOf_P=Z4zWYxvqD3a3QhuOSh_OWd_A@mail.gmail.com' \ --to=jason@zx2c4.com \ --cc=ard.biesheuvel@linaro.org \ --cc=ebiggers@kernel.org \ --cc=gkaiser@google.com \ --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=martin@strongswan.org \ --cc=paulcrowley@google.com \ --cc=samuel.c.p.neves@gmail.com \ --cc=tomer.ashur@esat.kuleuven.be \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.