Advising in packages to load new module or reboot

Advising in packages to load new module or reboot

[Jason A. Donenfeld]

Hey guys,

I've noticed that around 60% of emails and IRC messages I get about
WireGuard issues are due to:

1) forgetting to `rmmod wireguard && modprobe wireguard` after updating
2) installing new kernel headers, removing old kernel headers, updating
   wireguard, and then having the module built for the newer kernel and
   forgetting to reboot
3) not having any headers installed

I don't really know the best generic solution for (3), since different
distros and distro-derivatives (armbian,raspian,archlinuxarm,etc) seem
to express these dependencies in different ways, or not at all. But I do
have an idea to pretty easily address (1) and (2). I've just added the
below to the Gentoo ebuild:

+ if [[ $(uname -r) != "${KV_FULL}" ]]; then
+         ewarn
+         ewarn "You have just built WireGuard for kernel ${KV_FULL}, yet the currently running"
+         ewarn "kernel is $(uname -r). If you intend to use this WireGuard module on the currently"
+         ewarn "running machine, you will first need to reboot it into the kernel ${KV_FULL}, for"
+         ewarn "which this module was built."
+         ewarn
+ elif [[ -f /sys/module/wireguard/version ]] && \
+      old="$(< /sys/module/wireguard/version)" && \
+      new="$(modinfo -F version "${ROOT}/lib/modules/${KV_FULL}/net/wireguard.ko" 2>/dev/null)" && \
+      [[ $old != "$new" ]]; then
+         ewarn
+         ewarn "You appear to have just upgraded WireGuard from version v$old to v$new."
+         ewarn "However, the old version is still running on your system. In order to use the"
+         ewarn "new version, you will need to remove the old module and load the new one. As"
+         ewarn "root, you can accomplish this with the following commands:"
+         ewarn
+         ewarn "    # rmmod wireguard"
+         ewarn "    # modprobe wireguard"
+         ewarn
+         ewarn "Do note that doing this will remove current WireGuard interfaces, so you may want"
+         ewarn "to gracefully remove them yourself prior."
+         ewarn
+ fi

There's a bit of Gentoo-specific stuff in there, but the general idea is
that I first check to see if the module is being built for the current
kernel or a different one, and then I check whether an older module is
loaded than the one just built. It might be slightly trickier to
accomplish this with DKMS, but I think still it's possible.

Any thoughts on this pattern?

Jason

Re: Advising in packages to load new module or reboot

[Jonathon Fernyhough]

[-- Attachment #1.1: Type: text/plain, Size: 696 bytes --]

On 09/08/17 00:16, Jason A. Donenfeld wrote:
> 3) not having any headers installed
> 
...
> 
> Any thoughts on this pattern?
> 

I suspect this would be a packaging issue - packages that build modules
should depend on whatever headers (etc.) that are necessary for building
the module. I can't think of any distro where that isn't the norm, and
it's not normally up to the upstream developers to check those things
(they provide the software source, packagers provide something that
works specifically with the distro).

OTOH, if people are installing from source and expecting to be able to
build a kernel module without kernel headers... that's a user-education
issue.

J


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Advising in packages to load new module or reboot

[Jason A. Donenfeld]

On Wed, Aug 9, 2017 at 1:27 AM, Jonathon Fernyhough
<jonathon.fernyhough@york.ac.uk> wrote:
> On 09/08/17 00:16, Jason A. Donenfeld wrote:
>> 3) not having any headers installed
>>
> ...
>>
>> Any thoughts on this pattern?
>>
>
> I suspect this would be a packaging issue - packages that build modules
> should depend on whatever headers (etc.) that are necessary for building
> the module. I can't think of any distro where that isn't the norm, and
> it's not normally up to the upstream developers to check those things
> (they provide the software source, packagers provide something that
> works specifically with the distro).

Right. So this is all item (3) stuff. I agree with you there --
packages need to express the dependencies in whatever way they can.
That might mean printing nice messages if the correct dependency isn't
obvious.

For (1) and (2), though, what do you think of the warning I've added
to Gentoo? That's what I meant by asking for thoughts on "this
pattern" -- the whole thing with comparing running kernel and
compiled-for-kernel and comparing loaded-module-version and
compiled-module-version.

Re: Advising in packages to load new module or reboot

[Bzzzz]

On Wed, 9 Aug 2017 01:30:50 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> That might mean printing nice messages if the correct dependency isn't
> obvious.
> 
> For (1) and (2), though, what do you think of the warning I've added
> to Gentoo? That's what I meant by asking for thoughts on "this
> pattern" -- the whole thing with comparing running kernel and
> compiled-for-kernel and comparing loaded-module-version and
> compiled-module-version.

I found something that _may_ help you, it's an old bug report on DKMS.
As far as I understand it, it is DKMS' work to issue a warning:
https://github.com/dell/dkms/issues/14

Jean-Yves

Re: Advising in packages to load new module or reboot

[Jonathon Fernyhough]

