[OFFICIAL] Linux Kernel (new modules, optimizations, hacks, ...)


Any word on when we’ll see 4.1-based kernels? I’m relying on some internal APIs from it for a kernel module I’d like to run on Scaleway.


I “plussoie”! Linux 4.1 has introduced a File-System Encryption, which can be very interesting in comparison of any LVM-LUKS partionning.

Also, I saw a 4.1.2-std kernel on github. What is the deployment flow of these new kernels?


Can u please add an option for kexec call in kernel.
just one line in .config:

Probably it will be great replacement for [absent] ability to create custom bootscripts and kernel images.


Linux 4.1.6 needs CRYPTODEV (the kernel needs patching) so we can take advantage of MV_CESA (which is in) for crypto acceleration. Thanks!

Update, performance without cryptodev and without utilizing the CESA:

$ openssl speed aes-128-cbc chacha20-poly1305 aes-128-gcm
The 'numbers' are in 1000s of bytes per second processed.
type                   1024 bytes   8192 bytes
aes-128 cbc           54811.31k    55107.58k
aes-128 gcm           23972.52k    24737.11k
chacha20 poly1305     30683.14k    32522.24k

(24–32 MB/s per core at 100% utilization with TLSv1.2. That could be three times more! Although impressive enough because it matches an old Intel Pentium 4 @3GHz.)

Update: I’ve optimized the CESA-less, NEON-less implementation of…:

chacha20 poly1305     34686.63k    37178.03k


You can follow the current CESA support status: https://github.com/scaleway/kernel-tools/pull/137


Thanks for the heads-up!

CRYPTODEV ≠ DEV_CRYPTO_xxx by the way.

I can only see the latter; which helps with in-kernel cryptography, for example, as used in IPsec or dm-crypt.

The former will expose the kernel’s facilities as /dev/crypto and is what you use with OpenSSL and the like. Find the patches here: https://github.com/cryptodev-linux/cryptodev-linux


I’m trying to store my data on a volume encrypted with dm-crypt, but the module isn’t available. Can you please add:




Actually the module is already enabled on all the kernels except 3.2.34-std, can you try with the 4.1.6-std for instance ?


Thanks, I see. I’m running the default Ubuntu 14.04 image which means kernel 3.2.34-30. Are there any instructions on how to move to 4.1.6?


I could be wrong (didn’t do this; not sure if you better copy kernel modules first to restore them after the switch), but once you have started a server you can click on advanced and then…:


Yep, https://www.scaleway.com/docs/bootscript-and-how-to-use-it/


@manfred @mark thanks, that’s solved the problem. Have a great day.


Hello Community,

even though I understand that IPv6 is not officially supported on scaleway, I tried setting up a he.net tunnel. That works fine for me. But, I am little puzzled by the kernel config: it contains IPv6 support and even IP6 tables as modules, but lacks other related features (like CONFIG_NF_CONNTRACK_IPV6). Could you please consider building all v6 related modules?


btw. It may have been brought up earlier, but what about building everything that can be built as a module, disabling just those causing issues?


is a grsec enabled Kernel planned?


Hi @tze, not for the C1, see https://github.com/scaleway/kernel-tools/issues/142.

The current official GRSEC support is for linux kernels up to 3.14, however, the minimal mainline kernel we can run on the C1 is 3.18.

You can use alternatives: selinux or apparmor on C1 or wait for new hardware


Hi @manfred,

Thanks for the response, i know that stable grsec is available only till 3.14
It would still be great to get an “unstable” grsec enabled newer Kernel.
As of now Alpine Linux is using 3.18.X enabled with the “unstable” grsec patches.
Just food for thought, i think a lot of Alpine Users would welcome this.


Ok, I created this issue to follow up: https://github.com/scaleway/kernel-tools/issues/164


Hello @manfred,

why we have a x86_64 Kernel at GitHub?


I was asking before, but got no response.
What about kexec kernel option?