Dear Maintainer,

I managed to install argon2i patches from Arch repo and it works!
But argon2 may fail on some system due to lack of memory error and
makes some systems unbootable.

In short: grub2 by default on x64 machines only allocates memory only
from first 4GB (0x10000000) physical address to avoid EFI bugs (which
are very common, when programmers EFI using 32bit register for pointers,
which as result causing EFI to crash when system sends x64 bit pointers
during IO proc calls). As result not every machines has enough (1GB
continuous) memory for argon2id keys. So we need allocate memory from
higher regions >4gb. I wrote a smartmem.patch (hack, since it need more
work).

You need argon_*.patch:

* https://aur.archlinux.org/packages/grub-improved-luks2-git

smartmem.patch (allow to allocate >4gb if original allocation <4gb
fails)

This is my original conversation (about smartmem.patch >4gb patch):

* https://savannah.gnu.org/bugs/index.php?64471

Control: tag -1 wontfix upstream

Feel free to land the support upstream, but it's not something that
we should be shipping downstream.

Going forward, for secure boot, our focus is not on adding things, but on removing
existing things like f2fs file support again. It stands to reason
that encrypted /boot should not be supported either as there is no
practical use case (it is security by obscurity) and you are better
served by an unencrypted boot with a pre-built signed initrd or
a MOK-signed initrd (or really UKI), and decrypting untrusted data
hence is unnecessary danger.

I report upstream. But seems like it not going to be fixed anytime
soon. So, I share my smartmem.patch here. But I have no idea how it
works here at Debian. Maybe I better to keep it as is, rebuilding grub
locally.
but on removing

Saying things I put in my pocket are untrusted, but items gaven to me
by other guys with sign, are trusted?! That how security treated here
at debian from all members?

Beside security point, having hudge many GB boot partition with all
kernel installed is a pain. I keep my EFI under 50MB for binaries to
boot.

Regarding the memory allocation, it is much more complex than you think
it is. Unfortunately plenty of devices have broken firmware and will
fail to work with allocations over 4GB, some just DMA files to different
regions when you pass them high memory.

Luckily we managed to fit most initrds into 4GB now so we're probably
safe for now if you don't do crazy things like high-memory password
hashing.

I have absolutely no idea what you're saying, but as you may have seen
by the recent CVE again, we have a lot of problem with code quality and
need to minimize the attack surface as much as reasonably possible.

In an optimal world, /boot would be a separate FAT partition (or well
the ESP directly) and kernels would be copied there [and would be UKI
with pre-built initrd] and we would not have any support for other
file systems or luks or crap. Heck optimally we'd not have any disk
drivers and file systems and just use the firmware implementations :D

argon2id is memory dependent key. Recommended key size (memory
requirements, not the key it self) are 1GB in heap size.

Here is my desktop machine. Memory map using following script (it
showing blocks more then 1MB in size).

dmesg | awk '/usable/ && /BIOS-e820/ && match($0, /mem ([0-9a-z]+)-([0-
9a-z]+)/,aa){s=strtonum(aa[1]);e=strtonum(aa[2]);if(e-
s>1024*1024)printf("0x%x-0x%x %dGB\n",s,e,((e-s)/1024/1024/1024))}'

0x100000-0x35f3cfff 0GB
0x100000000-0x4bfffffff 14GB

It is clear here is no space below 4GB. And argon2id will most likely
fail on that machine if here is no >4GB grub support.
seen
and

I'm sorry. I should be more clear and polite here. I see that FDE (full
disk encryption) is more secure, since I do not have to deal with
signing kernels and init.rd data. Also having FDE reducing the EFI
partition size significantly. So, in ideal world here will be only LUKS
disk encryption, and EFI would support decryption of disk, which will
resolve all CVE grub related issues at once.