[PATCH] util/grub-mkfont: Fix resource leaks
---
util/grub-mkfont.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/util/grub-mkfont.c b/util/grub-mkfont.c
index f07566ade..0070edf19 100644
--- a/util/grub-mkfont.c
+++ b/util/grub-mkfont.c
@@ -699,6 +699,7 @@ add_font (struct grub_font_info *font_info, FT_Face face,
int nocut)
}
}
}
+ free(gsub);
}
if (font_info->num_range)
@@ -1322,11 +1323,15 @@ main (int argc, char *argv[])
if (font_verbosity > 1)
print_glyphs (&arguments.font_info);
+ free(arguments.font_info.glyphs_sorted);
+
{
size_t i;
for (i = 0; i < arguments.nfiles; i++)
free (arguments.files[i]);
}
+ free(arguments.files);
+
return 0;
}
--
2.28.0.windows.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 0/3] Cryptomount detached headers
On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
brutser--- via Grub-devel wrote:
> Glenn,
>
>
>
> As I had no idea how to get the debug logs from qemu, I made screenshots,
> find them attached. As this is probably something I am doing wrong, I hope it
> shows from the logs.
>
> https://imgur.com/a/rAlfZ77
Getting the output to go to serial depends on the target. For i386
using seabios, use "-fw_cfg name=etc/sercon-port,string=0 -serial
stdio".
Unfortunately, I'm now seeing that there are no debug log messages
in the luks2 module that would be shown in this case. How about putting
the line 'grub_dprintf("entering luks_scan");' at the start of the
function luks2_scan in grub-core/disk/luks2.c and then recompiling and
getting the output?
Glenn
>
> Van: Glenn Washburn
> Aan: brut...@perso.be
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 29/07/2022 21:27:48 Europe/Paris
> Cc: grub-devel@gnu.org;
> dki...@net-space.pl;
> p...@pks.im
>
> On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> brut...@perso.be wrote:
>
> >
> > testing detached header failed:
> >
> >
> >
> > 1. built grub payload with following modules: ahci usb_keyboard part_msdos
> > part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael gcry_sha1
> > gcry_sha256 gcry_sha512
> >
> > 2. encrypt a partition: cryptsetup luksFormat --type luks2 -q -h sha512 -s
> > 512 --pbkdf pbkdf2 --header /path/to/header --luks2-metadata-size=16k
> > --luks2-keyslots-size=512k /dev/sda1
> >
> > (where --luks2-metadata-size=16k --luks2-keyslots-size=512k is optional,
> > this is just to minimize header size, but I also tested without).
> >
> > 3. from the grub cmd, i try to decrypt this partition using: cryptomount -H
> > /path/to/header (ahci0,msdos1)
> >
> >
> >
> > 4. I also tried luks1 encryption with detached header.
> >
> >
> >
> > whatever I try, I always get the same error:
> >
> > "no cryptodisk module can handle this device"
> >
> >
> >
> > Is this feature not 100% implemented yet, I saw people already verifying
> > the patches and would expect this to be working, so if yes, this seems like
> > a bug.
>
> This feature should be working in all cases, and if not there may be a
> bug. I responded to your off-list email before seeing this one. I'll
> repeat what I said there and let's continue this discussion on the list.
>
> I see nothing obviously wrong with what you're doing, given the
> information above. To further debug this, would you be able to send a
> log of the serial output when the GRUB envvar debug is set to "all"
> while running the cryptomount command? If so, please send compressed in
> a reply to this email on the list.
>
> If you can't because of hardware issues, would you be able to replicate
> this in QEMU and grab the serial output from there? If you can boot the
> system via other means, you should be able to use the raw disks (the
> one with the LUKS volume and the other with the filesystem containing
> the header file).
>
> Glenn
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 0/3] Cryptomount detached headers
Glenn,
Still resorted to screenshots for the debug (with the added dprintf):
https://imgur.com/a/YkVMdBe
Van: Glenn Washburn
Aan: brutser--- via Grub-devel
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 01/08/2022 22:50:27 Europe/Paris
Cc: brut...@perso.be;
dki...@net-space.pl;
p...@pks.im
On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
brutser--- via Grub-devel wrote:
> Glenn,
>
>
>
> As I had no idea how to get the debug logs from qemu, I made screenshots,
> find them attached. As this is probably something I am doing wrong, I hope it
> shows from the logs.
>
> https://imgur.com/a/rAlfZ77
Getting the output to go to serial depends on the target. For i386
using seabios, use "-fw_cfg name=etc/sercon-port,string=0 -serial
stdio".
Unfortunately, I'm now seeing that there are no debug log messages
in the luks2 module that would be shown in this case. How about putting
the line 'grub_dprintf("entering luks_scan");' at the start of the
function luks2_scan in grub-core/disk/luks2.c and then recompiling and
getting the output?
Glenn
>
> Van: Glenn Washburn
> Aan: brut...@perso.be
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 29/07/2022 21:27:48 Europe/Paris
> Cc: grub-devel@gnu.org;
> dki...@net-space.pl;
> p...@pks.im
>
> On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> brut...@perso.be wrote:
>
> >
> > testing detached header failed:
> >
> >
> >
> > 1. built grub payload with following modules: ahci usb_keyboard part_msdos
> > part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael gcry_sha1
> > gcry_sha256 gcry_sha512
> >
> > 2. encrypt a partition: cryptsetup luksFormat --type luks2 -q -h sha512 -s
> > 512 --pbkdf pbkdf2 --header /path/to/header --luks2-metadata-size=16k
> > --luks2-keyslots-size=512k /dev/sda1
> >
> > (where --luks2-metadata-size=16k --luks2-keyslots-size=512k is optional,
> > this is just to minimize header size, but I also tested without).
> >
> > 3. from the grub cmd, i try to decrypt this partition using: cryptomount -H
> > /path/to/header (ahci0,msdos1)
> >
> >
> >
> > 4. I also tried luks1 encryption with detached header.
> >
> >
> >
> > whatever I try, I always get the same error:
> >
> > "no cryptodisk module can handle this device"
> >
> >
> >
> > Is this feature not 100% implemented yet, I saw people already verifying
> > the patches and would expect this to be working, so if yes, this seems like
> > a bug.
>
> This feature should be working in all cases, and if not there may be a
> bug. I responded to your off-list email before seeing this one. I'll
> repeat what I said there and let's continue this discussion on the list.
>
> I see nothing obviously wrong with what you're doing, given the
> information above. To further debug this, would you be able to send a
> log of the serial output when the GRUB envvar debug is set to "all"
> while running the cryptomount command? If so, please send compressed in
> a reply to this email on the list.
>
> If you can't because of hardware issues, would you be able to replicate
> this in QEMU and grab the serial output from there? If you can boot the
> system via other means, you should be able to use the raw disks (the
> one with the LUKS volume and the other with the filesystem containing
> the header file).
>
> Glenn
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v5 9/9] tests: add support for LoongArch
On Fri, 29 Jul 2022 15:12:01 +0800
Xiaotian Wu wrote:
> Signed-off-by: Xiaotian Wu
> ---
> tests/ahci_test.in | 2 +-
> tests/ehci_test.in | 2 +-
> tests/ohci_test.in | 2 +-
> tests/partmap_test.in| 2 +-
> tests/pata_test.in | 2 +-
> tests/uhci_test.in | 2 +-
> tests/util/grub-shell.in | 16
> 7 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/tests/ahci_test.in b/tests/ahci_test.in
> index 6d2e61d4e..70646a24e 100644
> --- a/tests/ahci_test.in
> +++ b/tests/ahci_test.in
> @@ -30,7 +30,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}"
> in
> mips*-arc | mips*-qemu_mips)
> exit 77;;
> # FIXME: No native drivers are available for those
> -powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
> +powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
> exit 77;;
> esac
>
> diff --git a/tests/ehci_test.in b/tests/ehci_test.in
> index df671b4b6..bf823a5de 100644
> --- a/tests/ehci_test.in
> +++ b/tests/ehci_test.in
> @@ -30,7 +30,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}"
> in
> mips*-arc | mips*-qemu_mips)
> exit 77;;
> # FIXME: No native drivers are available for those
> -powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
> +powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
> exit 77;;
> esac
>
> diff --git a/tests/ohci_test.in b/tests/ohci_test.in
> index 741ad881f..a40d3bc0a 100644
> --- a/tests/ohci_test.in
> +++ b/tests/ohci_test.in
> @@ -30,7 +30,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}"
> in
> mips*-arc | mips*-qemu_mips)
> exit 77;;
> # FIXME: No native drivers are available for those
> -powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
> +powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
> exit 77;;
> esac
>
> diff --git a/tests/partmap_test.in b/tests/partmap_test.in
> index 4138e88fe..6db59ce38 100644
> --- a/tests/partmap_test.in
> +++ b/tests/partmap_test.in
> @@ -90,7 +90,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}"
> in
> mipsel-arc)
> disk=arc/scsi0/disk0/rdisk0
> ;;
> -arm*-efi)
> +arm*-efi|loongarch64-efi)
> disk=hd2
The "loongarch64-efi" pattern should be separate and have "disk=hd1"
because the drive is set to show up as hd1 in the grub-shell.in changes
below.
> ;;
> *)
> diff --git a/tests/pata_test.in b/tests/pata_test.in
> index 31144a8fd..4d0e7d573 100644
> --- a/tests/pata_test.in
> +++ b/tests/pata_test.in
> @@ -33,7 +33,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}"
> in
> i386-efi)
> exit 77;;
> # FIXME: No native drivers are available for those
> -powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
> +powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
> exit 77;;
> i386-ieee1275)
> disk=hdb
> diff --git a/tests/uhci_test.in b/tests/uhci_test.in
> index 5aa5eb726..de199a281 100644
> --- a/tests/uhci_test.in
> +++ b/tests/uhci_test.in
> @@ -30,7 +30,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}"
> in
> mips*-arc | mips*-qemu_mips)
> exit 77;;
> # FIXME: No native drivers are available for those
> -powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
> +powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
> exit 77;;
> esac
>
> diff --git a/tests/util/grub-shell.in b/tests/util/grub-shell.in
> index 4828afb7c..b82c8243f 100644
> --- a/tests/util/grub-shell.in
> +++ b/tests/util/grub-shell.in
> @@ -194,6 +194,15 @@ case
> "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" in
> disk="device virtio-blk-device,drive=hd1 -drive if=none,id=hd1,file="
> serial_port=efi0
> ;;
> +loongarch64-efi)
> + qemu=qemu-system-loongarch64
> + boot=hd
> + console=console
> + trim=1
> + qemuopts="-machine virt -cpu la464 -smp 2 -nographic -bios
> /usr/share/qemu/edk2-loongarch64-code.fd $qemuopts"
This would be better as:
qemuopts="-machine virt -cpu la464 -smp 2 -nographic -L "${srcdir}"
-bios edk2-loongarch64-code.fd $qemuopts"
This allows a non-system bios to be used when placed in the grub source
directory and otherwise the file will be searched for in
/usr/share/qemu and other system paths.
> + disk="device virtio-blk-pci,drive=hd1 -drive if=none,id=hd1,file="
> + serial_port=
> + ;;
> *)
> boot=hd
> qemu=qemu-system-i386
> @@ -395,6 +404,8 @@ fi
> if [ x$boot = xhd ]; then
> if [ "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" = arm64-efi ]
> || [ "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" = arm-efi ]; then
> device="device virtio-blk-device,drive=hd0 -drive if=none,id=hd0,file="
> +elif [ "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" =
> loongarch64-efi ]; then
> + device="device virtio-blk-pci,drive=hd0 -drive if=
Re: [PATCH v5 0/9] Add support for LoongArch
On Sat, 30 Jul 2022 14:43:02 +0800 (GMT+08:00) 武校田 wrote: > Thanks for your reply. > > > Thanks for doing this testing. What are the values passed for the > > configure options --build, --host, and --target? > > I compiled it on my local machine, using the Archlinux 2022.03 LoongArch > version, the iso and repository are here: > https://mirrors.wsyu.edu.cn/loongarch/2022.03/ Ok, so to be clear, build, host, and target are all loongarch arctitecture, correct? > > > Also, would you be able to run these tests again on a system with as > > many of the make check test prerequisites installed? They are listed in > > the INSTALL file in the repository root. This would allow the testing > > of various GRUB filesystem code which is not happening now (the reason > > many tests fail with ERROR). > > I will check the dependencies required by grub-fs-tester, thanks. > > > There are two actual failure in the provided log. One is the functional > > test, which are not expected to be working. The other is the partmap > > test, which should be working. Its not clear exactly which sub-test of > > the partmap test is failing (due to output not being very verbose). If > > you add 'set -x' to the top of partmap_test and rerun the tests, I can > > get a clearer picture of what's going on. > > > > Glenn > > > > The details of this partmap_test are as follows: > > + echo 'Checking MSDOS partition types...' > Checking MSDOS partition types... > + create_disk_image /tmp/tmp.N6QvM6XPXY 64 > + name=/tmp/tmp.N6QvM6XPXY > + size=64 > + rm -f /tmp/tmp.N6QvM6XPXY > + dd if=/dev/zero of=/tmp/tmp.N6QvM6XPXY bs=512 count=1 seek=131071 > status=noxfer > 记录了1+0 的读入 > 记录了1+0 的写出 > + parted -a none -s /tmp/tmp.N6QvM6XPXY mklabel msdos > + list_parts part_msdos /tmp/tmp.N6QvM6XPXY /tmp/tmp.dOULt2UJMN > + mod=part_msdos > + shift > + imgfile=/tmp/tmp.N6QvM6XPXY > + shift > + outfile=/tmp/tmp.dOULt2UJMN > + shift > + ./grub-shell --disk=/tmp/tmp.N6QvM6XPXY --modules=part_msdos > + echo ls > WARNING: Image format was not specified for '/tmp/tmp.N6QvM6XPXY' and probing > guessed raw. > Automatically detecting the format is dangerous for raw images, > write operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. > WARNING: Image format was not specified for '/tmp/tmp.mQzmZs2ROc' and probing > guessed raw. > Automatically detecting the format is dangerous for raw images, > write operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. > + cat /tmp/tmp.dOULt2UJMN > + tr -d '\n\r' > (hd0) (hd1) (hd1,gpt3) (hd1,gpt2,msdos1) (hd1,gpt2) (hd1,gpt1) + echo > > + check_output /tmp/tmp.dOULt2UJMN hd2 > + outfile=/tmp/tmp.dOULt2UJMN > + shift > + for dsk in $@ > + grep '(hd2)' /tmp/tmp.dOULt2UJMN > ++ cat /tmp/tmp.dOULt2UJMN > + echo '(hd2): disk/partiton not found in: (hd0) (hd1) (hd1,gpt3) > (hd1,gpt2,msdos1) (hd1,gpt2) (hd1,gpt1) ' > (hd2): disk/partiton not found in: (hd0) (hd1) (hd1,gpt3) (hd1,gpt2,msdos1) > (hd1,gpt2) (hd1,gpt1) > + exit 1 > FAIL partmap_test (exit status: 1) > > It looks like it can't find '(hd2)' in the output. Ok, I believe my comments on patch #9 will successfully address this. What is odd here is that the image file /tmp/tmp.N6QvM6XPXY appears to be reused from a prior test run because at this point is should not have gpt partitions, just an MSDOS header with no partitions. So something seems off here. Glenn > > -- > Best Regards > Xiaotian Wu > > > 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 > > This email and its attachments contain confidential information from Loongson > Technology , which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction or > dissemination) by persons other than the intended recipient(s) is prohibited. > If you receive this email in error, please notify the sender by phone or > email immediately and delete it. > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 0/3] Cryptomount detached headers
On Sat, 30 Jul 2022 20:48:54 +0200 (CEST) brutser--- via Grub-devel wrote: > Glenn, > > > > The most obvious error that jumps out: > > Read out of range: sector 0x32000 (attempt to read or write outside partition) This looks like a red-herring to me. I believe it happens because in opening the header file the disk is probed to see what file system is on it. The error occurs in the probe for cbfs, which fails because its an ext* filesystem. Glenn > > > Van: brutser--- via Grub-devel > Aan: grub-devel@gnu.org > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers > Datum: 30/07/2022 11:54:32 Europe/Paris > Cc: brut...@perso.be; > dki...@net-space.pl; > p...@pks.im > > Glenn, > > > > As I had no idea how to get the debug logs from qemu, I made screenshots, > find them attached. As this is probably something I am doing wrong, I hope it > shows from the logs. > > > > https://imgur.com/a/rAlfZ77 > > > > > Van: Glenn Washburn > Aan: brut...@perso.be > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers > Datum: 29/07/2022 21:27:48 Europe/Paris > Cc: grub-devel@gnu.org; > dki...@net-space.pl; > p...@pks.im > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST) > brut...@perso.be wrote: > > > > > testing detached header failed: > > > > > > > > 1. built grub payload with following modules: ahci usb_keyboard part_msdos > > part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael gcry_sha1 > > gcry_sha256 gcry_sha512 > > > > 2. encrypt a partition: cryptsetup luksFormat --type luks2 -q -h sha512 -s > > 512 --pbkdf pbkdf2 --header /path/to/header --luks2-metadata-size=16k > > --luks2-keyslots-size=512k /dev/sda1 > > > > (where --luks2-metadata-size=16k --luks2-keyslots-size=512k is optional, > > this is just to minimize header size, but I also tested without). > > > > 3. from the grub cmd, i try to decrypt this partition using: cryptomount -H > > /path/to/header (ahci0,msdos1) > > > > > > > > 4. I also tried luks1 encryption with detached header. > > > > > > > > whatever I try, I always get the same error: > > > > "no cryptodisk module can handle this device" > > > > > > > > Is this feature not 100% implemented yet, I saw people already verifying > > the patches and would expect this to be working, so if yes, this seems like > > a bug. > > This feature should be working in all cases, and if not there may be a > bug. I responded to your off-list email before seeing this one. I'll > repeat what I said there and let's continue this discussion on the list. > > I see nothing obviously wrong with what you're doing, given the > information above. To further debug this, would you be able to send a > log of the serial output when the GRUB envvar debug is set to "all" > while running the cryptomount command? If so, please send compressed in > a reply to this email on the list. > > If you can't because of hardware issues, would you be able to replicate > this in QEMU and grab the serial output from there? If you can boot the > system via other means, you should be able to use the raw disks (the > one with the LUKS volume and the other with the filesystem containing > the header file). > > Glenn > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 0/3] Cryptomount detached headers
On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
brutser--- via Grub-devel wrote:
> Glenn,
>
>
>
> Still resorted to screenshots for the debug (with the added dprintf):
>
>
>
> https://imgur.com/a/YkVMdBe
Ok, that confirms that the luks2 module is loaded and that the scan is
happening. Based on the output I think luks2_read_header must be
failing. That means that either disk reads are failing, which doesn't
seem like the case, the disk read hook is failing or the LUKS2 magic
bytes are not what they should be.
Have you verified that after creating the volume and header file that
cryptsetup/dm can open the volume successfully?
What architecture and endianness is the machine you're running
cryptsetup on and what is it for the one GRUB is running on?
To test the read hook, add 'grub_dprintf("luks2", "read hook
successed");' just before the last return statement in the function
cryptodisk_read_hook in grub-core/disk/cryptodisk.c.
Glenn
>
>
>
> Van: Glenn Washburn
> Aan: brutser--- via Grub-devel
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 01/08/2022 22:50:27 Europe/Paris
> Cc: brut...@perso.be;
> dki...@net-space.pl;
> p...@pks.im
>
> On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> brutser--- via Grub-devel wrote:
>
> > Glenn,
> >
> >
> >
> > As I had no idea how to get the debug logs from qemu, I made screenshots,
> > find them attached. As this is probably something I am doing wrong, I hope
> > it shows from the logs.
> >
> > https://imgur.com/a/rAlfZ77
>
> Getting the output to go to serial depends on the target. For i386
> using seabios, use "-fw_cfg name=etc/sercon-port,string=0 -serial
> stdio".
>
> Unfortunately, I'm now seeing that there are no debug log messages
> in the luks2 module that would be shown in this case. How about putting
> the line 'grub_dprintf("entering luks_scan");' at the start of the
> function luks2_scan in grub-core/disk/luks2.c and then recompiling and
> getting the output?
>
> Glenn
>
>
> >
> > Van: Glenn Washburn
> > Aan: brut...@perso.be
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 29/07/2022 21:27:48 Europe/Paris
> > Cc: grub-devel@gnu.org;
> > dki...@net-space.pl;
> > p...@pks.im
> >
> > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > brut...@perso.be wrote:
> >
> > >
> > > testing detached header failed:
> > >
> > >
> > >
> > > 1. built grub payload with following modules: ahci usb_keyboard
> > > part_msdos part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael
> > > gcry_sha1 gcry_sha256 gcry_sha512
> > >
> > > 2. encrypt a partition: cryptsetup luksFormat --type luks2 -q -h sha512
> > > -s 512 --pbkdf pbkdf2 --header /path/to/header --luks2-metadata-size=16k
> > > --luks2-keyslots-size=512k /dev/sda1
> > >
> > > (where --luks2-metadata-size=16k --luks2-keyslots-size=512k is optional,
> > > this is just to minimize header size, but I also tested without).
> > >
> > > 3. from the grub cmd, i try to decrypt this partition using: cryptomount
> > > -H /path/to/header (ahci0,msdos1)
> > >
> > >
> > >
> > > 4. I also tried luks1 encryption with detached header.
> > >
> > >
> > >
> > > whatever I try, I always get the same error:
> > >
> > > "no cryptodisk module can handle this device"
> > >
> > >
> > >
> > > Is this feature not 100% implemented yet, I saw people already verifying
> > > the patches and would expect this to be working, so if yes, this seems
> > > like a bug.
> >
> > This feature should be working in all cases, and if not there may be a
> > bug. I responded to your off-list email before seeing this one. I'll
> > repeat what I said there and let's continue this discussion on the list.
> >
> > I see nothing obviously wrong with what you're doing, given the
> > information above. To further debug this, would you be able to send a
> > log of the serial output when the GRUB envvar debug is set to "all"
> > while running the cryptomount command? If so, please send compressed in
> > a reply to this email on the list.
> >
> > If you can't because of hardware issues, would you be able to replicate
> > this in QEMU and grab the serial output from there? If you can boot the
> > system via other means, you should be able to use the raw disks (the
> > one with the LUKS volume and the other with the filesystem containing
> > the header file).
> >
> > Glenn
> >
> >
> > ___
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3 0/3] Cryptomount detached headers
Debian 11.4 for all the testing.
as i said, i execute shell during installation, then simply enter the commands
I wrote earlier:
cryptsetup luksFormat --type luks2 -q -h sha512 -s 512 --pbkdf pbkdf2 --header
/root/header.bin --luks2-metadata-size=16k --luks2-keyslots-size=512k /dev/sda2
cryptsetup luksOpen --header /root/header.bin /dev/sda2 sda2crypt
pvcreate /dev/mapper/sda2crypt
vgcreate testvg /dev/mapper/sda2crypt
lvcreate -L 2G -n root testvg
- continue install debian 11.4
- chroot into system
- copy header
- populate crypttab etc.
this whole process works 100% fine with grub 2.04 and luks1 as i said before...
Van: Glenn Washburn
Aan: brutser--- via Grub-devel
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 02/08/2022 01:24:47 Europe/Paris
Cc: brut...@perso.be;
dki...@net-space.pl;
p...@pks.im
On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
brutser--- via Grub-devel wrote:
> Glenn,
>
>
>
> Still resorted to screenshots for the debug (with the added dprintf):
>
>
>
> https://imgur.com/a/YkVMdBe
Ok, that confirms that the luks2 module is loaded and that the scan is
happening. Based on the output I think luks2_read_header must be
failing. That means that either disk reads are failing, which doesn't
seem like the case, the disk read hook is failing or the LUKS2 magic
bytes are not what they should be.
Have you verified that after creating the volume and header file that
cryptsetup/dm can open the volume successfully?
What architecture and endianness is the machine you're running
cryptsetup on and what is it for the one GRUB is running on?
To test the read hook, add 'grub_dprintf("luks2", "read hook
successed");' just before the last return statement in the function
cryptodisk_read_hook in grub-core/disk/cryptodisk.c.
Glenn
>
>
>
> Van: Glenn Washburn
> Aan: brutser--- via Grub-devel
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 01/08/2022 22:50:27 Europe/Paris
> Cc: brut...@perso.be;
> dki...@net-space.pl;
> p...@pks.im
>
> On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> brutser--- via Grub-devel wrote:
>
> > Glenn,
> >
> >
> >
> > As I had no idea how to get the debug logs from qemu, I made screenshots,
> > find them attached. As this is probably something I am doing wrong, I hope
> > it shows from the logs.
> >
> > https://imgur.com/a/rAlfZ77
>
> Getting the output to go to serial depends on the target. For i386
> using seabios, use "-fw_cfg name=etc/sercon-port,string=0 -serial
> stdio".
>
> Unfortunately, I'm now seeing that there are no debug log messages
> in the luks2 module that would be shown in this case. How about putting
> the line 'grub_dprintf("entering luks_scan");' at the start of the
> function luks2_scan in grub-core/disk/luks2.c and then recompiling and
> getting the output?
>
> Glenn
>
>
> >
> > Van: Glenn Washburn
> > Aan: brut...@perso.be
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 29/07/2022 21:27:48 Europe/Paris
> > Cc: grub-devel@gnu.org;
> > dki...@net-space.pl;
> > p...@pks.im
> >
> > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > brut...@perso.be wrote:
> >
> > >
> > > testing detached header failed:
> > >
> > >
> > >
> > > 1. built grub payload with following modules: ahci usb_keyboard
> > > part_msdos part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael
> > > gcry_sha1 gcry_sha256 gcry_sha512
> > >
> > > 2. encrypt a partition: cryptsetup luksFormat --type luks2 -q -h sha512
> > > -s 512 --pbkdf pbkdf2 --header /path/to/header --luks2-metadata-size=16k
> > > --luks2-keyslots-size=512k /dev/sda1
> > >
> > > (where --luks2-metadata-size=16k --luks2-keyslots-size=512k is optional,
> > > this is just to minimize header size, but I also tested without).
> > >
> > > 3. from the grub cmd, i try to decrypt this partition using: cryptomount
> > > -H /path/to/header (ahci0,msdos1)
> > >
> > >
> > >
> > > 4. I also tried luks1 encryption with detached header.
> > >
> > >
> > >
> > > whatever I try, I always get the same error:
> > >
> > > "no cryptodisk module can handle this device"
> > >
> > >
> > >
> > > Is this feature not 100% implemented yet, I saw people already verifying
> > > the patches and would expect this to be working, so if yes, this seems
> > > like a bug.
> >
> > This feature should be working in all cases, and if not there may be a
> > bug. I responded to your off-list email before seeing this one. I'll
> > repeat what I said there and let's continue this discussion on the list.
> >
> > I see nothing obviously wrong with what you're doing, given the
> > information above. To further debug this, would you be able to send a
> > log of the serial output when the GRUB envvar debug is set to "all"
> > while running the cryptomount command? If so, please send compressed in
> > a reply to this email on the list.
> >
> > If you can't because of hardware issues, would you be able to replicate
> > thi
Re: [PATCH v3 0/3] Cryptomount detached headers
Glenn,
But my testing is very limited, i only create grub payload for coreboot and
then i create the encrypted sda2 from the debian expert installer etc.
If you got suggestions with this setup, how i can do another way of testing,
let me know and I will do it.
Van: brutser--- via Grub-devel
Aan: grub-devel@gnu.org
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 02/08/2022 01:47:57 Europe/Paris
Cc: brut...@perso.be;
dki...@net-space.pl;
p...@pks.im
Debian 11.4 for all the testing.
as i said, i execute shell during installation, then simply enter the commands
I wrote earlier:
cryptsetup luksFormat --type luks2 -q -h sha512 -s 512 --pbkdf pbkdf2 --header
/root/header.bin --luks2-metadata-size=16k --luks2-keyslots-size=512k /dev/sda2
cryptsetup luksOpen --header /root/header.bin /dev/sda2 sda2crypt
pvcreate /dev/mapper/sda2crypt
vgcreate testvg /dev/mapper/sda2crypt
lvcreate -L 2G -n root testvg
- continue install debian 11.4
- chroot into system
- copy header
- populate crypttab etc.
this whole process works 100% fine with grub 2.04 and luks1 as i said before...
Van: Glenn Washburn
Aan: brutser--- via Grub-devel
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 02/08/2022 01:24:47 Europe/Paris
Cc: brut...@perso.be;
dki...@net-space.pl;
p...@pks.im
On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
brutser--- via Grub-devel wrote:
> Glenn,
>
>
>
> Still resorted to screenshots for the debug (with the added dprintf):
>
>
>
> https://imgur.com/a/YkVMdBe
Ok, that confirms that the luks2 module is loaded and that the scan is
happening. Based on the output I think luks2_read_header must be
failing. That means that either disk reads are failing, which doesn't
seem like the case, the disk read hook is failing or the LUKS2 magic
bytes are not what they should be.
Have you verified that after creating the volume and header file that
cryptsetup/dm can open the volume successfully?
What architecture and endianness is the machine you're running
cryptsetup on and what is it for the one GRUB is running on?
To test the read hook, add 'grub_dprintf("luks2", "read hook
successed");' just before the last return statement in the function
cryptodisk_read_hook in grub-core/disk/cryptodisk.c.
Glenn
>
>
>
> Van: Glenn Washburn
> Aan: brutser--- via Grub-devel
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 01/08/2022 22:50:27 Europe/Paris
> Cc: brut...@perso.be;
> dki...@net-space.pl;
> p...@pks.im
>
> On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> brutser--- via Grub-devel wrote:
>
> > Glenn,
> >
> >
> >
> > As I had no idea how to get the debug logs from qemu, I made screenshots,
> > find them attached. As this is probably something I am doing wrong, I hope
> > it shows from the logs.
> >
> > https://imgur.com/a/rAlfZ77
>
> Getting the output to go to serial depends on the target. For i386
> using seabios, use "-fw_cfg name=etc/sercon-port,string=0 -serial
> stdio".
>
> Unfortunately, I'm now seeing that there are no debug log messages
> in the luks2 module that would be shown in this case. How about putting
> the line 'grub_dprintf("entering luks_scan");' at the start of the
> function luks2_scan in grub-core/disk/luks2.c and then recompiling and
> getting the output?
>
> Glenn
>
>
> >
> > Van: Glenn Washburn
> > Aan: brut...@perso.be
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 29/07/2022 21:27:48 Europe/Paris
> > Cc: grub-devel@gnu.org;
> > dki...@net-space.pl;
> > p...@pks.im
> >
> > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > brut...@perso.be wrote:
> >
> > >
> > > testing detached header failed:
> > >
> > >
> > >
> > > 1. built grub payload with following modules: ahci usb_keyboard
> > > part_msdos part_gpt at_keyboard cbfs cryptodisk luks2 lvm gcry_rijndael
> > > gcry_sha1 gcry_sha256 gcry_sha512
> > >
> > > 2. encrypt a partition: cryptsetup luksFormat --type luks2 -q -h sha512
> > > -s 512 --pbkdf pbkdf2 --header /path/to/header --luks2-metadata-size=16k
> > > --luks2-keyslots-size=512k /dev/sda1
> > >
> > > (where --luks2-metadata-size=16k --luks2-keyslots-size=512k is optional,
> > > this is just to minimize header size, but I also tested without).
> > >
> > > 3. from the grub cmd, i try to decrypt this partition using: cryptomount
> > > -H /path/to/header (ahci0,msdos1)
> > >
> > >
> > >
> > > 4. I also tried luks1 encryption with detached header.
> > >
> > >
> > >
> > > whatever I try, I always get the same error:
> > >
> > > "no cryptodisk module can handle this device"
> > >
> > >
> > >
> > > Is this feature not 100% implemented yet, I saw people already verifying
> > > the patches and would expect this to be working, so if yes, this seems
> > > like a bug.
> >
> > This feature should be working in all cases, and if not there may be a
> > bug. I responded to your off-list email before seeing this one. I'll
> > repe
Re: [PATCH v5 0/9] Add support for LoongArch
在 2022/8/2 上午6:44, Glenn Washburn 写道: On Sat, 30 Jul 2022 14:43:02 +0800 (GMT+08:00) 武校田 wrote: Thanks for your reply. > Thanks for doing this testing. What are the values passed for the > configure options --build, --host, and --target? I compiled it on my local machine, using the Archlinux 2022.03 LoongArch version, the iso and repository are here: https://mirrors.wsyu.edu.cn/loongarch/2022.03/ Ok, so to be clear, build, host, and target are all loongarch arctitecture, correct? Yes, build, host and target are all loongarch arctitecture. > Also, would you be able to run these tests again on a system with as > many of the make check test prerequisites installed? They are listed in > the INSTALL file in the repository root. This would allow the testing > of various GRUB filesystem code which is not happening now (the reason > many tests fail with ERROR). I will check the dependencies required by grub-fs-tester, thanks. > There are two actual failure in the provided log. One is the functional > test, which are not expected to be working. The other is the partmap > test, which should be working. Its not clear exactly which sub-test of > the partmap test is failing (due to output not being very verbose). If > you add 'set -x' to the top of partmap_test and rerun the tests, I can > get a clearer picture of what's going on. > > Glenn > The details of this partmap_test are as follows: + echo 'Checking MSDOS partition types...' Checking MSDOS partition types... + create_disk_image /tmp/tmp.N6QvM6XPXY 64 + name=/tmp/tmp.N6QvM6XPXY + size=64 + rm -f /tmp/tmp.N6QvM6XPXY + dd if=/dev/zero of=/tmp/tmp.N6QvM6XPXY bs=512 count=1 seek=131071 status=noxfer 记录了1+0 的读入 记录了1+0 的写出 + parted -a none -s /tmp/tmp.N6QvM6XPXY mklabel msdos + list_parts part_msdos /tmp/tmp.N6QvM6XPXY /tmp/tmp.dOULt2UJMN + mod=part_msdos + shift + imgfile=/tmp/tmp.N6QvM6XPXY + shift + outfile=/tmp/tmp.dOULt2UJMN + shift + ./grub-shell --disk=/tmp/tmp.N6QvM6XPXY --modules=part_msdos + echo ls WARNING: Image format was not specified for '/tmp/tmp.N6QvM6XPXY' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. WARNING: Image format was not specified for '/tmp/tmp.mQzmZs2ROc' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. + cat /tmp/tmp.dOULt2UJMN + tr -d '\n\r' (hd0) (hd1) (hd1,gpt3) (hd1,gpt2,msdos1) (hd1,gpt2) (hd1,gpt1) + echo + check_output /tmp/tmp.dOULt2UJMN hd2 + outfile=/tmp/tmp.dOULt2UJMN + shift + for dsk in $@ + grep '(hd2)' /tmp/tmp.dOULt2UJMN ++ cat /tmp/tmp.dOULt2UJMN + echo '(hd2): disk/partiton not found in: (hd0) (hd1) (hd1,gpt3) (hd1,gpt2,msdos1) (hd1,gpt2) (hd1,gpt1) ' (hd2): disk/partiton not found in: (hd0) (hd1) (hd1,gpt3) (hd1,gpt2,msdos1) (hd1,gpt2) (hd1,gpt1) + exit 1 FAIL partmap_test (exit status: 1) It looks like it can't find '(hd2)' in the output. Ok, I believe my comments on patch #9 will successfully address this. What is odd here is that the image file /tmp/tmp.N6QvM6XPXY appears to be reused from a prior test run because at this point is should not have gpt partitions, just an MSDOS header with no partitions. So something seems off here. Ok, thank you for your comments in #9, I think I have fixed the issue, and partmap_test has passed. -- Best Regards Xiaotian Wu ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v5 9/9] tests: add support for LoongArch
在 2022/8/2 上午6:33, Glenn Washburn 写道:
On Fri, 29 Jul 2022 15:12:01 +0800
Xiaotian Wu wrote:
Signed-off-by: Xiaotian Wu
---
tests/ahci_test.in | 2 +-
tests/ehci_test.in | 2 +-
tests/ohci_test.in | 2 +-
tests/partmap_test.in| 2 +-
tests/pata_test.in | 2 +-
tests/uhci_test.in | 2 +-
tests/util/grub-shell.in | 16
7 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/tests/ahci_test.in b/tests/ahci_test.in
index 6d2e61d4e..70646a24e 100644
--- a/tests/ahci_test.in
+++ b/tests/ahci_test.in
@@ -30,7 +30,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" in
mips*-arc | mips*-qemu_mips)
exit 77;;
# FIXME: No native drivers are available for those
-powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
+powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
exit 77;;
esac
diff --git a/tests/ehci_test.in b/tests/ehci_test.in
index df671b4b6..bf823a5de 100644
--- a/tests/ehci_test.in
+++ b/tests/ehci_test.in
@@ -30,7 +30,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" in
mips*-arc | mips*-qemu_mips)
exit 77;;
# FIXME: No native drivers are available for those
-powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
+powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
exit 77;;
esac
diff --git a/tests/ohci_test.in b/tests/ohci_test.in
index 741ad881f..a40d3bc0a 100644
--- a/tests/ohci_test.in
+++ b/tests/ohci_test.in
@@ -30,7 +30,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" in
mips*-arc | mips*-qemu_mips)
exit 77;;
# FIXME: No native drivers are available for those
-powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
+powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
exit 77;;
esac
diff --git a/tests/partmap_test.in b/tests/partmap_test.in
index 4138e88fe..6db59ce38 100644
--- a/tests/partmap_test.in
+++ b/tests/partmap_test.in
@@ -90,7 +90,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" in
mipsel-arc)
disk=arc/scsi0/disk0/rdisk0
;;
-arm*-efi)
+arm*-efi|loongarch64-efi)
disk=hd2
The "loongarch64-efi" pattern should be separate and have "disk=hd1"
because the drive is set to show up as hd1 in the grub-shell.in changes
below.
This is indeed a issue. When I delete loongarch64-efi and use the
default hd0 directly, the partmap_test passed.
;;
*)
diff --git a/tests/pata_test.in b/tests/pata_test.in
index 31144a8fd..4d0e7d573 100644
--- a/tests/pata_test.in
+++ b/tests/pata_test.in
@@ -33,7 +33,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" in
i386-efi)
exit 77;;
# FIXME: No native drivers are available for those
-powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
+powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
exit 77;;
i386-ieee1275)
disk=hdb
diff --git a/tests/uhci_test.in b/tests/uhci_test.in
index 5aa5eb726..de199a281 100644
--- a/tests/uhci_test.in
+++ b/tests/uhci_test.in
@@ -30,7 +30,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" in
mips*-arc | mips*-qemu_mips)
exit 77;;
# FIXME: No native drivers are available for those
-powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi)
+powerpc-ieee1275 | sparc64-ieee1275 | arm*-efi | loongarch64-efi)
exit 77;;
esac
diff --git a/tests/util/grub-shell.in b/tests/util/grub-shell.in
index 4828afb7c..b82c8243f 100644
--- a/tests/util/grub-shell.in
+++ b/tests/util/grub-shell.in
@@ -194,6 +194,15 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}"
in
disk="device virtio-blk-device,drive=hd1 -drive if=none,id=hd1,file="
serial_port=efi0
;;
+loongarch64-efi)
+ qemu=qemu-system-loongarch64
+ boot=hd
+ console=console
+ trim=1
+ qemuopts="-machine virt -cpu la464 -smp 2 -nographic -bios
/usr/share/qemu/edk2-loongarch64-code.fd $qemuopts"
This would be better as:
qemuopts="-machine virt -cpu la464 -smp 2 -nographic -L "${srcdir}"
-bios edk2-loongarch64-code.fd $qemuopts"
This allows a non-system bios to be used when placed in the grub source
directory and otherwise the file will be searched for in
/usr/share/qemu and other system paths.
Ok, I will change it in the v6 patch series.
+ disk="device virtio-blk-pci,drive=hd1 -drive if=none,id=hd1,file="
+ serial_port=
+ ;;
*)
boot=hd
qemu=qemu-system-i386
@@ -395,6 +404,8 @@ fi
if [ x$boot = xhd ]; then
if [ "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" = arm64-efi ] || [
"${grub_modinfo_target_cpu}-${grub_modinfo_platform}" = arm-efi ]; then
device="device virtio-blk-device,drive=hd0 -drive if=none,id=hd0,file="
+elif [ "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" =
loongarch64-efi ]; then
+ de
