heads
heads copied to clipboard
linuxboot
Better grub.cfg parsing, to consider conditionals
Is your feature request related to a problem? Please describe.
When AEM package is installed on Qubes OS, the grub.cfg will include extra boot options guarded by if [ -d /aem/ ]; then. So, when it's just package installed but AEM is not initialized, nothing should change. But Heads' parsing of grub.cfg (I guess) doesn't consider this condition and include such boot entries anyway:
https://openqa.qubes-os.org/tests/81744#step/startup/7
Describe the solution you'd like
Ideally grub.cfg should be parsed as real grub would do. But in practice, maybe Heads can support just few condition variants like this one?
Describe alternatives you've considered
Not installing anti-evil-maid package when using Heads.
Additional context
For now (I hope) it affects only some tests, as anti-evil-maid is not installed by default. But some users may try to install it and get confused. And one day maybe AEM is going to be installed by default (not going to happen in short term).
@marmarek So I understand https://github.com/QubesOS/openqa-tests-qubesos/commit/70d4661772fb522e656fcdb42e97a0270e38df36 doesn't require Heads to do anything special with grub.cfg if/then/dynamic options anymore?
I'm not sure what to do with grub.cfg becoming a programming language where it should be static config as syslinux effectively done. Referencing comment from @DemiMarie from https://github.com/QubesOS/qubes-issues/issues/8763#issuecomment-1858581160 :
Dealing with now generalized variables under grub.cfg will be something else. Grub has grew in complexity over the past years for questionable reasons. Not sure why things there have switched to static written config from os having capacity to interpret and hardcode stuff for itself to letting things dynamic at runtime, but it seems that complexity wan there too.
Heads having to parse a GRUB config is a problem. The Boot Loader Specification is a much better solution to that, but it’s insufficiently expressive for Xen, unfortunately.
@DemiMarie: Maybe here would be better place to discuss alternatives/improvements to grub.cfg/plan to suggest things to grub so this issue could be used as a base for improvements suggestions upstream?
I don’t think that Heads should try to parse grub.cfg. GRUB scripting is a Turing-complete language, and trying to implement it outside of GRUB would be a nightmare.
A much better approach is to generate declarative spec files for Heads to use, possibly extended with extra fields for use with Xen and for security. I recommend a signify-signed file containing a security version number, hypervisor and kernel command lines, and hypervisor, kernel, and initramfs paths and hashes. It should be quite simple for Qubes OS to provide this information.
@marmarek So I understand QubesOS/openqa-tests-qubesos@70d4661 doesn't require Heads to do anything special with grub.cfg if/then/dynamic options anymore?
Correct. Since AEM under Heads makes little sense (at least in the current form), there is no need to trying to make them compatible.
I'm not sure what to do with grub.cfg becoming a programming language where it should be static config as syslinux effectively done.
Yeah, that's unfortunate...
A much better approach is to generate declarative spec files for Heads to use, possibly extended with extra fields for use with Xen and for security. I recommend a signify-signed file containing a security version number, hypervisor and kernel command lines, and hypervisor, kernel, and initramfs paths and hashes. It should be quite simple for Qubes OS to provide this information.
I'd rather avoid https://xkcd.com/927/. BLS might be a starting point, but it would require extending to support booting Xen (most likely using multiboot2 protocol - that gives most flexibility compared to for example unified xen+dom0 file). Such spec change would need to be incorporated into the original spec, not just kept as a custom format that only looks similar to BLS. I don't see it happening anytime soon, though.
Heads's parsing grub.cfg is fragile, but OTOH gives it excellent compatibility with several Linux distributions, without any changes on their side. Any custom solution would loose this feature.
Back to the topic of grub.cfg when AEM is installed, the "if" is used to reuse the same grub.cfg for on-disk /boot and for AEM stick. Having the same file eases updates quite a bit (it's enough to copy the file, instead of regenerating it separately, with some extra flag to make it an AEM-stick flavor). Parsing this in Heads would complicate the parser quite a bit (I don't see keeping much context, and here it would require tracking "if" and matching "fi"). But maybe the AEM grub generator could be changed a bit to make work easier for Heads? For example add some AEM-specific "class" to menuentry line, that Heads could skip (or maybe skip conditionally if /aem dir is missing)?
@DemiMarie @marmarek thanks for stating your points here, where they have to be considered for support. Will test https://github.com/QubesOS/updates-status/issues/4238 and go from there.
Edit: 6.6.2+ works as intended with dracut installed patching initramfs file correctly as per latest QSB.
@Demi-Marie @marmarek
As of today, no need outside of even weirder grub.cfg configs on talos II (ppc64le) or newer Ubuntu. Hear me out, Ubuntu is a thing so I will do this eventually. But turning heads into code analyser, nope.
Covering what is needed to escape complexity of grub.cfg dynamic configs:yes.
Somehow I will probably have to jump into grub or at least understand why grub.cfg generator doesn't create something static. There is no reason for security that things get so complex and this is ridiculous.