linux-kernel - Re: [PATCH RFC net-next] net: WireGuard secure network tunnel

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: <CAHmME9rmFw7xGKNMURBUSiezbsBEikOPiJxtEu=i2Quzf+JNDg@mail.gmail.com>
Date:   Thu, 21 Nov 2019 12:07:28 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Toke Høiland-Jørgensen <thoiland@...hat.com>
Cc:     Netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH RFC net-next] net: WireGuard secure network tunnel

On Thu, Nov 21, 2019 at 11:29 AM Toke Høiland-Jørgensen
<thoiland@...hat.com> wrote:
> Could you please get rid of the "All Rights Reserved" (here, and
> everywhere else)? All rights are *not* reserved: this is licensed under
> the GPL. Besides, that phrase is in general dubious at best:
> https://en.wikipedia.org/wiki/All_rights_reserved

I've seen people make arguments for this in both ways, and code from
major corporation enters the kernel every day bearing that line, which
means lawyers of important kernel contributors disagree with you.
Neither one of us are lawyers. Lacking any wide scale precedent for
such changes, or the expertise to even be properly persuaded in any
direction, I follow the advice of my council to stick to the norm and
not to mess with copyright headers.

I think there are some Linux Foundation mailing lists that have
license lawyers on them, relating to SPDX mainly. Maybe we can ask
there?

> > +     MAX_QUEUED_INCOMING_HANDSHAKES = 4096, /* TODO: replace this with DQL */
> > +     MAX_STAGED_PACKETS = 128,
> > +     MAX_QUEUED_PACKETS = 1024 /* TODO: replace this with DQL */
>
> Yes, please (on the TODO) :)
>
> FWIW, since you're using pointer rings I think the way to do this is
> probably to just keep the limits in place as a maximum size, and then
> use DQL (or CoDel) to throttle enqueue to those pointer rings instead of
> just letting them fill.
>
> Happy to work with you on this (as I believe I've already promised), but
> we might as well do that after the initial version is merged...

I've actually implemented this a few times, but DQL always seems too
slow to react properly, and I haven't yet been able to figure out
what's happening. Let's indeed work on this after the initial version
is merged. I think this change, and several more like it, will be the
topic of some interesting discussions. But that doesn't need to happen
/now/ I don't think.