EFI loader - GELI secrets in memory exposed on exit() ?

Dear All,

Could someone with FreeBSD EFI loader knowledge please confirm my
impression that currently the memory is not cleared in any way upon a
call to exit() / efi_exit() in the EFI loader? This means that if the
loader (for whatever reason) exits instead of booting, the next UEFI
boot entry might be able to read any secrets left over on the heap
(i.e. GELI passphrase / key)? Would adding explicit_bzero() before
efi_main.c:44 [1] address this and other such "cold boot" concerns?
This scenario is particularly clumsy because for "resets"  the
Platform Reset Mitigation can be engaged (and does engage by default
if TPM is owned) but a simple "exit" from an UEFI app is different.
For example multiple UEFI apps can simply run one after another from
the UEFI Shell, clearly without zero-ing out all of the physical
memory. Thoughts? Thank you for your time and consideration.

PS. The work on automatically booting GELI-encrypted installs using
TPM2 using more standard TPM provisioning (Shrared Storage Key) is
almost finished [3]. It works quite beautifully and actually allows to
store the key instead of the passphrase which is faster (avoids
computation) and also largely avoid messy use of environment variables
AND EFI variables for config are no longer used, instead relying on
files in /efi/freebsd/gkut2. GKUT2 stands for GELI Key Using TPM2. The
question above is clearly related to GKUT2 in particular.

[1] https://github.com/freebsd/freebsd-src/blob/main/stand/efi/loader/efi_main.c#L44
[2] https://trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf
[3] https://github.com/sadaszewski/freebsd-patch-geli-password-from-tpm2/tree/decrypt

Best regards,

--
Stanislaw