On Sat, 22 Aug 2020 00:25:18 +0200 Denis 'GNUtoo' Carikli <gnu...@cyberdimension.org> wrote:
> On Wed, 19 Aug 2020 13:59:57 -0500 > Glenn Washburn <developm...@efficientek.com> wrote: > > > I'm curious, are you using a virtual machine to test grub? If I > > understand correctly the above, you're using physical machines to > > test. I'm using qemu and generally testing with x86_64-efi. > > I don't have a good vm setup for testing yet. I tried to create a self > contained test setup with qemu+coreboot+grub as a payload but it ended > up being too slow (probably due to my key sizes) and messy as I needed > to specify all the modules and I always missed some. I also had issues with things being too slow, like 15min to unlock a luks device. I realized that it was because when cryptosetup adds a key to a luks device it sets the pbkdf iteration count such that it takes '--iter-time' (default 2 seconds) to unlock the master key. The problem was that I was creating the LUKS device outside the VM, but unlocking with the same iteration count inside the VM. And obviously the code running inside the VM is a lot slower. When I created LUKS keys with --pbkdf-force-iterations set to 1000, the minimum, the keys unlocked a lot faster in the VM. > For the v6 I ended up installed grub in /usr/local and then with > grub-install + grub-mkconfig on an x86_64 machine running Coreboot and > SeaBIOS. > > I then created two LVM partitions: one encrypted with the key and the > header inside, and another without a header to be opened, and I tested > by opening the later and accessing a file inside that I read with cat. You may find my grub-shell-luks-tester script in my CRYPTOMOUNT-TEST patch set useful in doing tests in a virtual machine as it does a lot of the setup work. Its fairly flexible in that you can pass a cryptsetup script to control what the luks device looks like and a grub script to interact with the luks device. Unfortunately, I'm not sure how to make it interactive yet in the VM (its real intention purpose is headless automated testing). > So it was more manual but I could reuse the distribution installation > and configuration I already had. > > Denis. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
