tirdad module autoloading sensible?

[adrelanos]

This DKMS issue made me wonder if loading tirdad using systemd-modules-load.service / /usr/lib/modules-load.d/30_tirdad.conf is the right approach. Other modules (such as battery, ext4, not sure if good example and probably many others) are automatically load on some event.

Would it be doable, sensible to use the kernel's auto load mechanism to load tirdad too?

[madaidan]

Those modules are built as part of the kernel (e.g. CONFIG_EXT4_FS=m) and aren't out-of-tree modules like tirdad is. I'm not sure if it's possible to auto-load out-of-tree modules.

It would be cool if tirdad was also distributed as a kernel patch so we could enable it with CONFIG_TIRDAD=y/CONFIG_TIRDAD=m.

#6 is related.

[0xsirus]

Would it be doable, sensible to use the kernel's auto load mechanism to load tirdad too?

Well, kernel can load modules on-demand. For example when a socket family is not in kernel core code, it can try to find the corresponding modules to manage the socket. For example:
https://elixir.bootlin.com/linux/v5.5.2/source/net/socket.c#L1401

However this is not useful for our use case. We can't have the kernel load tirdad itself the way the aforementioned example does, because again it needs modifying kernel code which in turn means using a custom kernel. And I'm not aware of any other standard way to instruct the kernel to load a module automatically without changing something in its code.
If you want to use a custom kerenl I'll be happy to add tirdad to the kernel itself, but if not, you'll probably have to use it the way it is.

It would be cool if tirdad was also distributed as a kernel patch

I've already done that. I submitted the patch to kernel developers and they didn't show any interest in resolving this issue in TCP. I even added a sysctl option to Linux kernel so that users can arbitrarily switch the patch on/off without needing to reboot the system. But again anonymity is not their concern.

[adrelanos]

Alright, good. :)

We don't have a custom kernel installed by default yet but hopefully will get there:

• https://github.com/Whonix/hardened-kernel
• https://phabricator.whonix.org/T960

When that happened, we can think about a kernel patch and open a new issue here. However, I guess we might want to keep it a module because of those where hardened-kernel does not work or if if hardened-kernel temporarily does not work, one has to fall back to booting a standard distribution kernel. Then it's good to have the kernel module load. Also the kernel module makes it more accessible to more users outside of Whonix / Kicksecure, i.e. everyone not compiling their own kernel.

Also I don't know how much extra effort would it be to maintain a kernel module + kernel patch at the same time?

My very question of this issue was answered. Therefore closing this issue. Anyone feel free to re-open if this was premature.

[madaidan]

I've already done that. I submitted the patch to kernel developers and they didn't show any interest in resolving this issue in TCP. I even added a sysctl option to Linux kernel so that users can arbitrarily switch the patch on/off without needing to reboot the system. But again anonymity is not their concern.

You can submit the patch to our hardened-kernel package we're working on or maybe https://github.com/anthraxx/linux-hardened (which we use)

[adrelanos]

https://github.com/anthraxx/linux-hardened would be ideal for maximum review/exposure.

[0xsirus]

anthraxx/linux-hardened#26