/usr/src/linux does not exist by default on Fedora

[krishjainx]

Hi. After following the DKMS instructions I attempt to run https://github.com/lkrg-org/lkrg/blob/main/scripts/add-exports.sh but I see that it has a dependency on the /usr/src/linux directory existing but that's not the case on a fresh Fedora 36 install. So how would we modify this script for that?

$ tree /usr/src/ /usr/src/ ├── debug └── kernels

[solardiz]

Thanks for reporting.

What were you trying to do? What's your reason to use this script in the first place? Did you run into an issue that it works around, and what was that, and is that the only such issue? In other words, was the script both necessary and sufficient in your case? One of the reasons I ask is because we'd consider simply dropping the script from our tree.

As to the directory name, you can pass any directory name corresponding to your kernel source tree to that script (via KDIR=... on its command line), and you'd normally use that script only along with a custom kernel build perhaps not coming from your distro anyway.

[krishjainx]

For now I am using the default kernel from my distro, Fedora, but in the future yes I plan to have a custom kernel. In this case (a) would I need that script or (b) should it work without? Thanks!

[krishjainx]

And if needed with a custom kernel build could you explain why it is needed in that case and not when you're using the kernel package from your distro?

[solardiz]

This is tricky. Most of the time, things should work without that script. When they don't, there's only a chance the script will help. This is not strictly connected to distro vs. custom kernels, but there's a wider variety of custom kernel builds and compiler optimizations used, making this sort of problems more likely with custom builds. Also, if the problem occurs for a distro kernel, we don't really expect the person to rebuild that kernel anyway - they're probably using a distro kernel precisely to avoid building (and then rebuilding) their own - so also not to use this script. We generally try to fix LKRG to avoid such problems instead, especially with distro kernels.

[solardiz]

I'll close this issue now as it's not something we need to track nor act upon.

[krishjainx]

I'm soon building my custom hardened kernel. I'll try LKRG against that and see how it works. Also, lockdown=confidentiality or lockdown=integrity won't work or which will? @solardiz . Thanks!

[solardiz]

I'm no lockdown expert, but per my re-reading of a private discussion thread we had in 2020, the lockdown mode that's default with Secure Boot should work in newer kernels, which I think means integrity, and it was mentioned that confidentiality restricts use of kprobes, so presumably won't work. In summary, integrity should work and confidentiality should not.

Also, I think your questions would be more appropriate in separate threads in a discussion forum on LKRG. We currently only have the lkrg-users mailing list, which became inactive lately, but we could revitalize it. Having questions added to unrelated GitHub issues is not ideal.

[krishjainx]

I understand. Thanks anyway. Have a great day!

[solardiz]

@Krish-sysadmin I'm sorry, I'm not going to spend my time on this, and I would be unlikely to spot everything just by looking. Good luck!

[krishjainx]

Ok, thank you. I'll just test it out and let you know if it works

[krishjainx]

# insmod output/p_lkrg.ko kint_enforce=1 && dmesg

would tell me if it works, right? @solardiz

[solardiz]

@Krish-sysadmin Yes, loading the module like that is the first test you'd do after building it.