Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 11 Nov 2022 at 23:29, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
>
> On 11/9/22 2:05 AM, Ard Biesheuvel wrote:
> > On Wed, 9 Nov 2022 at 04:52, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> >>
> >> On Tue, Nov 08, 2022 at 10:50:48AM -0800, Ben Greear wrote:
> >>>
> >>> While rebasing my patches onto 6.1-rc4, I noticed my aesni for ccm(aes) patch didn't apply cleanly,
> >>> and I found this patch described below is applied now.  Does this upstream patch mean that aesni is already
> >>> supported upstream now?  Or is it specific to whatever xctr is?  If so,
> >>> any chance the patch is wanted upstream now?
> >>
> >> AFAICS the xctr patch has nothing to do with what you were trying
> >> to achieve with wireless.  My objection still stands with regards
> >> to wireless, we should patch wireless to use the async crypto
> >> interface and not hack around it in the Crypto API.
> >>
> >
> > Indeed. Those are just add/add conflicts because both patches
> > introduce new code into the same set of files. The resolution is
> > generally to keep both sides.
> >
> > As for Herbert's objection: I will note here that in the meantime,
> > arm64 now has gotten rid of the scalar fallbacks entirely in AEAD and
> > skipcher implementations, because those are only callable in task or
> > softirq context, and the arm64 SIMD wrappers now disable softirq
> > processing. This means that the condition that results in the fallback
> > being needed can no longer occur, making the SIMD helper dead code on
> > arm64.
> >
> > I suppose we might do the same thing on x86, but since the kernel mode
> > SIMD handling is highly arch specific, you'd really need to raise this
> > with the x86 maintainers.
> >
>
> Hello Ard,
>
> Could you please review the attached patch to make sure I merged it properly?  My concern
> is the cleanup section and/or some problems I might have introduced related to the similarly
> named code that was added upstream.
>

I don't think the logic is quite right, although it rarely matter.

I've pushed my version here - it invokes the static call for CTR so it
will use the faster AVX version if the CPU supports it.

https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=aesni-ccm-v6.1



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux