Change:
cpu-cgroup-v2 = import ./cpu-cgroup-v2-patches; hardened = let <del> mkPatch = kernelVersion: src: { </del> <ins> mkPatch = kernelVersion: { version, sha256, patch }: let src = patch; in { </ins> name = lib.removeSuffix ".patch" src.name; patch = fetchurl (lib.filterAttrs (k: v: k != "extra") src); extra = src.extra; <ins> inherit version sha256; </ins> }; patches = builtins.fromJSON (builtins.readFile ./hardened/patches.json); in lib.mapAttrs mkPatch patches;

Discussion:
I'm one of the folks who are currently testing/merging/backporting Linux kernel updates. All in all, this is quite a smooth process thanks to who tirelessly files update PRs in the first place and an existing updater-script. However there are a few minor issues I have that I'd like to discuss here before submitting any code. We have all active Kernel releases packaged and - if available - also which provides a few additional security properties. However these releases lag behind the upstream Kernel usually, on a few occasions we had to wait for about a week[1][2]. However, Kernel updates are quite relevant usually, either because of important bugfixes or because of CVEs to be fixed. Because of that, we decided to ignore outdated hardened patches at some point[3] and right now the hardened kernel is broken rather regularly[4]. Another issue is what's supposed to happen if a kernel minor-release gets EOL and no hardened patches are available for the next higher minor release (that's also )[5]. IMHO neither the "old" approach (awaiting hardened patches and thus delaying kernel updates for everyone) nor the current one (ignoring build failures) is optimal. Current ideas I have are: Drop all hardened kernels. With Nix it isn't very hard to re-add packages via an overlay. Use older versions of a Kernel for hardened variants (i.e. let's say we are at Linux and want to upgrade to , but no hardened patch is available yet. Now we upgrade to , but use continue to use for the hardened kernel). This is a rather trivial one :sweatsmile: I noticed that I get pinged rather inconsistently on Kernel PRs which is totally understandable, I also wouldn't want to keep track of everyone I have to ping for each PR I open, especially because this is automatable. Currently we seem to have a single person listed as maintainer for Kernels: My suggestion is rather simple - we should for a maintainer team with both a team in the NixOS GH org and an entry in . I'd nominate myself - if everyone's OK with that and make sure the members are requested for a review on each Kernel bump.

[1] [2] [3] [4] [5]
Since we are using the hardened kernels on our infrastructure, I'm a big fan of changing the way it currently works. I don't know how many people other than us use the hardened kernels, but I don't think it's fesible for everybody to overlay in the hardened kernel and keep it up to date, especially for new users who are switching from other Distros and want to keep their kernels. For this reason, I tend to prefer your second idea. I did this for OpenSSH in as well and I think most of the user base who are using the stock ssh benefit from this change with the others having to accept the less maintained packages.
Just one more detail. For zfs, there is the to track the latest kernel version compatible with zfs. It would be really nice to have something like . I don't use hardened yet, but I am interested in it, the second choice would be amazing.
Yeah, I'm aware of that, but I don't think this is useful here. isn't a good idea because this can lead to "silent" downgrades as mentioned in the OP. Also, this doesn't help when trying to update the "latest compatible version" in question, if no hardened patch is available for a new patch-release we can either delay the upgrade or ignore the hardened kernel.
I have not had as much time to do this maintenance as I used to. I would go with the "keep a specific version for the hardened kernels"-approach.
To chime in, I support decoupling hardened kernel bumps from vanilla kernel bumps. Adopting the the hardening patches takes time and testing, so hardened kernels will often be delayed by a few days. For minor version bumps the upgrade script should attempt to apply the patchset from the previous version, if no matching patchset is available. If it applies cleanly and compiles, fine. If not: simply delay the Kernel update. Another thing that we should take care of before 21.11 are the other Kernel flavours, e.g. Xanmod. While the version in unstable is pretty up-to-date, 21.05 is currently stuck with 5.12.13-xanmod. Maybe the update-script can be extended to ensure that backports are taken care of and we should provide and .

ping for their view on this
If someone who uses wants to take up the maintenance of xanmod backports I'll happily help merge PRs. I live on in all my systems, so I don't have time or a host to test the backports properly.
I've been switching around Kernel versions on a lot lately (because of issues with nouveau, not NixOS specific) and it always worked like a charm. Given that Xanmod is targeted towards desktop use, where a rollback is just a reboot away I think we are fine with a "no guarantees" approach. The user base on stable seems to be rather small, given that no one noticed the outdated kernel for quite some time.
I'm fine with a stable version of xanmod if there's enough demand of it, personally I use the latest available, as I don't use ZFS and the like.
I use xanmod latest and zfs
Hardened plan sounds fine to me. I'm happy to be in the maintainer team so I get pinged if I'm around, as long as everybody has the expectation going in that I don't often find the time to do kernel patch releases.
Splendid! I'll file PRs for both the hardening topic and the maintainer team during one fo the next days :)
Can XanMod be to
I (evidently ) use the hardened kernel so would prefer the second approach. Do you believe this will be a significant maintenance burden?
there's already doing exactly that :)