Is partially deblobbing the kernel worth it?

Privacy Questions
1

Hello,

Linux-libre’s deblob scripts appear to be documented well enough that I could probably modify it to retain support for security relevant blobs such as the CPU microcode updates. Is doing this worth it, for the purpose of further reducing kernel attack surface, or is it more trouble than its worth?

Thanks.

2

You can install your own kernel, but you might have conflict with your distros package manager and such. Personally, unless you know what the dangers are of keeping the blobs in the kernel, I see no reason for the average user to deblob a kernel

3

I already compile the kernel with only the required modules. I want to reduce attack surface (and avoid potentially nonfree software in ring0) as much as possible without loss of functionality

4

You probably need those proprietary blobs for security fixes from hardware vendors. Of which, they are many e.g for CPUs there seems to be a new flaw discovered almost every month now.

However if you want a secure kernel and still want to keep compiling your own kernel, there’s this very easy option maintained by kernel developer Kees Cook. https://www.phoronix.com/news/Linux-6.7-Hardening

That option enables kernel Kconfigs for basic security hardening (minimal performance disruption to users) which can be found here: linux/kernel/configs/hardening.config at d74da846046aeec9333e802f5918bd3261fb5509 · torvalds/linux · GitHub

Remember security is not a one-click toggle. And I recommend you go through this blogpost from a Cloudflare systems engineer to get a better understanding of kernel security more broadly. Linux kernel security tunables everyone should consider adopting

5

Thanks. I already apply the linux-hardened patches so pretty much all of this should be in (edit: I also apply many sysctls and boot parameters from madaidan’s guide).

Reading through the deblob script, it seems like a lot of it is cleaning drivers that aren’t even compiled in with my build so it should be easier to maintain if I decide to use parts of it. But yeah, it’s probably too hard for me to tell if a blob is a good or a bad blob without being able to actually read and understand the kernel source code. If anyone knows what blobs are good and should never be touched, or what blobs are 100% not security fixes and can be safely removed, please let me know. This is the script I’m talking about

6

The hardening config I mentioned above and linux-hardened patches do very different things. If you had read and compared both sources would be straightforward to see why.

7

You are right. I’ll implement these into my config, thanks.

(Edit) The config options that are missing from the linux-hardened default config are:

CONFIG_SLAB_BUCKETS=y

CONFIG_PAGE_TABLE_CHECK=y
CONFIG_PAGE_TABLE_CHECK_ENFORCED=y

CONFIG_UBSAN=y
CONFIG_UBSAN_TRAP=y
CONFIG_UBSAN_BOUNDS=y

CONFIG_EFI_DISABLE_PCI_DMA=y

CONFIG_STRICT_DEVMEM=y
CONFIG_IO_STRICT_DEVMEM=y

CONFIG_CFI_CLANG=y

# CONFIG_LDISC_AUTOLOAD is not set