From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from frisell.zx2c4.com ([192.95.5.64]:45373 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725904AbeKUCyw (ORCPT ); Tue, 20 Nov 2018 21:54:52 -0500 MIME-Version: 1.0 References: <20181105232526.173947-1-ebiggers@kernel.org> <20181105232526.173947-11-ebiggers@kernel.org> <20181112185816.GA8663@gmail.com> <20181116060227.hwu4igi6bp26ddpi@gondor.apana.org.au> <20181117001718.GA175522@gmail.com> <20181119052451.qttzfgcm4hvbdc4u@gondor.apana.org.au> <20181120060217.t4nccaqpwnxkl4tx@gondor.apana.org.au> <20181120141850.zjmfwcari5kykk6y@gondor.apana.org.au> In-Reply-To: <20181120141850.zjmfwcari5kykk6y@gondor.apana.org.au> From: "Jason A. Donenfeld" Date: Tue, 20 Nov 2018 17:24:41 +0100 Message-ID: Subject: Re: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc To: Herbert Xu Cc: Ard Biesheuvel , Eric Biggers , Linux Crypto Mailing List , linux-fscrypt@vger.kernel.org, linux-arm-kernel@lists.infradead.org, LKML , Paul Crowley , Greg Kaiser , Samuel Neves , Tomer Ashur , Martin Willi Content-Type: text/plain; charset="UTF-8" Sender: linux-crypto-owner@vger.kernel.org List-ID: On Tue, Nov 20, 2018 at 3:19 PM Herbert Xu 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason@zx2c4.com (Jason A. Donenfeld) Date: Tue, 20 Nov 2018 17:24:41 +0100 Subject: [RFC PATCH v2 0/4] Exporting existing crypto API code through zinc In-Reply-To: <20181120141850.zjmfwcari5kykk6y@gondor.apana.org.au> References: <20181105232526.173947-1-ebiggers@kernel.org> <20181105232526.173947-11-ebiggers@kernel.org> <20181112185816.GA8663@gmail.com> <20181116060227.hwu4igi6bp26ddpi@gondor.apana.org.au> <20181117001718.GA175522@gmail.com> <20181119052451.qttzfgcm4hvbdc4u@gondor.apana.org.au> <20181120060217.t4nccaqpwnxkl4tx@gondor.apana.org.au> <20181120141850.zjmfwcari5kykk6y@gondor.apana.org.au> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Nov 20, 2018 at 3:19 PM Herbert Xu 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