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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <586277AE.80401@iogearbox.net>
Date:   Tue, 27 Dec 2016 15:16:14 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Herbert Xu <herbert@...dor.apana.org.au>,
        Andy Lutomirski <luto@...capital.net>
CC:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Andy Lutomirski <luto@...nel.org>,
        Netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Hannes Frederic Sowa <hannes@...essinduktion.org>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Eric Biggers <ebiggers3@...il.com>,
        Tom Herbert <tom@...bertland.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can
 be used without shash

On 12/27/2016 10:58 AM, Herbert Xu wrote:
> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
>>
>> According to Daniel, the networking folks want to let embedded systems
>> include BPF without requiring the crypto core.
>
> Last I checked the IPv4 stack depended on the crypto API so this
> sounds bogus.

I think there's a bit of a mixup here with what I said. To clarify,
requirement back then from tracing folks was that bpf engine and
therefore bpf syscall can be build w/o networking enabled for small
devices, so dependencies preferably need to be kept on a absolute
minimum, same counts for either making it suddenly a depend on
CRYPTO or a select CRYPTO for just those few lines that can be
pulled in from lib/ code instead.