Generally encrypting the boot partition is not well supported. Using tpm or smartcard for this is even less supported
that article is older but lists the key reasons why this is a challenge. Even if we downgrade luks2 to be compatible with grub2 there is no way to have the grub boot process unlock the luks2 partition via hardware (tpm2, smartcard). It only supports inputting a password.
Is it feasible to modify grub to support tpm? maybe but that's been challenging even in the initrd which is a fully working linux kernel and utilities. Support for smartcards faces the same problems. All of this would be new code and grub is working with limits since it has to fit into smaller spaces.
Now modern systems are booting with UEFI which allows larger code since it is on a whole partition. Could we modify the grub2 uefi shim?
UEFI => shim => grub => check for tpm/prompt for pin => decrypt /boot => load kernel and initrd
If the root partition is encrypted there would also be a second pin prompt. This is not ideal. TPM unlock would be seamless as that is all handled in the background.
There are also other issues. Ubuntu disables grub2 support for luks2 in secure boot. They claim that not enough security review to trust the code. In addition crypto hardware may not be used causing long delays to reach the boot menu (ie. 3 minutes). And Secure Boot further restricts the boot process which often stops the decrypt process from working--and this is before any smartcard integrations.
if we use luks1 for only the boot partition we eliminate some of the problems related to luks2 with grub. Grub will prompt for the luks1 passphrase in this setup and then the boot process would prompt as needed for the root partition. It will be SLOW. It is less secure than luks2 which means we need to use a much larger passphrase for /boot.
Could we patch grub to use the tpm for the boot unlock? this will probably not work on many systems. the tpm tools with systemd only suppport the lastest hardware. But on those systems we might be able to eliminate the first prompt. Combined with a long passphrase our boot process should stay reasonably secure.
oh look. in 2023 ubuntu is already doing this... things to note
features delivered via snaps rather than apt/deb
uses UKI
26.10 release article mentions widening support for systems without compatible hardware for secure boot and full disk encryption.
Even if we got this approach to work it seems that it will be fragile. (prone to breaking often). The only viable solution seems to be self signed Unified Kernel Images (UKI) which is also fragile. Since Ubuntu is moving in a similar direction that will likely prevent adoption of the approach detailed on this page--opting instead for encrypting the entire disk.