missing step from installation instructions

[AndySchroder]

I am on ubuntu 18.04 and can-isotp did not work unless I also ran sudo depmod -a after installing.

You may want to add this step to the installation instructions.

It's possible that this was required as a byproduct of #7 , which I resolved by generating a signing key. I am not sure if the initial install attempts without the signing key created a messed up install that was not completely overwritten by subsequent install attempts with the signing key present (and I don't know how to uninstall, so I can't try again to be sure!).

Either way, I don't think running sudo depmod -a hurts anything, so why not add it to the install instructions?

[hartkopp]

Are you sure?
make modules_install automatically runs depmod and I can find
extra/net/can/can-isotp.ko: kernel/net/can/can.ko
at the end of /lib/modules/5.6.0-rc1/modules.dep

[AndySchroder]

What can I do to uninstall and re-test? I'm not sure how to uninstall.

[hartkopp]

I would just remove extra/net/can/can-isotp.ko, run depmodagain and then grep for 'isotp' in modules.dep if is really removed.
But I don't know if this is the 'right way'(TM) :-)

[JL2010]

Hi @AndySchroder - can you please post the full installation instructions that worked for you? I too am having issues installing. I got past the self signing step by generating signing keys. But then I get this error on the insmod step:

insmod: ERROR: could not insert module ./net/can/can-isotp.ko: Operation not permitted

Not sure if that was related to what you experienced. Thanks.

[hartkopp]

Operation not permitted -> you need to be root (admin user) ; alternatively use sudo insmod ...

[JL2010]

@hartkopp Yes, I ran that command with sudo. Same result

Edit: I am using Ubuntu 18.04

[hartkopp]

Can you check with dmesg what the kernel log tells you about the failure?
This is often more detailed then just Operation not permitted :-)

[AndySchroder]

I just did a fresh install of Ubuntu 18.04.4 on a new computer. It still required me to run sudo depmod -a after installing in order for it to work. Here is the output of sudo make modules_install

$ sudo make modules_install
make -C /lib/modules/5.3.0-40-generic/build M=/home/xxxx/Desktop/yyy/installers/can-isotp modules_install
make[1]: Entering directory '/usr/src/linux-headers-5.3.0-40-generic'
  INSTALL /home/xxxx/Desktop/yyy/installers/can-isotp/net/can/can-isotp.ko
  DEPMOD  5.3.0-40-generic
Warning: modules_install: missing 'System.map' file. Skipping depmod.
make[1]: Leaving directory '/usr/src/linux-headers-5.3.0-40-generic'
$

I don't remember if it had Warning: modules_install: missing 'System.map' file. Skipping depmod. last time. It looks like my issue is related to #15 .

After running sudo make modules_install, but before running sudo depmod -a, python-can-isotp gives me

OSError: [Errno 93] Protocol not supported

I didn't try running isotprecv this time, but on the other computer, neither worked until I ran sudo depmod -a.

P.S. This time I just copied the kernel signing keys over from the other computer, so they were totally setup before I did anything with make and can-isotp.

[hartkopp]

Did modprobe can-isotp return without errors?

[AndySchroder]

I recently upgraded an existing system to Ubuntu 18.04.4. This system did not ever have can-isotp installed.

This is the 3rd sytem I've installed can-isotp on.

This time, I ran into a road block because it is a newer UEFI system with Secure Boot. Apparently without secure boot, if you have a keypair stored in /lib/modules/$(uname -r)/build/certs/, sudo make modules_install works and then as mentioned at the beginning of this thread, if you run sudo depmod -a, then everything is fine.

With Secure Boot, it seems as though the keypair stored in /lib/modules/$(uname -r)/build/certs/ is ignored and when you run sudo modprobe can-isotp (after running sudo make modules_install), you get modprobe: ERROR: could not insert 'can_isotp': Required key not available.

On my system, I can run the command sudo kmodsign sha512 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der /lib/modules/$(uname -r)/extra/net/can/can-isotp.ko after running sudo make modules_install. This then signs the kernel module with my Machine Owner Key (MOK). After this signing, can-isotp instantly worked without requiring sudo depmod -a to be run (although I'm not 100% sure that a former run of sudo depmod -a or sudo modprobe can-isotp, that I did while mucking around before I figured out that kmodsign was needed to get the module properly signed, did the trick).

I believe that this MOK on my system was generated when installing the dkms package while trying to get VirtualBox kernel drivers to work, because part of that process required me to generate a password and then reboot to install a MOK into the system and supply that generated password.

As a side note, how is signing of kernel modules even secure if the private key stored in /var/lib/shim-signed/mok/MOK.priv is a world readable file?

[hartkopp]

Hello Andy,
thanks for the documentation! I looks like the dkms install really brings the keys to be able to sign the own modules. Good to know!!

I was too cowardly to fiddle with an additional key and bringing it into UEFI on my dual-boot setup with W10 so I disabled secure boot on my machine with mokutil --disable-validation:
https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS
It's a pretty interesting process to give a password on your running Linux which is required to confirm the transition in the next boot process.

Regarding your side note: Once you are able to correctly boot into the cryptographic secured system and also have credentials to be root you are probably allowed to do signings. But I also wonder why the MOK.priv file is world readable then. Being root-only readable should be better. Maybe a bug in Ubuntu worth to be filed in their bugtracker?!?

[AndySchroder]

Did you actually test installing dkms and it worked for you or are you taking my word for it? I don't know for 100% sure because I haven't done another fresh Ubuntu installation on a new computer with secure boot yet.

Here are a few write ups that describe the process that I think happened for me when installing dkms regarding the password used on reboot

• https://wiki.debian.org/SecureBoot#Enroling_a_new_key
• https://wiki.ubuntu.com/UEFI/SecureBoot#How_can_I_do_non-automated_signing_of_drivers.3F

Where is the relevant Ubuntu bug tracker that I might submit a query about the permissions of the private key?

[hartkopp]

Did you actually test installing dkms ... ?

No. In fact I have only one Laptop which supports secure boot and I have to preserve the setup there.

Here are a few write ups that describe the process that I think happened for me when installing dkms regarding the password used on reboot

* https://wiki.debian.org/SecureBoot#Enroling_a_new_key

* https://wiki.ubuntu.com/UEFI/SecureBoot#How_can_I_do_non-automated_signing_of_drivers.3F

Thanks!

Where is the relevant Ubuntu bug tracker that I might submit a query about the permissions of the private key?

IDK. Would need to google too ;-)

[hartkopp]

You can obviously file Ubuntu problems of this type in Ubuntu Launchpad https://launchpad.net/ubuntu :
Like this one: https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1878115
:-D

[Cydfrey]

Hello,
Just ran into the same installation issue with newest Ubuntu on UEFI + Secure Boot, Thanks to your conversation I could solve the issue easily.

I was wondering if it would be worth it to add a note in the Readme to directly link to Andy's comment above? I will push something if you agree.