[FEAT] Compile our own kernel with clang for CFI

[alexvojproc]

Benefit

• Kernel control flow integrity implementations (kCFI and FineIBT) depend on LLVM, as discussed in [FEAT] Additional Kernel Boot Parameters secureblue#1393.
• These offer some protection from COP and some ROP, COOP attack chains. Complements CET/SHSTK.
• Goes hand-in-hand with [feat] OpenPaX kernel patches #6 and [FEAT] LTS custom kernels #4.

Solution

• As a starting point, maybe secureblue could look into building Fedora's kernel, just with clang? COPR might be appropriate?
• Perhaps then force cfi=kcfi.

Alternatives

Status quo: no CFI.

Declaration

• I agree to follow this project's Code of Conduct.
• I declare that this is not a request for alternate community messaging or social platforms.
• I declare that I have read the secureblue website and my feature request is in-scope.

[jasperweiss]

fwupdmgr security currently shows

✘ Linux kernel:                  Tainted

Because /proc/sys/kernel/tainted is 4096

When decoded:

Taint value (original): 4096, Hex: 0x00001000
Binary: [000000000000000000001000000000000] Hex cleared: 0x00001000
[F/bit] [bit val]   [description]                                                   
 O  12  4096        An out-of-tree module has been loaded (not shipped with Kernel) 

Presumably this is because of the included (open) Nvidia drivers. Would it be possible to fix that if secureblue builds it's own kernel? Or could that also be fixed without a custom kernel?

If so, perhaps it would also be a good idea to add a check for the tainted value in the audit script.

[alexvojproc]

@jasperweiss The Nvidia module is out of tree (i.e. not upstreamed into the main kernel). The purpose of tainting is to tell kernel devs when the kernel is running in an unusual state, so that they can avoid wasting their time on troubleshooting an issue that likely isn't kernel.org's fault. So marking Nvidia-loaded kernels as tainted is a good thing.

If we were to patch our kernel somehow to bring Nvidia in-tree and make those kernels non-tainted, that'd defeat the whole purpose of the tainting mechanism and mislead people trying to troubleshoot your system.

It could be useful to check kernel taint status in the secureblue audit, but I think the scope of the audit is mostly limited to things relevant to secureblue's own tooling. I think last time we discussed this, we have no plans to copy fwupdmgr in this regard besides just checking secure boot status (as secureblue often requires this, e.g. for Nvidia, where upstream doesn't).

TLDR: tainting isn't inherently dangerous, you have just voided your warranty

[alexvojproc]

@jasperweiss I should also add that kernel args are being discussed in secureblue/secureblue#1393 to panic in some taint-like scenarios (e.g. repeated oopses, live patching, bad hardware, etc.). This might be more useful in practice, as it happens in real time and is harder to ignore than a taint.

[jasperweiss]

@alexvojproc Understood. I was thinking of a service that checks for changes in the taint status and displays a critical notification if there is one. But a panic would probably be a better idea

[RoyalOughtness]

KSPP/linux#369