Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1547366

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

Show all headers | View raw

On Mon, Dec 26, 2016 at 9:51 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 26 December 2016 at 07:57, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> On Sat, Dec 24, 2016 at 09:57:53AM -0800, Andy Lutomirski wrote:
>>>
>>> I actually do use incremental hashing later on.   BPF currently
>>> vmallocs() a big temporary buffer just so it can fill it and hash it.
>>> I change it to hash as it goes.
>>
>> How much data is this supposed to hash on average? If it's a large
>> amount then perhaps using the existing crypto API would be a better
>> option than adding this.
>>
>
> This is a good point actually: you didn't explain *why* BPF shouldn't
> depend on the crypto API.

According to Daniel, the networking folks want to let embedded systems
include BPF without requiring the crypto core.

At some point, I'd also like to use modern hash functions for module
verification.  If doing so would require the crypto core to be
available when modules are loaded, then the crypto core couldn't be
modular.  (Although it occurs to me that my patches get that wrong --
if this change happens, I need to split the code so that the library
functions can be built in even if CRYPTO=m.)

Daniel, would you be okay with BPF selecting CRYPTO and CRYPTO_HASH?

Also, as a bikeshed thought: I could call the functions
sha256_init_direct(), etc.  Then there wouldn't be namespace
collisions and the fact that they bypass accelerated drivers would be
more obvious.

--Andy

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash Andy Lutomirski <luto@kernel.org> - 2016-12-24 03:30 +0100
  Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be  used without shash Andy Lutomirski <luto@amacapital.net> - 2016-12-24 03:30 +0100
  Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be  used without shash Andy Lutomirski <luto@amacapital.net> - 2016-12-24 19:00 +0100
    Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can  be used without shash Herbert Xu <herbert@gondor.apana.org.au> - 2016-12-26 09:00 +0100
      Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be  used without shash Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-12-26 19:00 +0100
        Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be  used without shash Andy Lutomirski <luto@amacapital.net> - 2016-12-26 19:20 +0100
          Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can  be used without shash Herbert Xu <herbert@gondor.apana.org.au> - 2016-12-27 11:00 +0100
            Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can  be used without shash Daniel Borkmann <daniel@iogearbox.net> - 2016-12-27 15:20 +0100
              Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be  used without shash Andy Lutomirski <luto@amacapital.net> - 2016-12-27 20:10 +0100

csiph-web