[bug #55093] Add LUKS2 support

[Joseph Dalrymple]

Follow-up Comment #12, bug #55093 (project grub):

[comment #11 comment #11:]

> comment #10
> > It seems that LUKS2 support has been implemented
> No it is not. Current version is limited to support LUKS2 with PBKDF2 (see
grub-core/disk/luks2.c 461)
> > case LUKS2_KDF_TYPE_ARGON2I:
> > ret = grub_error (GRUB_ERR_BAD_ARGUMENT, "Argon2 not supported");
> 
> > My suggestion is to close this bug and open a new one to address the new
bugs
> Why create an additional page if the errors in this one are still not fully
resolved?

Argon2ID is the default for LUKS2. It supports pbkdf2 for backwards
compatibility, but that's it. It's pretty widely asserted that GRUB2 either
does not, or has *very limited* support for LUKS2. Without Argon2ID support,
GRUB2 will can't be considered to have proper LUKS2 support. That's like
saying that you serve sodas, but don't have the ability to serve it
carbonated. That's just syrup and water.

Friendly jokes aside, this shouldn't be closed until LUKS2 support is
completed.

As Medoo pointed out, there are patches out that have taken upon themselves to
introduce proper support, including the AUR package they referenced
(grub-improved-luks2-git). It may not be difficult to port these in.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64471] grub efi memory allocation (efi/mm) does not work on every machine

[Alexey Kuznetsov]

Follow-up Comment #24, bug #64471 (project grub):

One thing to ask? Did grub has any code related to reading / parsing paging
tables? Looks like it dosn't.

How to read physical memory? Is here grub_ method for that? Or should I switch
to some protected mode back and forth using asm code?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64471] grub efi memory allocation (efi/mm) does not work on every machine

[Alexey Kuznetsov]

Follow-up Comment #23, bug #64471 (project grub):

What I understand from Paging is that I had to request memory from efi using
allocate_pages then check if pages table contains this virtual address, so it
was mapped correctly by the efi.

page table located at physical address pointed by part of CR3 register (12-32+
bits) then parse the table and make sure virtual adress is there. If not, free
efi requested memory and return out of memory error.

Which is raise more even questions...


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Grub XFS normal.mod not found error

[Steve]

Hello,

Last reply from you guys was on the 13th, and we have yet to see issue 
addressed. I, as a Distro maintainer, had to create a new repo where I held 
grub back to r499 as a result of this, not really ideal now is it ?


Kindly update us on the situation and ETA for fix.. 


--

Best Regards.

---
N: Steve, Chaanine
P: Hardware specialist / IT support

[bug #64475] grub failed to initrd /boot/amd-ucode.img in btrfs partition with bees

[Watermelon Rei]

Follow-up Comment #5, bug #64475 (project grub):

Hello, I used 
"qemu-img create -f raw example.img 200M"
to created a 200Mb image file, and 
"losetup /dev/loop0 example.img", 
mounting example.img as a loop device.

Then I formatted the /dev/loop0 by mkfs.btrfs with default options,

"mount /dev/loop0 /boot",
mounting the loop0 device to /boot,
copied the amd-ucode.img file to /boot/amd-ucode_src.img, and I noticed that I
had enabled the zstd compression for my root partition, so I ran 
"btrfs filesystem defragment -r -v -czstd /boot/"
to compress the amd-ucode_src.img file.

After that, started the beesd service for loop0, install the amd-ucode package
by package manager, then I confirmed  the bees deduplicated the
amd-ucode.img.

umount the /boot and "losetup -d /dev/loop0",
I compressed the example.img file with zstd.
I am not sure this image could cause the grub boot failed, just control the
variables as same as possible.
Thanks!

(file #54989)

___

Additional Item Attachment:

File name: example.img.zstSize:61 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/