. Donenfeld ; Samuel
> Neves
> ; Dan Carpenter ; Arnd Bergmann
> ;
> Eric Biggers ; Andy Lutomirski ; Will
> Deacon
> ; Marc Zyngier ; Catalin Marinas
>
> Subject: Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for
> packet encryption
>
> On Fri, Sep
On Fri, Sep 27, 2019 at 2:58 AM Pascal Van Leeuwen
wrote:
>
> > I'd want to see wireguard in an end-to-end situation from the very
> > client hardware. So laptops, phones, desktops. Not the untrusted (to
> > me) hw in between.
> >
> I don't see why the crypto HW would deserve any less trust than,
t; Herbert Xu
> ; David Miller ; Greg KH
> ; Jason A . Donenfeld ; Samuel
> Neves
> ; Dan Carpenter ; Arnd Bergmann
> ; Eric Biggers ; Andy Lutomirski
> ;
> Will Deacon ; Marc Zyngier ; Catalin Marinas
>
> Subject: RE: [RFC PATCH 18/18] net: wireguard - switch to c
. Donenfeld ; Samuel
> Neves
> ; Dan Carpenter ; Arnd Bergmann
> ; Eric Biggers ; Andy Lutomirski
> ;
> Will Deacon ; Marc Zyngier ; Catalin Marinas
>
> Subject: Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for
> packet
> encryption
>
> On Thu, Se
On Fri, Sep 27, 2019 at 09:58:14AM +, Pascal Van Leeuwen wrote:
>
> But I can see the appeal of getting a "done" response on the _encrypt()/
> _decrypt() call and then being able to immediately continue processing
> the result data and having the async response handling separated off.
This is
. Donenfeld ; Samuel
> Neves
> ; Dan Carpenter ; Arnd Bergmann
> ; Eric Biggers ; Andy Lutomirski
> ;
> Will Deacon ; Marc Zyngier ; Catalin Marinas
>
> Subject: Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for
> packet
> encryption
>
> On Thu, S
> > That remark is just very stupid. The hardware ALREADY exists, and
> > more hardware is in the pipeline. Once this stuff is designed in, it
> > usually stays in for many years to come. And these are chips sold in
> > _serious_ quantities, to be used in things like wireless routers and
> > DSL, c
On Thu, Sep 26, 2019 at 09:37:16PM -0700, Andy Lutomirski wrote:
>
> Then what's up with the insistence on using physical addresses for so
> many of the buffers?
This happens to be what async hardware wants, but the main reason
why the crypto API has them is because that's what the network
stack f
On Thu, Sep 26, 2019 at 8:54 PM Herbert Xu wrote:
>
> On Thu, Sep 26, 2019 at 07:54:03PM -0700, Linus Torvalds wrote:
> >
> > Side note: almost nobody does this.
> >
> > Almost every single async interface I've ever seen ends up being "only
> > designed for async".
> >
> > And I think the reason i
> On Sep 26, 2019, at 6:38 PM, Linus Torvalds
> wrote:
>
> - let the caller know what the state size is and allocate the
> synchronous state in its own data structures
>
> - let the caller just call a static "decrypt_xyz()" function for xyz
> decryptrion.
>
> - if you end up doing it synchronousl
On Thu, Sep 26, 2019 at 9:01 PM Herbert Xu wrote:
>
> So there is really no async overhead in the crypto API AFAICS if
> you're always doing sync. What you see as overheads are probably
> the result of having to support multiple underlying algorithms
> (not just accelerations which can indeed be
On Thu, Sep 26, 2019 at 07:54:03PM -0700, Linus Torvalds wrote:
>
> There's no "read_potentially_async()" interface that just does the
> synchronous read for any cached portion of the data, and then delays
> just the IO parts and returns a "here, I gave you X bytes right now,
> use this cookie to w
On Thu, Sep 26, 2019 at 07:54:03PM -0700, Linus Torvalds wrote:
>
> Side note: almost nobody does this.
>
> Almost every single async interface I've ever seen ends up being "only
> designed for async".
>
> And I think the reason is that everybody first does the simply
> synchronous interfaces, an
On Thu, Sep 26, 2019 at 6:30 PM Linus Torvalds
wrote:
>
> And once you have that cookie, and you see "ok, I didn't get the
> answer immediately" only THEN do you start filling in things like
> callback stuff, or maybe you set up a wait-queue and start waiting for
> it, or whatever".
Side note: al
On Thu, Sep 26, 2019 at 5:15 PM Pascal Van Leeuwen
wrote:
>
> But even the CPU only thing may have several implementations, of which
> you want to select the fastest one supported by the _detected_ CPU
> features (i.e. SSE, AES-NI, AVX, AVX512, NEON, etc. etc.)
> Do you think this would still be e
On Thu, Sep 26, 2019 at 5:15 PM Pascal Van Leeuwen
wrote:
>
> That remark is just very stupid. The hardware ALREADY exists, and
> more hardware is in the pipeline. Once this stuff is designed in, it
> usually stays in for many years to come. And these are chips sold in
> _serious_ quantities, to b
. Donenfeld ; Samuel
> Neves
> ; Dan Carpenter ; Arnd Bergmann
> ;
> Eric Biggers ; Andy Lutomirski ; Will
> Deacon
> ; Marc Zyngier ; Catalin Marinas
>
> Subject: Re: [RFC PATCH 18/18] net: wireguard - switch to crypto API for
> packet encryption
>
&
On Thu, Sep 26, 2019 at 2:40 AM Pascal Van Leeuwen
wrote:
>
> While I agree with the principle of first merging Wireguard without
> hooking it up to the Crypto API and doing the latter in a later,
> separate patch, I DONT'T agree with your bashing of the Crypto API
> or HW crypto acceleration in g
On Thu, 26 Sep 2019 at 13:06, Ard Biesheuvel wrote:
>
> On Thu, 26 Sep 2019 at 00:15, Linus Torvalds
> wrote:
> >
> > On Wed, Sep 25, 2019 at 9:14 AM Ard Biesheuvel
> > wrote:
> > >
> > > Replace the chacha20poly1305() library calls with invocations of the
> > > RFC7539 AEAD, as implemented by t
On Thu, 26 Sep 2019 at 00:15, Linus Torvalds
wrote:
>
> On Wed, Sep 25, 2019 at 9:14 AM Ard Biesheuvel
> wrote:
> >
> > Replace the chacha20poly1305() library calls with invocations of the
> > RFC7539 AEAD, as implemented by the generic chacha20poly1305 template.
>
> Honestly, the other patches l
> >
> > Replace the chacha20poly1305() library calls with invocations of the
> > RFC7539 AEAD, as implemented by the generic chacha20poly1305 template.
>
> Honestly, the other patches look fine to me from what I've seen (with
> the small note I had in a separate email for 11/18), but this one I
>
On Wed, Sep 25, 2019 at 3:15 PM Linus Torvalds
wrote:
>
> I don't really have a dog in this fight, but on the whole I really
> liked the series. But this 18/18 raised my heckles, and I think I
> understand why it might raise the heckles of the wireguard people.
To be honest, I guess I _do_ have a
On Wed, Sep 25, 2019 at 9:14 AM Ard Biesheuvel
wrote:
>
> Replace the chacha20poly1305() library calls with invocations of the
> RFC7539 AEAD, as implemented by the generic chacha20poly1305 template.
Honestly, the other patches look fine to me from what I've seen (with
the small note I had in a s
23 matches
Mail list logo
