Re: [PATCH] cryptodisk: Incorrect calculation of sector in grub_cryptodisk_read/write.
On Wed, Aug 26, 2020 at 06:50:29PM -0500, Glenn Washburn wrote: > On Wed, 26 Aug 2020 18:44:35 -0500 > Glenn Washburn wrote: > > > Here dev is a grub_cryptodisk_t and dev->offset is offset in sectors > > of size native to the cryptodisk device. The function grub_disk_read > > expects that the given start sector is in the native grub sector > > size, so dev->offset must be converted as well. Create function > > grub_disk_from_native_sector to convert disk sectors to grub sectors. > > Upon reviewing my previous patch, I realized that the updated commit > message had gotten lost. So this only changes the commit message and > not the diff itself. I don't think its imperative to have this updated > commit message, but I do think it more clearly and accurately describes > the patch. > > Glenn I did already update the commit's title in v2 of my patch series, but not its body. I'll pick your improvement if there's a need for v3 of my patch series, thanks! Patrick signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 0/9] Cryptodisk fixes for v2.06
On Wed, Aug 26, 2020 at 05:16:57PM -0500, Glenn Washburn wrote: > On Wed, 26 Aug 2020 10:13:18 +0200 > Patrick Steinhardt wrote: > > > I didn't yet get your test series to work, Glenn. I'll try again on > > another day as I'm not on top of things today. Meanwhile, could you > > please give it a go with this updated patch series? > > I've tested with this patch series and all tests pass. Thanks for letting me know. > Which part isn't working for the tests? The patchset (on the > mailinglist) has expected failures for all LUKS2 tests because my LUKS2 > keyfile patch is needed. So the tests should be able to verify that > LUKS1 tests are passing before and after this patchset. As I said, it's mostly me not having the brain capacity right now. Next to the keyfile dependency I'd also have to change MAC policies on my system or set up a VM for it, but I don't feel too well this week and thus need to defer this. > Here's the branch I created that has your patch series, the v5 crypto > keyfile and detached header patch series, my cryptomount test patches, > my luks2 keyfile patch, and patches turning on tests now expecting to > pass in that order applied to master. > > https://github.com/crass/grub/tree/cryptodisk-fixes-for-v2.06.v2+cryptodisk-v5+cryptodisk-tests > > Here is a command sequence that should show the cryptomount test as > passing. You can look at some more details of the testing in the test > log file grub_cmd_cryptomount.log. Once you see the tests passing, you > can remove some of the commits in the patch series and verify that the > test fails and that the appropriate subtest fails by checking the log > file. > > --- > git clone https://github.com/crass/grub.git > cd grub > git checkout > cryptodisk-fixes-for-v2.06.v2+cryptodisk-v5+cryptodisk-tests > ./bootstrap && ./configure && make -j8 > sudo env TESTS=grub_cmd_cryptomount make -e check VERBOSE=yes SUBDIRS= > --- Thanks a lot for these! Patrick signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Quoting issues in Bash script `grub-fs-tester` causes F2FS test failure
Dear GRUB folks,
Running `sudo env make -e check VERBOSE=yes SUBDIRS=` the F2FS is one of
the two tests failing. It returns 255.
Running only the specific test
sudo env TESTS=f2fs_test make -e check VERBOSE=yes SUBDIRS=
which runs
sudo ./grub-fs-tester f2fs
and using `set -ex` in `grub-fs-tester` the call below has quoting issues.
xf2fs)
"mkfs.f2fs" -l "$FSLABEL" -q "${LODEVICES[0]}"
fails due to the loop device being passed in single quotes, which does
not exist with the leading space.
+ LODEVICE=/dev/loop11
+ LODEVICES=' /dev/loop11'
+ mkfs.f2fs -l
'grub_;/testé䏌䐓䏕киритiurewfceniuewruewnuuireurevueurnievrewfnerfcnevirivinrewvnirewnivrewiuvcrewvnuewvrrrewniuerwreiuviurewiuviurewnuvewnvrenurnunuvrevuurerejiremvreijnvvcreivire
nverivnreivrevnureiorfnfrvoeoiroireoireoifrefoieroifoirvcreivire
nverivnreivrevnureiorfnfrvoeoiroireoireoifrefoieroifoircreivire
nverivnreivrevnureiorfnfrvoeoiroireoireoifrefoieroifoireoifoiq' -q '
/dev/loop11'
FAIL f2fs_test (exit status: 255)
Is there a Bash expert in here, able to fix it?
Kind regards,
Paul
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results
I run Arch Linux as an encrypted /, /boot and swap system. That encrypted /boot is nothing more than a folder under /, however two Keyslots are required to boot. If I understand the boot process correctly, LUKS Keyslot 1 is used by grub to unlock /boot, then control is handed off to the kernel which uses Keyslot 0 to unlock /. My passphrase, entered once, unlocks both. Grub can easily unlock /boot, assuming / is originally encrypted as a `type= luks1` partition. It seems, however, it is not possible for grub to unlock this same /boot if / is converted to `--type= luks2`. Is my assumption correct, and if so, what is preventing grub from this `type= luks2` /boot unlocking? I am running: grub-git 2.04.rc1.r19.g4e7b5bb3b-1 from the Arch (AUR). This package was last updated on 7 Feb 2020. See: https://aur.archlinux.org/packages/grub-git/ I originally encrypted the partition with: `cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --use-random --type luks1 luksFormat /dev/sdXZ` Then I set up two LVs: swap (512M) and / (remaining partition space). That swap LV is assigned as `dm-1` and / is assigned as `dm-2`. dm-2 runs BTRFS, if that matters. Grub boots that system without issue. The process I used to test LUKS2 encrypted /boot support: 1. UEFI boot from any reasonably recent arch iso, and run: `cryptsetup convert --type luks2 /dev/sdXZ`. That command will succeed, and luksDump will show PBKDF: pbkdf2 for both Keyslot 0 and 1. 2. Run cryptsetup open /dev/sdXY 3. Mount everything and arch-chroot into / 4. Run `mkinitcpio -P linux` 5. Run `grub-install --target=x86_64-efi --efi-directory=/efi --modules="luks2 part_gpt cryptodisk" --bootloader-id=`. Note: If `--modules="luks2 part_gpt cryptodisk" ` is not appended to grub-install, then the `ls` results in step 9 (below) only lists (proc) and (hd0) - and/or cryptodisk: command not found. 6. Run grub-mkconfig -o /boot/grub/grub.cfg 7. Exit, umount and reboot. 8. Immediately following power on: you are greeted by the dreaded: error: disk 'lvmid/some-lengthy-UUID' not found. Entering rescue mode. That lengthy UUID is exact UUID of my `dm-2` which is my encrypted / LV. 9. At the `grub rescue>` prompt: type `ls`. There I see (proc) (hd0) and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where my encrypted / resides. 10. Still at `grub rescue>` type: `cryptomount (hd0,gpt7)` which then requires my passphrase. After correct passphrase entry, and hitting Enter only returns: `error: Could not parse digest 1.` Incredibly, if you repeat step 10 and intentionally enter an incorrect passphrase, you get the same: `error: Could not parse digest 1.` In fact, if you enter NO passphrase and hit Enter, you also get: `error: Could not parse digest 1.` Very frustrating indeed! Does anyone know why grub is failing this way, and does a workaround exist? Thank you for your time...suggestions welcome.___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results
On 8/28/20 11:28 AM, HardenedArray via Grub-devel wrote: > I run Arch Linux as an encrypted /, /boot and swap system. That > encrypted /boot is nothing more than a folder under /, however two > Keyslots are required to boot. > > If I understand the boot process correctly, LUKS Keyslot 1 is used by > grub to unlock /boot, then control is handed off to the kernel which > uses Keyslot 0 to unlock /. My passphrase, entered once, unlocks > both. > > Grub can easily unlock /boot, assuming / is originally encrypted as a > `type= luks1` partition. It seems, however, it is not possible for > grub to unlock this same /boot if / is converted to `--type= luks2`. > > Is my assumption correct, and if so, what is preventing grub from > this `type= luks2` /boot unlocking? > > I am running: grub-git 2.04.rc1.r19.g4e7b5bb3b-1 from the Arch (AUR). > This package was last updated on 7 Feb 2020. See: > https://aur.archlinux.org/packages/grub-git/ > > I originally encrypted the partition with: `cryptsetup -c > aes-xts-plain64 -h sha512 -s 512 --use-random --type luks1 luksFormat > /dev/sdXZ` > > Then I set up two LVs: swap (512M) and / (remaining partition space). > That swap LV is assigned as `dm-1` and / is assigned as `dm-2`. dm-2 > runs BTRFS, if that matters. Grub boots that system without issue. > > The process I used to test LUKS2 encrypted /boot support: > > 1. UEFI boot from any reasonably recent arch iso, and run: > `cryptsetup convert --type luks2 /dev/sdXZ`. That command will > succeed, and luksDump will show PBKDF: pbkdf2 for both Keyslot 0 and > 1. > > 2. Run cryptsetup open /dev/sdXY > > 3. Mount everything and arch-chroot into / > > 4. Run `mkinitcpio -P linux` > > 5. Run `grub-install --target=x86_64-efi --efi-directory=/efi > --modules="luks2 part_gpt cryptodisk" --bootloader-id=`. > > Note: If `--modules="luks2 part_gpt cryptodisk" ` is not appended to > grub-install, then the `ls` results in step 9 (below) only lists > (proc) and (hd0) - and/or cryptodisk: command not found. > > 6. Run grub-mkconfig -o /boot/grub/grub.cfg > > 7. Exit, umount and reboot. > > 8. Immediately following power on: you are greeted by the dreaded: > error: disk 'lvmid/some-lengthy-UUID' not found. Entering rescue > mode. That lengthy UUID is exact UUID of my `dm-2` which is my > encrypted / LV. > > 9. At the `grub rescue>` prompt: type `ls`. There I see (proc) (hd0) > and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where > my encrypted / resides. > > 10. Still at `grub rescue>` type: `cryptomount (hd0,gpt7)` which then > requires my passphrase. After correct passphrase entry, and hitting > Enter only returns: > > `error: Could not parse digest 1.` > > Incredibly, if you repeat step 10 and intentionally enter an > incorrect passphrase, you get the same: > > `error: Could not parse digest 1.` > > In fact, if you enter NO passphrase and hit Enter, you also get: > > `error: Could not parse digest 1.` > > Very frustrating indeed! > > Does anyone know why grub is failing this way, and does a workaround > exist? > > Thank you for your time...suggestions welcome. If I remember correctly, you mentioned on IRC that you could successfully use grub-git to cryptomount a luks1 /boot/grub directory, then use the grub modules there to further cryptomount a luks2 partition. The problem sounded like an issue actually getting grub-install to generate a grubx64.efi with proper, usable luks2 support. Am I right? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results
Hi Eli, Unless I missed what I said in this very long, convoluted LUKS2 IRC history, I do not recall telling you that I could cryptomount from a --type luks1 partition, simply because I had never had a reason to do so. Again, grub boots my luks1 encrypted /boot system without issue, meaning I enter my passphrase at the grub (correct /dev/sda7 UUID) prompt (and NOT the `grub rescue>`) prompt and then boot continues until I reach KDE's SDDM login. What I think I told you is: once I'm logged into KDE on my luks1 encrypted /boot system, I can easily mount another luks2 encrypted / on another partition, be that Fedora or some other OS. No cryptomount command or `grub rescue> prompt involved. Only entering the correct LUKS passphrase is required. Hope that helps... ‐‐‐ Original Message ‐‐‐ On Friday, August 28, 2020 3:37 PM, Eli Schwartz wrote: > On 8/28/20 11:28 AM, HardenedArray via Grub-devel wrote: > > > I run Arch Linux as an encrypted /, /boot and swap system. That > > encrypted /boot is nothing more than a folder under /, however two > > Keyslots are required to boot. > > If I understand the boot process correctly, LUKS Keyslot 1 is used by > > grub to unlock /boot, then control is handed off to the kernel which > > uses Keyslot 0 to unlock /. My passphrase, entered once, unlocks > > both. > > Grub can easily unlock /boot, assuming / is originally encrypted as a > > `type= luks1` partition. It seems, however, it is not possible for > > grub to unlock this same /boot if / is converted to `--type= luks2`. > > Is my assumption correct, and if so, what is preventing grub from > > this `type= luks2` /boot unlocking? > > I am running: grub-git 2.04.rc1.r19.g4e7b5bb3b-1 from the Arch (AUR). > > This package was last updated on 7 Feb 2020. See: > > https://aur.archlinux.org/packages/grub-git/ > > I originally encrypted the partition with: `cryptsetup -c aes-xts-plain64 > > -h sha512 -s 512 --use-random --type luks1 luksFormat /dev/sdXZ` > > Then I set up two LVs: swap (512M) and / (remaining partition space). > > That swap LV is assigned as `dm-1` and / is assigned as `dm-2`. dm-2 > > runs BTRFS, if that matters. Grub boots that system without issue. > > The process I used to test LUKS2 encrypted /boot support: > > > > 1. UEFI boot from any reasonably recent arch iso, and run: > > `cryptsetup convert --type luks2 /dev/sdXZ`. That command will > > succeed, and luksDump will show PBKDF: pbkdf2 for both Keyslot 0 and > > > > 2. > > 3. Run cryptsetup open /dev/sdXY > > > > 4. Mount everything and arch-chroot into / > > > > 5. Run `mkinitcpio -P linux` > > > > 6. Run `grub-install --target=x86_64-efi --efi-directory=/efi > > --modules="luks2 part_gpt cryptodisk" --bootloader-id=`. > > > > > > Note: If `--modules="luks2 part_gpt cryptodisk"` is not appended to > > grub-install, then the `ls` results in step 9 (below) only lists > > (proc) and (hd0) - and/or cryptodisk: command not found. > > > > 6. Run grub-mkconfig -o /boot/grub/grub.cfg > > > > 7. Exit, umount and reboot. > > > > 8. Immediately following power on: you are greeted by the dreaded: > > error: disk 'lvmid/some-lengthy-UUID' not found. Entering rescue > > mode. That lengthy UUID is exact UUID of my `dm-2` which is my > > encrypted / LV. > > > > 9. At the `grub rescue>` prompt: type `ls`. There I see (proc) (hd0) > > and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where > > my encrypted / resides. > > > > 10. Still at `grub rescue>` type: `cryptomount (hd0,gpt7)` which then > > requires my passphrase. After correct passphrase entry, and hitting > > Enter only returns: > > > > > > `error: Could not parse digest 1.` > > Incredibly, if you repeat step 10 and intentionally enter an > > incorrect passphrase, you get the same: > > `error: Could not parse digest 1.` > > In fact, if you enter NO passphrase and hit Enter, you also get: > > `error: Could not parse digest 1.` > > Very frustrating indeed! > > Does anyone know why grub is failing this way, and does a workaround > > exist? > > Thank you for your time...suggestions welcome. > > If I remember correctly, you mentioned on IRC that you could > successfully use grub-git to cryptomount a luks1 /boot/grub directory, > then use the grub modules there to further cryptomount a luks2 partition. > > The problem sounded like an issue actually getting grub-install to > generate a grubx64.efi with proper, usable luks2 support. > > Am I right? > > --- > > Eli Schwartz > Arch Linux Bug Wrangler and Trusted User > > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/l
Re: Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results
On Fri, Aug 28, 2020 at 11:37:24AM -0400, Eli Schwartz wrote: > On 8/28/20 11:28 AM, HardenedArray via Grub-devel wrote: > > I run Arch Linux as an encrypted /, /boot and swap system. That > > encrypted /boot is nothing more than a folder under /, however two > > Keyslots are required to boot. > > > > If I understand the boot process correctly, LUKS Keyslot 1 is used by > > grub to unlock /boot, then control is handed off to the kernel which > > uses Keyslot 0 to unlock /. My passphrase, entered once, unlocks > > both. > > > > Grub can easily unlock /boot, assuming / is originally encrypted as a > > `type= luks1` partition. It seems, however, it is not possible for > > grub to unlock this same /boot if / is converted to `--type= luks2`. > > > > Is my assumption correct, and if so, what is preventing grub from > > this `type= luks2` /boot unlocking? > > > > I am running: grub-git 2.04.rc1.r19.g4e7b5bb3b-1 from the Arch (AUR). > > This package was last updated on 7 Feb 2020. See: > > https://aur.archlinux.org/packages/grub-git/ > > > > I originally encrypted the partition with: `cryptsetup -c > > aes-xts-plain64 -h sha512 -s 512 --use-random --type luks1 luksFormat > > /dev/sdXZ` > > > > Then I set up two LVs: swap (512M) and / (remaining partition space). > > That swap LV is assigned as `dm-1` and / is assigned as `dm-2`. dm-2 > > runs BTRFS, if that matters. Grub boots that system without issue. > > > > The process I used to test LUKS2 encrypted /boot support: > > > > 1. UEFI boot from any reasonably recent arch iso, and run: > > `cryptsetup convert --type luks2 /dev/sdXZ`. That command will > > succeed, and luksDump will show PBKDF: pbkdf2 for both Keyslot 0 and > > 1. > > > > 2. Run cryptsetup open /dev/sdXY > > > > 3. Mount everything and arch-chroot into / > > > > 4. Run `mkinitcpio -P linux` > > > > 5. Run `grub-install --target=x86_64-efi --efi-directory=/efi > > --modules="luks2 part_gpt cryptodisk" --bootloader-id=`. > > > > Note: If `--modules="luks2 part_gpt cryptodisk" ` is not appended to > > grub-install, then the `ls` results in step 9 (below) only lists > > (proc) and (hd0) - and/or cryptodisk: command not found. > > > > 6. Run grub-mkconfig -o /boot/grub/grub.cfg > > > > 7. Exit, umount and reboot. > > > > 8. Immediately following power on: you are greeted by the dreaded: > > error: disk 'lvmid/some-lengthy-UUID' not found. Entering rescue > > mode. That lengthy UUID is exact UUID of my `dm-2` which is my > > encrypted / LV. > > > > 9. At the `grub rescue>` prompt: type `ls`. There I see (proc) (hd0) > > and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where > > my encrypted / resides. > > > > 10. Still at `grub rescue>` type: `cryptomount (hd0,gpt7)` which then > > requires my passphrase. After correct passphrase entry, and hitting > > Enter only returns: > > > > `error: Could not parse digest 1.` > > > > Incredibly, if you repeat step 10 and intentionally enter an > > incorrect passphrase, you get the same: > > > > `error: Could not parse digest 1.` > > > > In fact, if you enter NO passphrase and hit Enter, you also get: > > > > `error: Could not parse digest 1.` > > > > Very frustrating indeed! > > > > Does anyone know why grub is failing this way, and does a workaround > > exist? > > > > Thank you for your time...suggestions welcome. > > If I remember correctly, you mentioned on IRC that you could > successfully use grub-git to cryptomount a luks1 /boot/grub directory, > then use the grub modules there to further cryptomount a luks2 partition. > > The problem sounded like an issue actually getting grub-install to > generate a grubx64.efi with proper, usable luks2 support. > > Am I right? If that's the case, then this is entirely expected right now. grub-install doesn't yet include the required modules automatically for LUKS2 support. There is ongoing work to enable this, first by recognizing LUKS2 devices at all [1,2]. But we're not there yet, and it's unlikely to happen for release 2.06. Until then, you'll have to manually add required GRUB modules for LUKS2, PBKDF2 and the gcry modules required for your configured cipher/hash combination. Patrick [1]: https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00235.html [2]: https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00050.html signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results
On 8/28/20 12:35 PM, HardenedArray via Grub-devel wrote: > Hi Eli, > > Unless I missed what I said in this very long, convoluted LUKS2 IRC > history, I do not recall telling you that I could cryptomount from a > --type luks1 partition, simply because I had never had a reason to do > so. 2020-08-17 03:27:30 PM eschwartz what I mean to say is, for testing purposes it's useful to narrow down where grub might be failing 2020-08-17 03:28:16 PM eschwartz so instead of re-encrypting / and /boot with luks2, try adding a new disk, encrypted with luks2, and see if it can be mounted 2020-08-17 03:28:53 PM eschwartz this lets you test, in isolation, whether grub can decrypt luks2 in general 2020-08-17 03:30:42 PM eschwartz if that works, then you can follow on to the next stage -- seeing if the minimal grubx64.efi (or BIOS core.img embedded in the MBR) can handle luks2 when unlocking /boot (which is where extended modules are located) 2020-08-18 02:11:55 PM h4rd3n3Deschwartz: following up from yesterday, if this a sufficient test from your POV? From a LUKS1 Arch encrypted /boot system, I can easily mount a Fedora btrfs LUKS2 encrypted / partition. The reverse boot and mount case is also true. Both OSes run grub and can be independently booted. My assumption was, here, that you performed the fedora mount using the grub command line. In order to test grub. Did you instead test this using the Linux initramfs command line? That would test the linux "cryptsetup" program, a useless test. > Again, grub boots my luks1 encrypted /boot system without issue, > meaning I enter my passphrase at the grub (correct /dev/sda7 UUID) > prompt (and NOT the `grub rescue>`) prompt and then boot continues > until I reach KDE's SDDM login. > > What I think I told you is: once I'm logged into KDE on my luks1 > encrypted /boot system, I can easily mount another luks2 encrypted / > on another partition, be that Fedora or some other OS. No > cryptomount command or `grub rescue> prompt involved. Only entering > the correct LUKS passphrase is required. > > Hope that helps... -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results
On 8/28/20 12:51 PM, Patrick Steinhardt wrote: > If that's the case, then this is entirely expected right now. > grub-install doesn't yet include the required modules automatically for > LUKS2 support. There is ongoing work to enable this, first by > recognizing LUKS2 devices at all [1,2]. But we're not there yet, and > it's unlikely to happen for release 2.06. That is what I'd postulated when discussing things with the OP. But I was having trouble providing clear guidance since I wasn't sure what the required modules actually are. > Until then, you'll have to manually add required GRUB modules for LUKS2, > PBKDF2 and the gcry modules required for your configured cipher/hash > combination. This sounds like useful guidance. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results
Eli, Sorry if you misunderstood how I decrypted a LUKS2 / from a booted LUKS1 encrypted /boot Arch system. No CLI, nor initramfs was involved. I merely booted my LUKS1 encrypted /boot, logged into SDDM, then used KDE's Dolphin to unlock another LUKS2 / partition. And, of course, grub can boot a non-encrypted /boot with an encrypted LUKS2 /. Following that LUKS2 boot, Dolphin can be used to unlock a LUKS1 /, but neither approach tests grub unlocking, as far as I know. Patrick, Thank you for your follow-up, and understood re: the ongoing development, and the likely v2.06 LUKS2 support miss. Also, noted on the additional modules you mentioned. As far as I can tell, the documentation concerning `grub-install --modules=xxx` is very sparse. If you know a decent resource, please link it. Cheers ‐‐‐ Original Message ‐‐‐ On Friday, August 28, 2020 4:51 PM, Patrick Steinhardt wrote: > On Fri, Aug 28, 2020 at 11:37:24AM -0400, Eli Schwartz wrote: > > > On 8/28/20 11:28 AM, HardenedArray via Grub-devel wrote: > > > > > I run Arch Linux as an encrypted /, /boot and swap system. That > > > encrypted /boot is nothing more than a folder under /, however two > > > Keyslots are required to boot. > > > If I understand the boot process correctly, LUKS Keyslot 1 is used by > > > grub to unlock /boot, then control is handed off to the kernel which > > > uses Keyslot 0 to unlock /. My passphrase, entered once, unlocks > > > both. > > > Grub can easily unlock /boot, assuming / is originally encrypted as a > > > `type= luks1` partition. It seems, however, it is not possible for > > > grub to unlock this same /boot if / is converted to `--type= luks2`. > > > Is my assumption correct, and if so, what is preventing grub from > > > this `type= luks2` /boot unlocking? > > > I am running: grub-git 2.04.rc1.r19.g4e7b5bb3b-1 from the Arch (AUR). > > > This package was last updated on 7 Feb 2020. See: > > > https://aur.archlinux.org/packages/grub-git/ > > > I originally encrypted the partition with: `cryptsetup -c aes-xts-plain64 > > > -h sha512 -s 512 --use-random --type luks1 luksFormat /dev/sdXZ` > > > Then I set up two LVs: swap (512M) and / (remaining partition space). > > > That swap LV is assigned as `dm-1` and / is assigned as `dm-2`. dm-2 > > > runs BTRFS, if that matters. Grub boots that system without issue. > > > The process I used to test LUKS2 encrypted /boot support: > > > > > > 1. UEFI boot from any reasonably recent arch iso, and run: > > > `cryptsetup convert --type luks2 /dev/sdXZ`. That command will > > > succeed, and luksDump will show PBKDF: pbkdf2 for both Keyslot 0 and > > > > > > 2. > > > 3. Run cryptsetup open /dev/sdXY > > > > > > 4. Mount everything and arch-chroot into / > > > > > > 5. Run `mkinitcpio -P linux` > > > > > > 6. Run `grub-install --target=x86_64-efi --efi-directory=/efi > > > --modules="luks2 part_gpt cryptodisk" --bootloader-id=`. > > > > > > > > > Note: If `--modules="luks2 part_gpt cryptodisk"` is not appended to > > > grub-install, then the `ls` results in step 9 (below) only lists > > > (proc) and (hd0) - and/or cryptodisk: command not found. > > > > > > 6. Run grub-mkconfig -o /boot/grub/grub.cfg > > > > > > 7. Exit, umount and reboot. > > > > > > 8. Immediately following power on: you are greeted by the dreaded: > > > error: disk 'lvmid/some-lengthy-UUID' not found. Entering rescue > > > mode. That lengthy UUID is exact UUID of my `dm-2` which is my > > > encrypted / LV. > > > > > > 9. At the `grub rescue>` prompt: type `ls`. There I see (proc) (hd0) > > > and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where > > > my encrypted / resides. > > > > > > 10. Still at `grub rescue>` type: `cryptomount (hd0,gpt7)` which then > > > requires my passphrase. After correct passphrase entry, and hitting > > > Enter only returns: > > > > > > > > > `error: Could not parse digest 1.` > > > Incredibly, if you repeat step 10 and intentionally enter an > > > incorrect passphrase, you get the same: > > > `error: Could not parse digest 1.` > > > In fact, if you enter NO passphrase and hit Enter, you also get: > > > `error: Could not parse digest 1.` > > > Very frustrating indeed! > > > Does anyone know why grub is failing this way, and does a workaround > > > exist? > > > Thank you for your time...suggestions welcome. > > > > If I remember correctly, you mentioned on IRC that you could > > successfully use grub-git to cryptomount a luks1 /boot/grub directory, > > then use the grub modules there to further cryptomount a luks2 partition. > > The problem sounded like an issue actually getting grub-install to > > generate a grubx64.efi with proper, usable luks2 support. > > Am I right? > > If that's the case, then this is entirely expected right now. > grub-install doesn't yet include the required modules automatically for > LUKS2 support. There is ongoing work to enable this, first by > recognizing
Re: Can grub-git be used to decrypt a LUKS2 encrypted partition? Testing Results
On Fri, 28 Aug 2020 15:28:41 + HardenedArray via Grub-devel wrote: > I run Arch Linux as an encrypted /, /boot and swap system. That > encrypted /boot is nothing more than a folder under /, however two > Keyslots are required to boot. > > If I understand the boot process correctly, LUKS Keyslot 1 is used by > grub to unlock /boot, then control is handed off to the kernel which > uses Keyslot 0 to unlock /. My passphrase, entered once, unlocks both. This is confusing. Do you have a two LUKS devices, one for / and one for /boot? If so, you only need to access LUKS Keyslot 0 on either device. > Grub can easily unlock /boot, assuming / is originally encrypted as a > `type= luks1` partition. It seems, however, it is not possible for > grub to unlock this same /boot if / is converted to `--type= luks2`. > > Is my assumption correct, and if so, what is preventing grub from > this `type= luks2` /boot unlocking? Please post the output of `cryptsetup luksDump --debug-json ' (for both /boot and / if using two LUKS devices). > I am running: grub-git 2.04.rc1.r19.g4e7b5bb3b-1 from the Arch (AUR). > This package was last updated on 7 Feb 2020. See: > https://aur.archlinux.org/packages/grub-git/ > > I originally encrypted the partition with: `cryptsetup -c > aes-xts-plain64 -h sha512 -s 512 --use-random --type luks1 luksFormat > /dev/sdXZ` > > Then I set up two LVs: swap (512M) and / (remaining partition space). > That swap LV is assigned as `dm-1` and / is assigned as `dm-2`. dm-2 > runs BTRFS, if that matters. Grub boots that system without issue. > > The process I used to test LUKS2 encrypted /boot support: > > 1. UEFI boot from any reasonably recent arch iso, and run: > `cryptsetup convert --type luks2 /dev/sdXZ`. That command will > succeed, and luksDump will show PBKDF: pbkdf2 for both Keyslot 0 and > 1. > > 2. Run cryptsetup open /dev/sdXY > > 3. Mount everything and arch-chroot into / > > 4. Run `mkinitcpio -P linux` > > 5. Run `grub-install --target=x86_64-efi --efi-directory=/efi > --modules="luks2 part_gpt cryptodisk" --bootloader-id=`. Is /efi on the encrypted /boot partition? If so how are you going to get the BIOS to boot it? > Note: If `--modules="luks2 part_gpt cryptodisk" ` is not appended to > grub-install, then the `ls` results in step 9 (below) only lists > (proc) and (hd0) - and/or cryptodisk: command not found. > > 6. Run grub-mkconfig -o /boot/grub/grub.cfg > > 7. Exit, umount and reboot. > > 8. Immediately following power on: you are greeted by the dreaded: > error: disk 'lvmid/some-lengthy-UUID' not found. Entering rescue > mode. That lengthy UUID is exact UUID of my `dm-2` which is my > encrypted / LV. > > 9. At the `grub rescue>` prompt: type `ls`. There I see (proc) (hd0) > and (hd0,gpt1)...(hd0,gpt7) where gpt7 is my last partition and where > my encrypted / resides. > > 10. Still at `grub rescue>` type: `cryptomount (hd0,gpt7)` which then > requires my passphrase. After correct passphrase entry, and hitting > Enter only returns: > > `error: Could not parse digest 1.` > > Incredibly, if you repeat step 10 and intentionally enter an > incorrect passphrase, you get the same: > > `error: Could not parse digest 1.` > > In fact, if you enter NO passphrase and hit Enter, you also get: > > `error: Could not parse digest 1.` It looks like you're hitting the bug in master which is triggered by attempting to cryptomount a LUKS device using a keyslot that is not the first one. Could you post the output of `cryptsetup luksDump --debug-json '? That bug is fixed by the patch on this mailing list with title "[PATCH v2 3/9] luks2: Fix use of incorrect index and some error messages". > Very frustrating indeed! > > Does anyone know why grub is failing this way, and does a workaround > exist? > > Thank you for your time...suggestions welcome. Glenn ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] tests: F2FS test should use MOUNTDEVICE like other tests.
LODEVICES is not an array variable and should not be accessed as such. This
allows the f2fs test to pass as it was failing because a device name had a
space prepended to the path.
Signed-off-by: Glenn Washburn
---
tests/util/grub-fs-tester.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/util/grub-fs-tester.in b/tests/util/grub-fs-tester.in
index bc14a05ca..bfc425e1f 100644
--- a/tests/util/grub-fs-tester.in
+++ b/tests/util/grub-fs-tester.in
@@ -796,7 +796,7 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE"
1); do
MOUNTFS=ext2
"mkfs.ext2" -L "$FSLABEL" -q "${MOUNTDEVICE}" ;;
xf2fs)
- "mkfs.f2fs" -l "$FSLABEL" -q "${LODEVICES[0]}" ;;
+ "mkfs.f2fs" -l "$FSLABEL" -q "${MOUNTDEVICE}" ;;
xnilfs2)
"mkfs.nilfs2" -L "$FSLABEL" -b $BLKSIZE -q
"${MOUNTDEVICE}" ;;
xext2_old)
--
2.27.0
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
