Re: [PATCH v2 0/2] crypto: arm/sha-neon - avoid ADRL instructions

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

 



On Wed, Sep 16, 2020 at 11:08 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>
> On Thu, 17 Sep 2020 at 03:53, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote:
> >
> > One thing I noticed was that if I grep for `adrl` with all of the
> > above applied within arch/arm, I do still see two more instances:
> >
> > crypto/sha256-armv4.pl
> > 609:    adrl    $Ktbl,K256
> >
> > crypto/sha256-core.S_shipped
> > 2679:   adrl    r3,K256
> >
> > Maybe those can be fixed up in patch 01/02 of this series for a v2?  I
> > guess in this cover letter, you did specify *some occurrences of
> > ADRL*.  It looks like those are guarded by
> > 605 # ifdef __thumb2__
> > ...
> > 608 # else
> > 609   adrl  $Ktbl,K256
> >
> > So are these always built as thumb2?
> >
>
> No need. The code in question is never assembled when built as part of
> the kernel, only when building OpenSSL for user space. It appears
> upstream has removed this already, but they have also been playing
> weird games with the license blocks, so I'd prefer fixing the code
> here rather than pulling the latest version.

Oh, like mixing and matching licenses throughout the source itself?
Or changing the source license?

(I've always wondered if software licenses apply to an entire
repository, or were per source file?  Could you mix and match licenses
throughout your project?  Not sure why you'd do that; maybe to make
some parts reusable for some other project.  But if you could, could
you do different sections of a file under different licenses? Again,
probably a worthless hypothetical; you could just split up your source
files better).
-- 
Thanks,
~Nick Desaulniers



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

  Powered by Linux