Re: Formally Verified Cryptographic Primitive Implementations
On Thu, Jan 18, 2018 at 04:42:10PM +0100, Jason A. Donenfeld wrote: > Hi folks, > > Writing crypto code is hard and sometimes scary. Especially on things > like elliptic curves and big number arithmetic, subtle but critical > bugs often sit around undetected for years. For this reason, I've been > working with some researchers at INRIA on using a formally verified > Curve25519 implementation inside WireGuard. This last week I had the > pleasure of talking with INRIA researchers and MIT researchers about > related efforts to automatically generate C implementations of > elliptic curve scalar multiplication from formal models. These models > produce proofs of correctness alongside machine-generated C. I've > taken these implementations and integrated them into WireGuard. > > For 64-bit Curve25519 multiplication, we're using HACL* [1], which has > specifications written in F* [2] and passes them through KreMLin [3] > for C generation. You can read the INRIA researchers paper [4] for > more information. Not only is this formally verified, but it is also > faster than our previous implementation (agl's donna-64). Mozilla's > NSS is doing something similar with HACL*. > > For 32-bit Curve25519 multiplication, we're using Fiat-Crypto [5], > which has specifications written in the abstract proof language Coq > [6], which also generates C code. These MIT researchers also have a > paper available [7]. This is faster than what we're using before > (agl's donna-32) and uses much less stack space, which means we no > longer need to kmalloc on platforms without separate irq stacks, which > is a nice boost. Google's BoringSSL is doing something similar with > Fiat-Crypto. > > Note that not _all_ of our cryptographic primitives are verified. > We're starting with replacing these two C implementations with > formally verified ones. Over time, we'll gradually replace remaining > existing implementations with formally verified counterparts. But > certainly, as this research is state of the art and quite new, the > work here is in the evolutionary category. > > Some speed results using my kbench9000 software [8] comparing the new > (top two lines) and old (bottom two lines), with turbo turned on: > > Xeon E3-1505M v5 [9] -- 14nm Skylake Laptop > hacl64: 109783 cycles per call > fiat32: 232710 cycles per call > donna64: 121794 cycles per call > donna32: 411588 cycles per call > > Core i5-5200U [10] -- 14 nm Broadwell Laptop > hacl64: 127001 cycles per call > fiat32: 253234 cycles per call > donna64: 137200 cycles per call > donna32: 438816 cycles per call > > I've updated the WireGuard formal verification site [11] to contain > this information. In a few days I expect to update this again with > some further exciting results in the same formal verification genre. > > Let me know if you have any questions. No questions, just a general, "Wow, this is great work!" It's wonderful to see this happen, thanks so much for pushing this forward. greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Trouble building WireGuard since December releases
On Mon, Jan 22, 2018 at 03:42:25PM +0100, Kevin wrote: > Hi all, > > I've been having trouble building WireGuard on Solus since its December > snapshots. Earlier snapshots (e.g. November) still build without a > problem, even on new kernels. Does this have to do with Solus kernel > builds, or am I overlooking something? > > user@t450s-solus ~/bin/WireGuard-0.0.20180118/src $ make debug > test -e include/generated/autoconf.h -a -e include/config/auto.conf || > ( \ > echo >&2; \ > echo >&2 " ERROR: Kernel configuration is invalid."; \ > echo >&2 " include/generated/autoconf.h or > include/config/auto.conf are missing.";\ > echo >&2 " Run 'make oldconfig && make prepare' on kernel src > to fix it."; \ Have you run 'make oldconfig' and 'make prepare' on the kernel source tree you are wanting to build the wireguard code against? thanks, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: gcc 8 warning
On Tue, Jan 30, 2018 at 09:38:59AM -0600, Bruno Wolff III wrote: > While there were a few other warnings about sibling call from callable > instruction with modified stack frame, the following looked more significant > if it isn't a gcc bug. > CC [M] /home/bruno/WireGuard/src/crypto/chacha20poly1305.o > In file included from ./include/linux/bitmap.h:9, > from ./include/linux/cpumask.h:12, > from ./arch/x86/include/asm/cpumask.h:5, > from ./arch/x86/include/asm/msr.h:11, > from ./arch/x86/include/asm/processor.h:21, > from ./arch/x86/include/asm/cpufeature.h:5, > from ./arch/x86/include/asm/thread_info.h:53, > from ./include/linux/thread_info.h:38, > from ./arch/x86/include/asm/preempt.h:7, > from ./include/linux/preempt.h:81, > from ./include/linux/spinlock.h:51, > from ./include/linux/seqlock.h:36, > from ./include/linux/time.h:6, > from ./include/linux/skbuff.h:19, > from ./include/linux/ip.h:20, > from /home/bruno/WireGuard/src/compat/compat.h:583, > from : > In function ‘memcpy’, >inlined from ‘poly1305_update’ at > /home/bruno/WireGuard/src/crypto/chacha20poly1305.c:549:4, >inlined from ‘chacha20poly1305_encrypt_sg’ at > /home/bruno/WireGuard/src/crypto/chacha20poly1305.c:673:4: > ./include/linux/string.h:344:9: warning: ‘__builtin_memcpy’ forming offset > [233, 272] is out of the bounds [0, 232] of object ‘poly1305_state’ with type > ‘struct poly1305_ctx’ [-Warray-bounds] > return __builtin_memcpy(p, q, size); > ^~~~ > /home/bruno/WireGuard/src/crypto/chacha20poly1305.c: In function > ‘chacha20poly1305_encrypt_sg’: > /home/bruno/WireGuard/src/crypto/chacha20poly1305.c:652:22: note: > ‘poly1305_state’ declared here I don't think the kernel builds properly with gcc8 just yet, so I wouldn't worry too much about stuff like this. Try building the 4.15 kernel release with gcc8 and see what happens :) thanks, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Wireguard backport to 2.6.3x kernels
On Wed, Jan 31, 2018 at 10:44:39AM +0200, John Wayne wrote: > Hi, > > I am working on a project that involves some old MIPS and ARM based > custom boards. > Current SDKs for these boards are pretty messy and there is no > documentation about the > patches that were applied to the 2.6.3x kernels in order make them > work on these boards. You can always just diff against the kernel.org release to see that. > So my question is how painfully will it be to port wireguard to the > even more ancient 2.6.3x kernels? You shouldn't be running any device based on those old kernels exposed to the network as they are probably totally insecure. Instead work on updating the kernel to something that was at least released in the past 5 years. Wireguard support is the least of your problems here :) good luck! greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Kernel lockup with (debian) 4.16.0-2-rt-amd64
On Wed, Jun 13, 2018 at 03:54:24PM +0100, Paul Hedderly wrote: > On Wed, 2018-06-13 at 15:52 +0200, Jason A. Donenfeld wrote: > > Hi Paul, > > > > I got an -rt kernel up and running, enabled a bunch of nice debugging > > options, and found a handful of problems, all of which were fixed by: > > https://git.zx2c4.com/WireGuard/commit/?id=0f05452d043d8d047cf5d7987f > > c2732b97d676e6 > > > > I realize the solution in that patch is a bit of a bummer, but at the > > very least it keeps things from breaking now. I'll see if I can > > improve it somewhere down the line. > > OUch. "So on sane kernels" I guess RT isn't sane then! > > Yea that performance hit is a nuisance, although in reality when I > really need RT I wont be doing much over a VPN... so I may have to suck > up to rebooting between kernels for a while. No big deal. Note, the -rt kernels _always_ run slower than a non-rt kernel. Real time is not "faster", it is only "deterministic". And it achieves this goal at the expense of performance, which is the only way it can be done. So I recommend just trying the "normal" kernel instead, odds are it will work just fine for you, unless you have some _very_ specific max-bound latency issues. thanks, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Ubuntu Error when trying to launch wireguard
On Fri, Jun 15, 2018 at 04:27:09PM -0400, Glen Bojsza wrote: > I am trying to run wireguard server on Bionic ARM processor. > > After following the installation instructions and creating my server config > file I get the following error when I run > > root@odroidxu4:~# wg-quick up wg0 > > Warning: `/etc/wireguard/wg0.conf' is world accessible You can fix the permissions on the file to not show this. > > [#] ip link add wg0 type wireguard > > RTNETLINK answers: Operation not supported You need to have the wireguard kernel module installed, are you sure you did that? thanks, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: compilation error on centos 7 kernels
On Mon, Jul 30, 2018 at 11:34:31AM +0800, Yousong Zhou wrote: > On Mon, 30 Jul 2018 at 11:29, Jason A. Donenfeld wrote: > > > > Update to the latest available centos kernel in the latest available > > centos release, and then after install WireGuard. If you're facing > > problems then, email a compilation log. > > Well, better add a note in the installation page about the > update-to-date kernel version expectation. The other thing is that > it's not always that feasible to switch kernel version in enterprise > managed environment But it is allowed to add random kernel modules to such an enviroment? You can't have it both ways, someone needs to work to fix such a horrible management policy that it sounds like you have. Good luck! greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Add Wireguard to Linux staging tree
On Tue, May 14, 2019 at 11:11:52AM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > Hi, > > it seems activities adding Wireguard to the Linux kernel have stopped > because of lack of audits and cryptographic weakness tests. That is not why it has stopped. > I suggest to offer adding Zinc/Wireguard to the Linux kernel staging > tree to make it easily available for testing and auditing. It's easy to test and audit today, adding it to staging is not going to help that out any, sorry. thanks, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Wiregaurd integration to private project
On Wed, Apr 17, 2019 at 01:02:36PM +0530, bhashkar prakash Singh wrote: > Hi, > > I want to integrate Wireguard to my confidential project. I see Wireguard > source code is under GPLv2, if I add any patch to Wiregaurd source code to > work with my confidentail project, do I need to publish complete source > code along with my project source code ? Please consult with your lawyers, they will know the answer to this question. If you do not have a lawyer, then just release the code to all of your project to be safe, as obviously there is no assets involved :) Good luck! greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
On Sun, Mar 29, 2020 at 08:16:43PM -0600, Jason A. Donenfeld wrote: > Hi folks, > > Earlier this evening, Linus released [1] Linus 5.6, which contains our > first release of WireGuard. This is quite exciting. It means that > kernels from here on out will have WireGuard built-in by default. And > for those of you who were scared away prior by the "dOnT uSe tHiS > k0de!!1!" warnings everywhere, you now have something more stable to > work with. > > The last several weeks of 5.6 development and stabilization have been > exciting, with our codebase undergoing a quick security audit [3], and > some real headway in terms of getting into distributions. Congrats on all of this, and thanks for sticking with it. greg k-h
Re: [PATCH AUTOSEL 5.9 26/55] wireguard: selftests: check that route_me_harder packets use the right sk
On Tue, Nov 10, 2020 at 01:29:41PM +0100, Jason A. Donenfeld wrote: > Note that this requires > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=46d6c5ae953cc0be38efd0e469284df7c4328cf8 > And that commit should be backported to every kernel ever, since the > bug is so old. Sasha queued this up to 5.4.y and 5.9.y, but it looks like it doesn't easily apply to older kernels. If you think that it's needed beyond that, I'll gladly take backported patches. thanks, greg k-h
Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
On Sun, Dec 13, 2020 at 03:58:20PM +0100, Miguel Ojeda wrote: > > The key here is "if nobody complains". I would argue that it is _your_ > > responsibility to do those builds, and not the reponsibility of others > > to do it for you. > > Testing allmodconfig for a popular architecture, agreed, it is due > diligence to avoid messing -next that day. > > Testing a matrix of configs * arches * gcc/clang * compiler versions? > No, sorry, that is what CI/-next/-rcs are for and that is where the > "if nobody complains" comes from. > > If you think building a set of code for a given arch/config/etc. is > particularly important, then it is _your_ responsibility to build it > once in a while in -next (as you have done). If it is not that > important, somebody will speak up in one -rc. If not, is anyone > actually building that code at all? > > Otherwise, changing core/shared code would be impossible. Please don't > blame the author for making a sensible change that will improve code > quality for everyone. > > > But, sure, your call. Please feel free to ignore my report. > > I'm not ignoring the report, quite the opposite. I am trying to > understand why you think reverting is needed for something that has > been more than a week in -next without any major breakage and still > has a long road to v5.11. Because if you get a report of something breaking for your change, you need to work to resolve it, not argue about it. Otherwise it needs to be dropped/reverted. Please fix. thanks, greg k-h
Re: Misalignment, MIPS, and ip_hdr(skb)->version
On Sat, Dec 10, 2016 at 11:18:14PM +0100, Dan Lüdtke wrote: > > > On 8 Dec 2016, at 05:34, Daniel Kahn Gillmor wrote: > > > > On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote: > >> Your custom protocol should be designed in a way you get an aligned ip > >> header. Most protocols of the IETF follow this mantra and it is always > >> possible to e.g. pad options so you end up on aligned boundaries for the > >> next header. > > > > fwiw, i'm not convinced that "most protocols of the IETF follow this > > mantra". we've had multiple discussions in different protocol groups > > about shaving or bloating by a few bytes here or there in different > > protocols, and i don't think anyone has brought up memory alignment as > > an argument in any of the discussions i've followed. > > > > If the trade-off is between 1 padding byte and 2 byte alignment versus > 3 padding bytes and 4 byte alignment I would definitely opt for 3 > padding bytes. I know how that waste feels like to a protocol > designer, but I think it is worth it. Maybe the padding/reserved will > be useful some day for an additional feature. Note, if you do do this (hint, I think it is a good idea), require that these reserved/pad fields always set to 0 for now, so that no one puts garbage in them and then if you later want to use them, it will be a mess. thanks, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Performance of Wireguard on Infiniband 40G
On Sun, May 14, 2017 at 11:55:52AM +0200, Baptiste Jonglez wrote: > On Sun, May 14, 2017 at 12:52:11AM +0200, Jason A. Donenfeld wrote: > > One small and unfortunate thought just occurred to me: the backporting > > to really old kernels I'm pretty sure is way less efficient than newer > > kernels on the RX, due to some missing core fast-path APIs in the old > > kernels. In particular, I had to wrap the UDP layer with some nasty > > hacks to get packets out, whereas newer kernels have an elegant API > > for that which integrates in the right place. Just a thought... I > > haven't actually done concrete measurements though. > > Good idea, I have redone the same setup with kernel 4.9.18 from > jessie-backports. > > TL;DR: when switching from kernel 3.16 to 4.9, wireguard has a 50% > performance gain in the most favourable case (large MTU). Also, iperf > seems generally faster than iperf3, most likely because iperf3 has no > multi-threading. 4.9 is 6 months old, I'd be curious if 4.11 is any faster given the rate of change in the network stack :) thanks, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: October, Paris, France - Meticulous In-person WireGuard Codebase Study Session
On Tue, Oct 10, 2017 at 01:19:45AM +0200, Jason A. Donenfeld wrote: > Hey folks, > > A few friends asked if I'd do a meticulous read through and > explanation, in person, of every line of the relatively short > WireGuard code base. We had done this at some point in 2015, before > the project was made public, and it took several highly intense hours > to study the whole thing, but was a fairly interesting time for all > (though undoubtedly mentally exhausting to the fullest). > > Now they're asking me to do it again. But this time I thought I'd > extend the session to a bit larger group. > > If anybody is in Paris during the next few weeks and would like to > attend, please let me know, either on list or off list, and we'll pick > a time and place and all meet up for several hours of intense study. Count me in, should be "fun" :) greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: October, Paris, France - Meticulous In-person WireGuard Codebase Study Session
On Tue, Oct 10, 2017 at 01:19:45AM +0200, Jason A. Donenfeld wrote: > Hey folks, > > A few friends asked if I'd do a meticulous read through and > explanation, in person, of every line of the relatively short > WireGuard code base. We had done this at some point in 2015, before > the project was made public, and it took several highly intense hours > to study the whole thing, but was a fairly interesting time for all > (though undoubtedly mentally exhausting to the fullest). > > Now they're asking me to do it again. But this time I thought I'd > extend the session to a bit larger group. > > If anybody is in Paris during the next few weeks and would like to > attend, please let me know, either on list or off list, and we'll pick > a time and place and all meet up for several hours of intense study. Count me in, should be "fun" :) greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Production usage of Wireguard
On Mon, Nov 06, 2017 at 09:41:18PM +, Ferris Ellis wrote: > Hello Wireguard mailing list! > > I have been very interested in the WireGuard project for a little while now > and am in the process of evaluating it. While benchmarks and code reviews > are useful, they don’t uncover many of the issues that can potentially wake > one up at 3am. I’d hunted around on the web for a while but wasn’t able to > find any articles on running WireGuard in a production environment. I know > the project is still young but was wondering if anyone on the mailing list > had started using WireGuard in production? And, if so, if they’d be willing > to share some details about their use case and experience? There are at least two companies offering Wireguard as a VPN service "commercially" right now, so it is being used in that manner already. But as "production environment" always means different things for different people, perhaps only you can answer this question? What would it take for _you_ to be comfortable with it in your network environment? thanks, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH 1/4] Add wireguard-go as submodule
On Tue, Nov 07, 2017 at 03:38:12PM +1100, Aurélien Chabot wrote: > Signed-off-by: Aurélien Chabot > --- > .gitmodules | 3 +++ > wireguard-go | 1 + > 2 files changed, 4 insertions(+) > create mode 100644 .gitmodules > create mode 16 wireguard-go > > diff --git a/.gitmodules b/.gitmodules > new file mode 100644 > index 000..c7957ea > --- /dev/null > +++ b/.gitmodules > @@ -0,0 +1,3 @@ > +[submodule "wireguard-go"] > + path = wireguard-go > + url = g...@github.com:trishika/wireguard-go.git Ugh, submodules are a pain in git, do you really want to do it this way? If so, why? I thought there was a "replacement" for submodules that was recommended to use instead. And I mention this because I have a submodule in a project I maintain, and I _always_ mess it up when I go to update it, and have to go read the documentation for how to do it properly. thanks, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Blind Operator Mode - A Defensive Rootkit
On Wed, Nov 15, 2017 at 04:18:54PM +0100, Jason A. Donenfeld wrote: > Hey folks, > > One of the strengths of WireGuard is its visibility. wg(8) is a tiny tool > that's easy to use, and you can configure and reconfigure everything at > runtime, examining the current configuration, and doing other various things. > It works well and for the most part people seem to like it. > > It turns out that this strength might actually be a weakness for some. A small > commercial VPN provider approached me recently about the fact they could see > the allowed IPs mapping easily with WireGuard, whereas with OpenVPN it was > hidden deep inside a process they didn't know how to debug. "Great," I > thought. Not so fast. They were concerned that when compelled to retrieve this > kind of information, they would no longer be able to claim, "we don't know > how," since WireGuard makes it so easy. So, they hired me for a day to develop > and open source a small solution for their unique use case and odd scenario. > > Before reading further, do you have the same bizarre requirement? Probably > not. In that likely case, please keep reading only under the scope of, > "something somebody else thought they needed, but I don't need myself." In > other words, don't use this code. > > Not wanting to hack up WireGuard or add configuration nobs -- or really > compromise any of what the project is about in response to these kinds of > requests -- I thought I'd write a small "defensive rootkit," which most > certainly kills both your kitten and your neighbor's parrot. > > It started out by just hooking the Netlink API to zero out the endpoints and > allowedips for each peer. Then I disabled tcpdump. Then I disabled /dev/mem, > /dev/kmem, /dev/port, /proc/kcore, and module loading. Things were looking > fairly clean, until I needed to add compatibility support for old kernels, and > then I reverted to some cthulhu-style x86 opcode parsing and writing to proc > from kernelspace and other atrocities. It seems to work relatively well on > the kernels I've tested, but of course there are no guarantees with this kind > of stuff. In any case, there aren't very many public rootkit examples like > this, so at the very least it might be an aid to a college freshman doing an > assignment for his "Intro to Computer Security" course. > > Keep in mind that there are several ways to subvert each and every defense > that this thing introduces. Several ways! All of the defenses! Subverted! For > that reason, you shouldn't use this if you're relying on the impossibility of > subversion. It's only meant as a confinement based on your own lack of > knowledge on how to subvert it. As you learn more, the software becomes less > effective. > > If it's of any interest, it's online here: > https://git.zx2c4.com/blind-operator-mode/about/ > https://git.zx2c4.com/blind-operator-mode/tree/blind-operator-mode.c > $ git clone https://git.zx2c4.com/blind-operator-mode/ > > Enjoy! Please don't run this monster at home! Ouch, my eyes!!! That's a great kernel module, thanks for publishing it, lots of fun things in there :) greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: disabling ipv6 with wg-quick
On Thu, Nov 16, 2017 at 11:04:49AM +0100, d...@fastmail.fm wrote: > Hi, > > Is there a way to disable ipv6 when using wg-quick? > > If I have the following line on my conf file: > > Address = xx.xx.x.39/32,::xxx:bb01::327/128 > > wg-quick will fail with the following error: > > ~ 2 wg-quick up mullvad-se2 > [#] ip link add mullvad-se2 type wireguard > [#] wg setconf mullvad-se2 /dev/fd/63 > [#] ip address add xx.xx.x.39/3 dev mullvad-se2 > [#] ip address add ::xxx:bb01::327/128 dev mullvad-se2 > RTNETLINK answers: Permission denied > > I have ip6 disabled in my system. > > Removing ::xxx:bb01::327/128 works, but wg-quick still sets ups > some ipv6 routes `ip -6 ..` etc. > > Is there a way to use ipv4 only with wg-quick? I placed the following in the [Interface] section of the configuration file to achieve this: PreUp = sysctl net.ipv6.conf.all.disable_ipv6=1 PostDown = sysctl net.ipv6.conf.all.disable_ipv6=0 It's a horrid hack, but does seem to work. hope this helps, greg k-h ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
On Thu, Jun 30, 2022 at 09:49:24PM +0200, Jason A. Donenfeld wrote: > Hi Kalesh, > > On Thu, Jun 30, 2022 at 07:12:29PM +, Kalesh Singh wrote: > > Systems that initiate frequent suspend/resume from userspace > > can make the kernel aware by enabling PM_USERSPACE_AUTOSLEEP > > config. > > > > This allows for certain sleep-sensitive code (wireguard/rng) to > > decide on what preparatory work should be performed (or not) in > > their pm_notification callbacks. > > > > This patch was prompted by the discussion at [1] which attempts > > to remove CONFIG_ANDROID that currently guards these code paths. > > > > [1] https://lore.kernel.org/r/20220629150102.1582425-1-...@lst.de/ > > > > Suggested-by: Jason A. Donenfeld > > Signed-off-by: Kalesh Singh > > Thanks, looks good to me. Do you have a corresponding Gerrit link to the > change adding this to the base Android kernel config? If so, have my > Ack: > > Acked-by: Jason A. Donenfeld Cool, I'll queue this up and also the CONFIG_ANDROID removal into my tree now, thanks all for working it out! greg k-h
