Re: Any progress on R_ARM_THM_JUMP11 issues?
Looks as though in the end this is a binutils bug with -fvisibility=hidden. Details on https://sourceware.org/bugzilla/show_bug.cgi?id=12532#c9
Re: wireguard: unknown relocation: 102 [ARMv7 Thumb-2]
Hey Rui, I fixed it! It turned out to be caused by -fvisibility=hidden undoing the effect of the binutils fix from a while back. Here's the patch that makes the problem go away: https://git.zx2c4.com/wireguard-linux-compat/commit/?id=178cdfffb99f2fd6fb4a5bfd2f9319461d93f53b This will be in the next compat release. Jason
Re: Kernel Panic after updating Kernel
On Thu, Jun 18, 2020 at 2:10 PM Jean-Denis Girard wrote: > > Le 18/06/2020 à 09:48, Jason A. Donenfeld a écrit : > > I am unable to reproduce this issue with vmxnet3. However, as I noted > > earlier, your wireguard version seems old. Try updating everything at > > once, and then see. > > yum updated to wireguard-dkms.noarch 1:1.0.20200611-1.el7 > > By the way, yum complains : > Error! Could not locate dkms.conf file. > File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist. > > I cannot reboot now, I will let you know how it goes later. Oh, in your case, you appear to be using the dkms package instead of the elrepo package.
Re: Kernel Panic after updating Kernel
Le 18/06/2020 à 09:48, Jason A. Donenfeld a écrit : > I am unable to reproduce this issue with vmxnet3. However, as I noted > earlier, your wireguard version seems old. Try updating everything at > once, and then see. yum updated to wireguard-dkms.noarch 1:1.0.20200611-1.el7 By the way, yum complains : Error! Could not locate dkms.conf file. File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist. I cannot reboot now, I will let you know how it goes later. Thanks, -- Jean-Denis Girard SysNux Systèmes Linux en Polynésie française https://www.sysnux.pf/ Tél: +689 40.50.10.40 / GSM: +689 87.797.527 signature.asc Description: OpenPGP digital signature
Re: Kernel Panic after updating Kernel
On 18/06/2020 05:31, dx...@xirihosting.com wrote: 6) Yum operations trigger a lot of exclutions for elrepo, but nothing seems wireguard related: Not related to this bug, so for information only. The following is caused by a difference in the way CentOS compose their repositories over RHEL: https://bugs.centos.org/view.php?id=15476 The solution is to enable the CentOS vault repo which will allow CentOS to more closely match RHEL behaviour and prevent the exclusions notified below. This is documented in /usr/share/doc/yum-plugin-elrepo-7.5.1/README Loaded plugins: changelog, elrepo, fastestmirror, priorities, tsflags, universal-hooks Loading mirror speeds from cached hostfile * EA4: 208.100.0.204 * cpanel-addons-production-feed: 208.100.0.204 * cpanel-plugins: 208.100.0.204 * elrepo: elrepo.0m3n.net * epel: mirror.csis.ysu.edu [elrepo]: excluding package: kmod-3c59x-0.0-3.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-8188eu-4.1.4_6773.20130222-4.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-8188eu-4.1.4_6773.20130222-5.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-8188eu-5.2.2.4-1.20190907git.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-a2818-1.20-1.el7.elrepo.x86_64 [elrepo]: excluding package: kmod-a3818-1.6.0-1.el7.elrepo.x86_64 [elrepo]: excluding package: kmod-a3818-1.6.2-1.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-aacraid-1.2.1-5.el7.elrepo.x86_64 [elrepo]: excluding package: kmod-aic7xxx-7.0-3.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-ar5523-0.0-8.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-ar5523-0.0-9.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-ath5k-0.0-12.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-cassini-1.6-2.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-cciss-3.6.26-5.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-cciss-3.6.26-6.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-cciss-3.6.26-7.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-drbd84-8.4.11-1.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-drbd84-8.4.11-1.1.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-drbd90-9.0.14-1.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-drbd90-9.0.16-1.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-drbd90-9.0.20-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-e100-3.5.24-3.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-ecryptfs-0.1-1.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-forcedeth-0.64-3.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-fpga-mgr-0.0-1.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-hfs-0.0-4.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-hfsplus-0.0-5.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-i2c-i801-0.0-4.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-i2c-i801-0.0-5.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-i2c-i801-0.0-6.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-ixgb-1.0.135-4.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-ixgbe-5.5.5-1.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-ixgbe-5.6.3-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-ixgbe-5.6.3-2.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-joydev-0.0-4.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-mt7601u-4.14.108-1.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-mt7601u-4.14.108-2.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-nct6775-0.0-4.20180327git.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-nct6775-0.0-5.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-ne2k-pci-1.03-4.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-netatop-0.3-4.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-netatop-2.0-1.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-niu-1.1-2.el7_5.elrepo.x86_64 [elrepo]: excluding package: kmod-nvidia-440.44-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: nvidia-x11-drv-libs-440.44-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: nvidia-x11-drv-libs-440.44-1.el7_7.elrepo.i686 [elrepo]: excluding package: nvidia-x11-drv-440.44-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-nvidia-440.59-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: nvidia-x11-drv-libs-440.59-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: nvidia-x11-drv-440.59-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: nvidia-x11-drv-libs-440.59-1.el7_7.elrepo.i686 [elrepo]: excluding package: kmod-nvidia-440.64-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: nvidia-x11-drv-libs-440.64-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: nvidia-x11-drv-libs-440.64-1.el7_7.elrepo.i686 [elrepo]: excluding package: nvidia-x11-drv-440.64-1.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-nvidia-340xx-340.107-2.el7_6.elrepo.x86_64 [elrepo]: excluding package: kmod-nvidia-340xx-340.107-3.el7_7.elrepo.x86_64 [elrepo]: excluding package: kmod-nvidia-390xx-390.116-1.el7_6.elrepo.x86_64 [elrepo]:
Re: Any progress on R_ARM_THM_JUMP11 issues?
Hi again, Jason, [Adding a bit of extra context for linux-arm-kernel.] On Wed, 17 Jun 2020 at 22:02, Jason A. Donenfeld wrote: > > But I am wondering: has anybody heard about toolchain progress toward > fixing this? Couldn't the compiler reorder functions itself more > intelligently? Or avoid emitting the B in the case that the jump will > be too far? Or does nobody care much about 32-bit ARM these days so > it's just fallen by the wayside and > CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y is the best we've got? Or > something else? The thing is, CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y implies -fno-optimize-sibling-calls, which seems like a big hammer to work around a toolchain bug. Now, this bug has been reported in Linaro binutils as early as February 2011 [1] and the upstream bug has been deemed fixed in binutils 2.22 [2], two months later. I usually don't build modular kernels, but in OpenWrt we don't have a choice due to the compat backports of wireless drivers. What strikes me as odd is the fact that without CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11, all kernel modules load and run just fine, except for WireGuard. Anyway, I completely agree that if it's a toolchain bug, the toolchain must be fixed. Out of curiosity, I also compared the vmlinux sizes in both modes (OpenWrt kernel, Linux 5.4.46 with my Turris Omnia configuration, gcc 9.3.0 and binutils 2.34). Pure ARM: 24243392 bytes Thumb-2 (with CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y): 22102716 bytes A 2 MiB smaller code footprint is nothing to sneeze at. [1] https://bugs.launchpad.net/binutils-linaro/+bug/725126 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=12532 Cheers, Rui
Wireguard Identity Rotation
I'm looking for a nice way to rotate keypairs with Wireguard. How much time do you have to update the initiator and responder with new keypairs before handshakes fail? If I understood the whitepaper correctly, sessions aren't immediately invalid when you change a peers identity. Instead, you have up to 5 minutes to update both sides, or else the session keys are exhausted. Is this correct? Thanks, John
Re: [PATCH] wg-quick: add restart command
Thanks for your comments! I really like the systemctl reload approach. My main intention with this patchset was to add this feature to wg-quicks arsenal because (at least for me) it's the most obvious approach. I mainly use `wg-quick down wg0 && wg0 up wg0`, I think you guys see where I'm coming from. I haven't dealt with systemd units yet, but I can certainly look into it and submit a corresponding patch soon. Am Mi., 17. Juni 2020 um 10:32 Uhr schrieb Eric Light : > > Oh hey that sounds like a great way to do it. Seems like it'd be simpler > than this patch set as well, which is always good. > > E > > > Q: Why is this email five sentences or less? > A: http://five.sentenc.es > > On Wed, 17 Jun 2020, at 20:19, Jason A. Donenfeld wrote: > > On Wed, Jun 17, 2020 at 2:17 AM Eric Light wrote: > > > > > > As a purely Debian user, the 'service x restart' pattern is far more > > > memorable than the syncconf method. I know personal preference isn't a > > > great reason to add a knob, but Garrit's method is probably going to be > > > much more familiar to many users. > > > > For users who want service management patterns like that, it'd > > certainly be possible to map the wg-quick strip stuff to `systemctl > > reload wg-quick@wg0.service`, for that purpose. Maybe that's something > > we should consider? > >
Re: [PATCH v4 0/3] mm, treewide: Rename kzfree() to kfree_sensitive()
On 6/16/20 9:53 PM, Joe Perches wrote: > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote: >> v4: >> - Break out the memzero_explicit() change as suggested by Dan Carpenter >> so that it can be backported to stable. >> - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for >> now as there can be a bit more discussion on what is best. It will be >> introduced as a separate patch later on after this one is merged. > > To this larger audience and last week without reply: > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ > > Are there _any_ fastpath uses of kfree or vfree? > > Many patches have been posted recently to fix mispairings > of specific types of alloc and free functions. I've prepared a coccinelle script to highlight these mispairings in a function a couple of days ago: https://lkml.org/lkml/2020/6/5/953 I've listed all the fixes in the commit message. Not so many mispairings actually, and most of them are harmless like: kmalloc(E) -> kvfree(E) However, coccinelle script can't detect cross-functions mispairings, i.e. allocation in one function, free in another funtion. Thanks, Denis
Re: Kernel Panic after updating Kernel
On Thu, Jun 18, 2020 at 10:48 AM Jean-Denis Girard wrote: > For what it's worth, I seem to have the same problem on a CentOS-7 > virtual machine hosted on VMware with vmxnet3. It has been working fine > since installed in 2017, but does lock up after upgrading to > kernel-3.10.0-1127.8.2.el7.x86_64 or kernel-3.10.0-1127.10.1.el7.x86_64. > The VM is now running fine on kernel-3.10.0-1062.18.1.el7.x86_64. I am unable to reproduce this issue with vmxnet3. However, as I noted earlier, your wireguard version seems old. Try updating everything at once, and then see.
Re: Kernel Panic after updating Kernel
On Thu, Jun 18, 2020 at 10:48 AM Jean-Denis Girard wrote: > [ 17.886512] wireguard: WireGuard 1.0.20200520 loaded. See > www.wireguard.com for information. 20200520 is old. Have you tried the newer version yet?
Re: Kernel Panic after updating Kernel
Hi list, Le 17/06/2020 à 19:53, Jason A. Donenfeld a écrit : > Hmm, still not able to reproduce. > > Are you sure you're running the latest up to date module? Try > uninstalling kmod-wireguard and reinstalling? > > What driver is your ethernet NIC using? > For what it's worth, I seem to have the same problem on a CentOS-7 virtual machine hosted on VMware with vmxnet3. It has been working fine since installed in 2017, but does lock up after upgrading to kernel-3.10.0-1127.8.2.el7.x86_64 or kernel-3.10.0-1127.10.1.el7.x86_64. The VM is now running fine on kernel-3.10.0-1062.18.1.el7.x86_64. [4.751926] NET: Registered protocol family 40 [5.008840] vmxnet3 :03:00.0 ens160: intr type 3, mode 0, 3 vectors allocated [5.009298] vmxnet3 :03:00.0 ens160: NIC Link is Up 1 Mbps [9.148571] vmxnet3 :13:00.0 ens224: intr type 3, mode 0, 3 vectors allocated [9.149062] vmxnet3 :13:00.0 ens224: NIC Link is Up 1 Mbps [ 13.318360] vmxnet3 :1b:00.0 ens256: intr type 3, mode 0, 3 vectors allocated [ 13.318908] vmxnet3 :1b:00.0 ens256: NIC Link is Up 1 Mbps [ 17.704052] FS-Cache: Loaded [ 17.823986] FS-Cache: Netfs 'nfs' registered for caching [ 17.837062] Key type dns_resolver registered [ 17.867211] NFS: Registering the id_resolver key type [ 17.867218] Key type id_resolver registered [ 17.867220] Key type id_legacy registered [ 17.879846] wireguard: module verification failed: signature and/or required key missing - tainting kernel [ 17.886512] wireguard: WireGuard 1.0.20200520 loaded. See www.wireguard.com for information. [ 17.886514] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved. [ 564.297446] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) Thanks, -- Jean-Denis Girard SysNux Systèmes Linux en Polynésie française https://www.sysnux.pf/ Tél: +689 40.50.10.40 / GSM: +689 87.797.527 signature.asc Description: OpenPGP digital signature
