From: Andy Lutomirski <luto@amacapital.net>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andy Lutomirski <luto@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Eric Biggers <ebiggers@kernel.org>,
Greg KH <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Samuel Neves <sneves@dei.uc.pt>,
Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
Date: Mon, 17 Sep 2018 07:51:54 -0700 [thread overview]
Message-ID: <35BC21D7-01F4-4F91-A7E9-8D15DE5B95D6@amacapital.net> (raw)
In-Reply-To: <CAKv+Gu8QgRo-Oex2Sk5unET3FMq+1Cp2btAWXCB8xsALxjatHg@mail.gmail.com>
> On Sep 16, 2018, at 10:26 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> As far as I can tell (i.e., as a user not a network dev), WireGuard is
> an excellent piece of code, and I would like to see it merged. I also
> think there is little disagreement about the quality of the proposed
> algorithm implementations and the usefulness of having a set of easy
> to use solid crypto primitives in addition to or complementing the
> current crypto API.
>
> I do have some concerns over how the code is organized though:
>
> * simd_relax() is currently not called by the crypto routines
> themselves. This means that the worst case scheduling latency is
> unbounded, which is unacceptable for the -rt kernel. The worst case
> scheduling latency should never be proportional to the input size.
> (Apologies for not spotting that earlier)
>
> * Using a cute name for the crypto library [that will end up being the
> preferred choice for casual use only] may confuse people, given that
> we have lots of code in crypto/ already. I'd much prefer using, e.g.,
> crypto/lib and crypto/api (regardless of where the arch specific
> pieces live)
>
> * I'd prefer the arch specific pieces to live under arch, but I can
> live with keeping them in a single place, as long as the arch
> maintainers have some kind of jurisdiction over them. I also think
> there should be some overlap between the maintainership
> responsibilities of the two generic pieces (api and lib).
>
> * (Nit) The GCC command line -include'd .h files contain variable and
> function definitions so they are actually .c files.
Hmm. I would suggest just getting rid of the -include magic entirely. The resulting ifdef will be more comprehensible.
> * The current organization of the code puts all available (for the
> arch) versions of all routines into a single module, which can only be
> built in once we update random.c to use Zinc's chacha20 routines. This
> bloats the core kernel (which is a huge deal for embedded systems that
> have very strict boot requirements). It also makes it impossible to
> simply blacklist a module if you, for instance, prefer to use the
> [potentially more power efficient] scalar code over the SIMD code when
> using a distro kernel.
I think the module organization needs to change. It needs to be possible to have chacha20 built in but AES or whatever as a module.
>
> [To summarize the 4 points above, I'd much rather see a more
> conventional organization where different parts are provided by
> different modules. I don't think the argument that inlining is needed
> for performance is actually valid, given that we have branch
> predictors and static keys, and the arch SIMD code is built as
> separate object files anyway]
I might have agreed before Spectre :(. Unfortunately, unless we do some magic, I think the code would look something like:
if (static_branch_likely(have_simd)) arch_chacha20();
...where arch_chacha20 is a *pointer*. And that will generate a retpoline and run very, very slowly. (I just rewrote some of the x86 entry code to eliminate one retpoline. I got a 5% speedup on some tests according to the kbuild bot.)
So, if we really wanted modules, we’d need a new dynamic patching mechanism.
I would suggest instead adding two boot (or debugfs) options:
simd=off: disables simd_get using a static branch.
crypto_chacha20_nosimd: Does what it sounds like.
next prev parent reply other threads:[~2018-09-17 14:52 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 1:08 [PATCH net-next v3 00/17] WireGuard: Secure Network Tunnel Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 01/17] asm: simd context helper API Jason A. Donenfeld
2018-09-12 6:14 ` Kevin Easton
2018-09-12 18:10 ` Jason A. Donenfeld
2018-09-13 5:03 ` Kevin Easton
2018-09-13 13:52 ` Jason A. Donenfeld
2018-09-13 13:53 ` Jason A. Donenfeld
2018-09-15 19:58 ` Andy Lutomirski
2018-09-15 20:01 ` Jason A. Donenfeld
2018-09-17 13:14 ` Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library Jason A. Donenfeld
2018-09-11 10:08 ` Ard Biesheuvel
2018-09-11 14:56 ` Greg Kroah-Hartman
2018-09-11 21:47 ` Eric Biggers
2018-09-11 22:02 ` Jason A. Donenfeld
2018-09-11 23:30 ` Andrew Lunn
2018-09-11 23:57 ` David Miller
2018-09-12 0:02 ` Jason A. Donenfeld
2018-09-17 4:09 ` Andy Lutomirski
2018-09-17 4:45 ` David Miller
2018-09-17 14:55 ` Andy Lutomirski
2018-09-17 14:59 ` Jason A. Donenfeld
2018-09-17 5:07 ` Jason A. Donenfeld
2018-09-17 14:53 ` Andy Lutomirski
2018-09-17 14:59 ` Jason A. Donenfeld
2018-09-17 16:24 ` Jason A. Donenfeld
2018-09-18 16:06 ` Ard Biesheuvel
2018-09-18 16:45 ` Jason A. Donenfeld
2018-09-17 5:26 ` Ard Biesheuvel
2018-09-17 14:51 ` Andy Lutomirski [this message]
2018-09-17 15:28 ` Jason A. Donenfeld
2018-09-17 16:06 ` Andy Lutomirski
2018-09-17 16:17 ` Jason A. Donenfeld
2018-09-17 15:31 ` Jason A. Donenfeld
2018-09-17 16:07 ` Andy Lutomirski
2018-09-17 16:16 ` Jason A. Donenfeld
2018-09-17 16:18 ` Andy Lutomirski
2018-09-18 0:56 ` Jason A. Donenfeld
2018-09-17 15:52 ` Jason A. Donenfeld
2018-09-18 4:21 ` Herbert Xu
2018-09-18 4:26 ` Jason A. Donenfeld
2018-09-18 18:53 ` Ard Biesheuvel
2018-09-18 20:36 ` Jason A. Donenfeld
2018-09-19 16:55 ` Ard Biesheuvel
2018-09-11 22:16 ` Andy Lutomirski
2018-09-11 22:18 ` Jason A. Donenfeld
2018-09-11 23:01 ` Andy Lutomirski
2018-09-12 0:01 ` Jason A. Donenfeld
2018-09-12 4:29 ` Jason A. Donenfeld
2018-09-11 21:22 ` Jason A. Donenfeld
2018-09-12 22:56 ` Ard Biesheuvel
2018-09-12 23:45 ` Andy Lutomirski
2018-09-13 5:41 ` Ard Biesheuvel
2018-09-13 14:32 ` Jason A. Donenfeld
2018-09-13 15:42 ` Ard Biesheuvel
2018-09-13 15:58 ` Jason A. Donenfeld
2018-09-14 6:15 ` Ard Biesheuvel
2018-09-14 9:53 ` Jason A. Donenfeld
2018-09-13 6:39 ` Milan Broz
2018-09-13 14:34 ` Jason A. Donenfeld
2018-09-13 15:26 ` Andy Lutomirski
2018-09-13 14:18 ` Jason A. Donenfeld
2018-09-13 15:07 ` Ard Biesheuvel
2018-09-13 14:15 ` Jason A. Donenfeld
2018-09-13 15:04 ` Ard Biesheuvel
2018-09-13 15:45 ` Jason A. Donenfeld
2018-09-11 22:08 ` Eric Biggers
2018-09-12 18:16 ` Jason A. Donenfeld
2018-09-12 18:19 ` Ard Biesheuvel
2018-09-12 18:34 ` Eric Biggers
2018-09-14 6:21 ` Ard Biesheuvel
2018-09-11 1:08 ` [PATCH net-next v3 03/17] zinc: ChaCha20 generic C implementation Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 04/17] zinc: ChaCha20 ARM and ARM64 implementations Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 05/17] zinc: ChaCha20 x86_64 implementation Jason A. Donenfeld
2018-09-11 8:22 ` Thomas Gleixner
2018-09-11 9:00 ` Samuel Neves
2018-09-11 9:09 ` Thomas Gleixner
2018-09-11 21:12 ` Jason A. Donenfeld
2018-09-11 21:27 ` Thomas Gleixner
2018-09-11 21:28 ` Jason A. Donenfeld
2018-09-11 21:48 ` Eric Biggers
2018-09-11 22:04 ` Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 06/17] zinc: ChaCha20 MIPS32r2 implementation Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 07/17] zinc: Poly1305 generic C implementation and selftest Jason A. Donenfeld
2018-09-11 1:17 ` Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 07/17] zinc: Poly1305 generic C implementations " Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 08/17] zinc: Poly1305 ARM and ARM64 implementations Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 09/17] zinc: Poly1305 x86_64 implementation Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 10/17] zinc: Poly1305 MIPS32r2 and MIPS64 implementations Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 11/17] zinc: ChaCha20Poly1305 construction and selftest Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 12/17] zinc: BLAKE2s generic C implementation " Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 13/17] zinc: BLAKE2s x86_64 implementation Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 14/17] zinc: Curve25519 generic C implementations and selftest Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 15/17] zinc: Curve25519 ARM implementation Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 16/17] zinc: Curve25519 x86_64 implementation Jason A. Donenfeld
2018-09-11 1:08 ` [PATCH net-next v3 17/17] net: WireGuard secure network tunnel Jason A. Donenfeld
2018-09-11 12:59 ` kbuild test robot
2018-09-11 20:53 ` Jason A. Donenfeld
2018-09-11 13:17 ` kbuild test robot
2018-09-11 21:05 ` Jason A. Donenfeld
2018-09-11 13:30 ` Andrew Lunn
2018-09-11 21:08 ` Jason A. Donenfeld
2018-09-11 21:55 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=35BC21D7-01F4-4F91-A7E9-8D15DE5B95D6@amacapital.net \
--to=luto@amacapital.net \
--cc=Jason@zx2c4.com \
--cc=andrew@lunn.ch \
--cc=ard.biesheuvel@linaro.org \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jeanphilippe.aumasson@gmail.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sneves@dei.uc.pt \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).