As far as having a GUI front-end to allow a user to manually change the kernel command line before booting, because it’s a one-off change that doesn’t persist reboots, I suppose (like with our failsafe boot mode in the boot menu) it could be done safely.
It would still need someone willing to write the feature though 
Which is a temporary change of the value, correct? So the use of the rescue shell will not alert me when I switch on the computer the next time.
What would have to be done to have the LibremKey detect the former use of the rescue shell on next reboot?
Correct, because it’s not a persistent change (which is what Heads cares about), someone booting your system or existing to the recovery shell will not trigger a warning as the system wasn’t actually successfully tampered with in those cases.
Off the top of my head, I suppose you could challenge the user to enter a password to get access to the recovery shell, and if they fail too many times, remove a signed kexec config files in /boot so that the real user gets an alert when they boot next.
Thanks for the answer. I’ll think some more about it and maybe sometimes look into the coreboot code.
Anyway I’d prefer to change a signed file in a way that it could not be restored from the rescue shell - thinking about it: if someone took the notebook apart and copied the file from /boot beforehand she or he could use the rescue shell and cover their traces.
Isn’t there something that could be altered that would affect the initial value of a relevant PCR?
The “nuclear option” would be to erase the TPM. That’s something an attacker couldn’t restore (as they don’t know the shared secret inside the TPM).
This option has other implications though, as some Heads users also store part of their LUKS unlock key in the TPM–it gets combined with a passphrase they type in at boot so that one can only unlock the OS if the TPM has proper measurements.