> 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.
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.
> 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.
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.
