In this [default] mode, Aeon will measure all of the following aspects of your systems integrity and store those measurements in your systems TPM:

UEFI Firmware
Secureboot state (enabled or disabled)
Partition Table
Boot loader and drivers
Kernel and initrd (including kernel cmdline parameters)

When your system starts, it will compare the current state to the measurements stored in the TPM.

If they match, your system will boot.

As Default Mode establishes a strong 'chain of trust' between a more comprehensive list of key boot components, the use of Secureboot in Default Mode can be considered optional.

As Fallback Mode has no such measurements of boot components, Secureboot should be enabled. Disabling Secureboot in Fallback Mode leaves your system vulnerable to tampering, including attacks which may capture your passphrase when entered.

If secure boot isn't needed then what's stopping an attacker from USB booting and changing the tpm parameters or pulling the luks password? Actually what's stopping an attacker from USB booting even when secure boot is enabled? Or switching the Aeon kernel with one that won't do the check at all and registering that with secure boot?

A quick Google search says secure boot is not intended to protect against someone with physical access. Then why does it matter in the context of fde at all? Malware running after boot would have access to (most of the) unencrypted filesystem anyways. Edit: and if it has the privileges to modify kernel or boot loader it could do the things I wrote above too

And it's weird that there isn't a mode that uses a luks password in combination to the chain of trust. Relying on the user password for protection doesn't feel very secure since a physical attacker would have more opportunities to see it while the computer is in use than a luks password.

Oh, I never heard of this one before, it certainly meets the criteria, I read the documentation to understand it more

yes, the developer seem very opinionated :|