Can you explain more what security vector you're talking about here, because I just don't see it?
Like, as far as I can tell, grub or whatever is a bundle of filesystem and device drivers, with enough info to then execute a kernel.
Linux also is a bundle of filesystem and device drivers, but better tested ones I think.
To me, it seems like using the kernel's filesystem drivers, which you have to use already anyway once you've booted, means you have to trust fewer total implementations of these drivers, so it seems more secure.
What attack or threat vector are you trying to talk about here?
It is the same security abstraction where you don’t allow support for network socket in process ID 1.
(Looking at you, systemd.)
You don’t allow access to the bootloader from any kernel, thereby afford a relative security in starting 2nd stage (kernels). One abstraction is that TPM, et. al., can lockstep assurances on each stage. At a minimum, you have a bootloader, in case of SNAFU/FOOBAR.
Bricking (or worse, malicious kernel) seems more a possibility with upcoming Redhat design.
> You don’t allow access to the bootloader from any kernel, thereby afford a relative security in starting 2nd stage
You install and update the bootloader and its configuration from your running linux system.
In this new world, you would also update the kernel from your running linux system. That's the same, right? To update the kernel, you need to update bootloader configuration anyway, so it's obviously required that the running system can at least update the kernel, and that's true either way.
> Bricking (or worse, malicious kernel) seems more a possibility with upcoming Redhat design.
If your kernel is malicious, it's game over whether or not you're using grub, right? Like, that doesn't seem like a new threat model.
I don't really care about bricking because, frankly, I've made my system unbootable via grub bugs more often than I have through kernel bugs, and the kernel developers seem to take these bugs more seriously, so I feel like bricking is a possibility with either design, but less likely without grub.
Either way, I need to have a liveusb off to the side to fix these issues.
Nothing for hacker to see and analyze the bootloader, assuming you did not load a driver to the NVRAM/Flash/UEFI/EFI.
Nice security compartment alization.
Redhat is smothering this easential security abstraction of 1st stage loader: not a good security model.