Missing Modules from Kernel Crypto API

Hi,

I am currently trying to tunnel into a VPN from my Jetson using ipsec, and though the connections appear to be made correctly, no virtual IP is ever assigned to the Jetson. It seems as though this is due to a few essential crypto modules missing from the tegra linux kernel (namely, the ones required for ipsec). I’ve been trying to build the standard kernel modules but have run into problems with including all the correct files. I can’t seem to get any of the asm headers through the kernel source… Any ideas on how to get around this issue?

-Harris

Is this R28.1? Later releases have not only the kernel source, but a “hardware” subdirectory next to the kernel source…some device tree references use a relative path requiring that subdirectory (some hardware-dependent code was separated out of the kernel when TX1 and TX2 were merged to use the same rootfs).

In the driver package you will find “source_sync.sh”. The best way to get everything needed is:

./source_sync.sh -k tegra-l4t-r28.1

…various docs explain the “-k” and other variations…“k” is for kernel, “u” is for U-Boot.

Thank you for the quick response. My release is indeed R28.1.

EDIT: Found my release version

# R28 (release), REVISION: 1.0, GCID: 9379712, BOARD: t186ref, EABI: aarch64, DATE: Thu Jul 20 07:59:31 UTC 2017

I don’t see a “hardware” subdirectory in /usr/src. I see the following directories:

cudnn_samples_v6  linux-headers-4.4.38-tegra  tensorrt

Inside the linux-headers directory:

arch   certs   Documentation  firmware  include  ipc     Kconfig  lib       mm               modules.order   net     samples  security  System.map  usr
block  crypto  drivers        fs        init     Kbuild  kernel   Makefile  modules.builtin  Module.symvers  README  scripts  sound     tools       virt

Do you have the absolute path for the source_sync.sh file?

EDIT:
I downloaded the L4T driver package and have found the sourc_sync.sh file. I’m going to run that on our test platform first, but just to make sure, running the source_sync script should not touch files outside of the kernel/driver packages, correct? Or should I back everything up first?

That source_sync.sh command creates and populates a “source/” subdirectory. It won’t touch anything else.

So I now have the source files downloaded, how do I go about actually compiling the new files and ensuring that the kernel supports all of the necessary crypto algorithms? Sorry for asking so many questions, this is my first time messing with the kernel.

As for whether you have all modules needed you’ll have to check the VPN requirements docs…don’t know. What actually needs to change in your kernel build depends on whether everything can be built as a module…you’ll need to know which features before that can be answered (odds are high everything can be a module…but some features must be integrated into the kernel image itself instead of as a loadable module).

You can actually build on the Jetson itself if you’ve used source_sync.sh there. If not, then you’ll need to set up your cross compile environment. I assume since you mentioned above some build failures that you are set up either for compile on the Jetson or cross compile on the PC host.

The part you want to always start with is the configuration which matches your running system. Copy “/proc/config.gz” somewhere, gunzip it, and save this as a reference. When a copy is named “.config” and placed in your build area it will start out matching the existing kernel.

You’d need to match the existing suffix of “uname -r” to be your CONFIG_LOCALVERSION, and you’d need to set as module or integrated feature each driver or feature you want to add. If you know which these are it’ll be fairly easy to give advice on how to build, but I do not know your VPN software requirements.

Thanks again for answering.

It seems as though the only modules I need are located in the crypto API. They are:

  1. crypto_null
  2. authenc
  3. ccm
  4. gcm
  5. cbc
  6. ctr
  7. hmac
  8. deflate

These are the only crypto modules listed as necessary for ipsec (as specified here:
https://github.com/torvalds/linux/blob/master/crypto/Kconfig).

If it’s any help, I’m using strongswan to establish the ipsec connection.

Just a note ahead of time, the “make nconfig” target opens an ncurses-based kernel config editor which has a “search” function. You should be able to search for those key words, and if the symbol has a related name (as it almost always does), then you can find the symbol. To use the curses-based menu editors you will want to install package “libncurses5-dev”.

You will want to use the source_sync.sh kernel directory since it also has the hardware directory.

Note: You will often see the “O=/some/where/for/tmp/kernel/output” option. You should create an empty directory, and another directory as a subdirectory of this for your build if you use the source_sync.sh tree. The reason is because of arrangement of temporary content which will not be contained entirely in the “O=/some/where” directory…some content will go in the parent of this directory. If you change config after a build there is a chance you will keep getting messages about a configuration already being present…you can delete everything in this previously empty directory to get rid of that message.

Example (cross compile would need more additions to this):

mkdir -p ~/my/kernel/build/stage
mkdir ~/my/kernel/build/stage/kernel_out
mkdir ~/my/kernel/build/stage/modules_out
export TEGRA_KERNEL_OUT=~/my/kernel/build/stage/kernel_out
export TEGRA_MODULES_OUT=~/my/kernel/build/stage/modules_out
cp /proc/config.gz $TEGRA_KERNEL_OUT
cp /proc/config.gz /some/where/safe/for/future/reference
gunzip $TEGRA_KERNEL_OUT/config.gz
make O=$TEGRA_KERNEL_OUT nconfig
...do the config stuff...
...perhaps not all targets will be needed, stating anyway...
make -j4 O=$TEGRA_KERNEL_OUT Image
make -j4 O=$TEGRA_KERNEL_OUT modules
make -j4 O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT

Note that if “uname -a” on your existing system says “4.4.38-tegra”, then your CONFIG_LOCALVERSION is “-tegra”, and your base kernel version is “4.4.38”. Modules will be searched for in “/lib/modules/4.4.38-tegra/” under that setup. In general, modules are searched for based on the Image at compile time…the source_sync.sh will add a an annoying “+” to the CONFIG_LOCALVERSION, so if you set CONFIG_LOCALVERSION to “-tegra”, then “uname -r” under that Image would cause modules to need to be at “/lib/modules/4.4.38-tegra+/” (“/lib/modules/$(uname -r)/”).

See the Documentation for R28.1 for information on cross compile…it’s an extension of this. Or ask more on forums.

Thank you so much! I will give this a try.