Hmmm so you don't view those as "hardware support"? :facepalm: I realize it's a bit in reverse since it's rare that a hardware manufacturer fails so badly that they build in security holes especially at such low levels but it is still essentially no different than any new chip requiring new software previously unavailable.

The BIOS/UEFI subsystem is code that allows and informs all the present hardware how to communicate with each other. The kernel is code that allows and informs all the present hardware how to communicate with the OpSys. Bottom Line.

I definitely regard them as "hardware support" that necessitates scrapping the old kernel for a new one. Even by applying a non-trivial patch against Meltdown/Spectre (which would update the source code), I'd still wipe all the generated files/object code to start with the cleanest build tree possible. It might just be simpler to save the old .config, wipe the entire kernel source tree, then unpack, configure (using the old .config), & build the new kernel.

Plus, this is "hardware support" that has nothing to do with "new" hardware or device class, and everything to do with "legacy" hardware (and not just x86!).

Now I'm confused since my directly quoted words were "The only truly compelling reason for kernel upgrade is hardware support". Where is our conflict?

Your earlier words were:
I won't worry in this post about confusing " root encryption" and "hardware support". The defect in either place, is a defect in both places, I think.

I doubt that you & I have any conflict; perhaps, only a mis-understanding about our words. As I type this, I think it's gotten a bit foggy. If you're OK with that, well, so am I. Peace?

Yet another thread drawn off topic.

To gus3 - yeah we cool

To chrisretusn - Maybe a tangent but I maintain that kernel choice and it's requirements are fundamental to any discussion about initrd which is essentially a tangent to the kernel. Anyway unless I'm mistaken OP got his answer and this should likely be marked "Solved".