[-- Attachment #1.1: Type: text/plain, Size: 1363 bytes --]

On 09/08/17 00:30, Jason A. Donenfeld wrote:
> For (1) and (2), though, what do you think of the warning I've added
> to Gentoo? That's what I meant by asking for thoughts on "this
> pattern" -- the whole thing with comparing running kernel and
> compiled-for-kernel and comparing loaded-module-version and
> compiled-module-version.
> 

Ah, righty. From my admittedly limited experience that seems fine - for
example, from the Debian/Ubuntu virtualbox-dkms package
(vboxdrv/Makefile, #192):

>  # kernel base directory
>  ifndef KERN_DIR
>   # build for the current kernel, version check
>   KERN_DIR := /lib/modules/$(shell uname -r)/build
>   ifneq ($(shell if test -d $(KERN_DIR); then echo yes; fi),yes)
>    KERN_DIR := /usr/src/linux
>    ifneq ($(shell if test -d $(KERN_DIR); then echo yes; fi),yes)
>     $(error Error: unable to find the sources of your current Linux kernel. \
> 	           Specify KERN_DIR=<directory> and run Make again)
>    endif
>    $(warning Warning: using /usr/src/linux as the source directory of your \
>                       Linux kernel. If this is not correct, specify \
> 		      KERN_DIR=<directory> and run Make again.)
>   endif
>  else
>   ifneq ($(shell if test -d $(KERN_DIR); then echo yes; fi),yes)
>    $(error Error: KERN_DIR does not point to a directory)
>   endif
>  endif


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Advising in packages to load new module or reboot

[Egbert Verhage]

Hey Jason,

Ow, that it is a common problem.
I think your patch is a nice updated.

So I got some time left and build a patch (pull request) on github
here: https://github.com/EggieCode/wireguard-ppa/pull/24

Let me known what you think.

Greetz,
Egbert

On Wed, 2017-08-09 at 01:16 +0200, Jason A. Donenfeld wrote:
> Hey guys,
> 
> I've noticed that around 60% of emails and IRC messages I get about
> WireGuard issues are due to:
> 
> 1) forgetting to `rmmod wireguard && modprobe wireguard` after
> updating
> 2) installing new kernel headers, removing old kernel headers,
> updating
>    wireguard, and then having the module built for the newer kernel
> and
>    forgetting to reboot
> 3) not having any headers installed
> 
> I don't really know the best generic solution for (3), since
> different
> distros and distro-derivatives (armbian,raspian,archlinuxarm,etc)
> seem
> to express these dependencies in different ways, or not at all. But I
> do
> have an idea to pretty easily address (1) and (2). I've just added
> the
> below to the Gentoo ebuild:
> 
> + if [[ $(uname -r) != "${KV_FULL}" ]]; then
> +         ewarn
> +         ewarn "You have just built WireGuard for kernel ${KV_FULL},
> yet the currently running"
> +         ewarn "kernel is $(uname -r). If you intend to use this
> WireGuard module on the currently"
> +         ewarn "running machine, you will first need to reboot it
> into the kernel ${KV_FULL}, for"
> +         ewarn "which this module was built."
> +         ewarn
> + elif [[ -f /sys/module/wireguard/version ]] && \
> +      old="$(< /sys/module/wireguard/version)" && \
> +      new="$(modinfo -F version
> "${ROOT}/lib/modules/${KV_FULL}/net/wireguard.ko" 2>/dev/null)" && \
> +      [[ $old != "$new" ]]; then
> +         ewarn
> +         ewarn "You appear to have just upgraded WireGuard from
> version v$old to v$new."
> +         ewarn "However, the old version is still running on your
> system. In order to use the"
> +         ewarn "new version, you will need to remove the old module
> and load the new one. As"
> +         ewarn "root, you can accomplish this with the following
> commands:"
> +         ewarn
> +         ewarn "    # rmmod wireguard"
> +         ewarn "    # modprobe wireguard"
> +         ewarn
> +         ewarn "Do note that doing this will remove current
> WireGuard interfaces, so you may want"
> +         ewarn "to gracefully remove them yourself prior."
> +         ewarn
> + fi
> 
> There's a bit of Gentoo-specific stuff in there, but the general idea
> is
> that I first check to see if the module is being built for the
> current
> kernel or a different one, and then I check whether an older module
> is
> loaded than the one just built. It might be slightly trickier to
> accomplish this with DKMS, but I think still it's possible.
> 
> Any thoughts on this pattern?
> 
> Jason

Re: Advising in packages to load new module or reboot

[Daniel Kahn Gillmor]

On Wed 2017-08-09 13:16:45 +0200, Egbert Verhage wrote:

> Ow, that it is a common problem.
> I think your patch is a nice updated.
>
> So I got some time left and build a patch (pull request) on github
> here: https://github.com/EggieCode/wireguard-ppa/pull/24

thanks for writing this notification, Jason, and for including it in
your ubuntu ppa, Egbert.

I'm wondering whether the advice it gives is correct and thorough enough
for non-gentoo users, though.

If i "rmmod wireguard && modprobe wireguard" won't my configuration be
lost?  You point out that you might want to tear them down gracefully
first.  But then no mention of needing to bring them up again later?

Aren't there additional commands that the admin will have to do to have
a *functional* wireguard implementation, and those commands might
differe based on their userspace layout/configuration/policy?

The simplest instruction for the upgrade (which is probably offensive to
all of us here) is to say "you should reboot your machine for the
wireguard upgrade to take effect" -- that gets us the benefit of any
userspace wireguard configuration that happens during system
initialization to happen, without having to guess/poke/prod at the
user's networking config while live.

Also, for an administrator doing this over ssh, we might want to warn
them that taking these steps will lock them out if they're connecting
via ssh on top of wireguard, right?

      --dkg