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]
Date:   Fri, 26 Oct 2018 01:47:21 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH net-next v8 28/28] net: WireGuard secure network tunnel

Hi Andrew,

On Fri, Oct 26, 2018 at 12:44 AM Andrew Lunn <andrew@...n.ch> wrote:
> Out of tree is important here. To some degree, mainline does not care
> about out of tree drivers. Putting in a bandaid for them does not help
> get them fixed.
>
> I would drop this bandaid. If the Android community decides to move
> wireguard from mainline into their fork, they can put the bandaid back
> in again, or get the driver fixed.

No out-of-tree is really not important here, and sorry if mentioning
that in my explanation was distracting and caused you to
misunderstand. The issue isn't the crazy wireless driver; the issue is
that suspend on Android happens all the time, and the entire Android
way of using Linux is centered around non-stop suspending, with
triggers to wake up (wifi drivers, for example, like the out-of-tree
qcacld one, but presumably in tree ones too), and ways of controlling
when it goes to sleep (screen blanking, wakelocks, etc). The Android
model of Linux revolves around this, and hence the suspend semantics
for WireGuard respect this model and adjust accordingly, using the
appropriate CONFIG_ANDROID to determine which model we're operating
under. This is not a bandaid, and it doesn't have to do with forks of
the Linux kernel.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