All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Support for plain dm-crypt and detached LUKS header
       [not found] <4gDHpwpSsh5XJ-vHQwcowPqEhqLjNLizrokGB4Tb3SlFV--IOCSIYmogammiHB3CmC1AL9Qa1GLO_05eZeTZoHEKBbyoDDUCk3ImfTGDy98=@protonmail.com>
@ 2017-04-09  6:29 ` Andrei Borzenkov
  2017-04-10 10:46   ` Mat628
  0 siblings, 1 reply; 4+ messages in thread
From: Andrei Borzenkov @ 2017-04-09  6:29 UTC (permalink / raw)
  To: Mat628, grub, help-grub, The development of GNU GRUB

Thank you for the patch. Unfortunately it does not solve fundamental
problem - grub-install is expected to auto-detect everything that is
required to access /boot/grub (it violates it now for encrypted /boot,
but I plan to submit patch after release to decouple it from
/etc/default/grub). So any solution that integrates plain
dm-crypt/detached header into grub-install needs to work without user
intervention and provides some means to auto-detect this.

Although we already have some options that cannot be autodetected (e.g.
keys). So may be this can be relaxed.

But at the very least it needs to check whether LUKS device has detached
header and abort by default if it has, otherwise we cannot even find
device to open at boot time. It also needs code to detect underlying
block device and again abort if partition map does not support PTUUID
(i.e. is not MSDOS or GPT), as this is the only means to find it.

In generally, if grub-install completed without error grub should boot -
otherwise we have a bug.

08.04.2017 19:16, Mat628 пишет:
> Hi, I'd like to first say thanks to the additions you made to cryptomount. I came across your patches 2-3 months ago when I was looking to do FDE including /boot for LVM on LUKS. I created a few patches outlined with their features below. I would have messaged sooner but I didn't know about these posts on grub-help until after finding the link from your github. After also coming across the problem of having no way to reliably predict what a device (hd0,msdos1) will map to, I ended up creating an add-on command, that uses the partition UUID/GUID, to search (--pt-uuid) and an accompanying module search.pt_uuid. These two commands mirror the search --fs-uuid and search.fs_uuid where given a uuid it will return the device. When given a disk/partition UUID/GUID that corresponds to a disk that is either a biosdisk or efidisk, or a partition with a partmap name of either "msdos" or "gpt" on one of the previous disks it will return that device.
> 
> Patch 1 stops search from printing same device twice if called multiple times.
> 
> Patch 2 allows this--->Added module search_pt_uuid. When given a disk/part UUID/GUID it will return the associated device.
> On a biosdisk/mbr it will return the same value for the device (hd0)/(hd0,msdos1) as lsblk -o PARTUUID returns. This should be the same as the NT disk signature located at mbr.code[440] for 4 bytes in little endian format plus the partition number appended if applicable xxxxxxxx-yy. On an efidisk/gpt it will return the same value for the device (hd0)/(hd0,gpt1) as lsblk -o PARTUUID returns. This will be the disk/partition UUID/GUID.
> 
> An example of using this command inside load.cfg or directly on the grub command line. This example is for a detached header LUKS volume on (hdX,msdosY) which corresponds to a partuuid of 12345678-01 with the header file stored on a plain text partition either on the same device or a different one with a fs_uuid=5432-7654.
> 
> From your site this would look like
> 
> cryptomount -H (hd0,1)/header hd1,1
> 
> But with my patch it would be.
> 
> search.fs_uuid 5432-7654 header_file_device ----Line for setting (hd0,1)
> search.pt_uuid 12345678-01 cryptodevice ----Line for setting (hd1,1)
> cryptomount ($cryptodevice) --header=($header_file_device)/header.bin
> 
> Or if the header file is in a separate encrypted LUKS volume. LUKS volume UUID is 12345678-1234-1234-1234-1234567890ab. When the LUKS volume is open the mounted fs_uuid is 11112222-3333-4444-5555-123456654321 for a ext4 partition.
> 
> cryptomount -u 12345678-1234-1234-1234-1234567890ab ----Line for opening the LUKS volume with the header file in it.
> search.fs_uuid 11112222-3333-4444-5555-123456654321 header_file_device ----Line for setting (hd0,1)
> search.pt_uuid 12345678-01 cryptodevice ----Line for setting (hd1,1)
> cryptomount ($cryptodevice) --header=($header_file_device)/header.bin ----Line for opening LUKS volume with /boot
> 
> Patch 3 allows this---->Inclusion of altered "load.cfg" to grub-install/mkconfig.
> mattle_opts (More Advanced Than Traditional LUKS Encryption Options). Added mattle_opts.cfg file which allows the user to customize load.cfg to allow for extra options for cryptomount. mattle_opts.cfg is located in user-defined/etc/ folder. Same folder as crypttab and fstab. Only affects cryptomount options in load.cfg and only if GRUB_ENABLE_CRYPTODISK_MATTLE_OPTS=y is set in grub.cfg. If not set then normal 'cryptomount -u $uuid' is printed to load.cfg. I altered grub-install and grub-mkconfig to allow it to have essentially an alternate load.cfg (mattle_opts.cfg) to be easily editted by the user prior to running grub-install to allow grub-install to then read from this file and then fprint this alternate files contents into load.cfg to allow your alternate cryptomount commands to be run during boot up. This does not interfere with any of grub-install's other actions with load.cfg it merely replaces the normal 'cryptomount -u $uuid' that is printed from grub-install into load.cfg. This makes it so you don't have to do grub-mkimage and the associated commands. Also added command line options for grub-install/mkconfig to allow an alternate mattle_opts.cfg to allow the user to quickly install grub to another device without having to modify the default mattle_opts.cfg.
> 
> Patch 4 allows this----> grub-install and grub-mkconfig magic for /boot on a detached header LUKS volume
> Added grub-install magic for a crypto-device that is on a disk with either an msdos or gpt partition table and either on a biosdisk or efidisk. Grub-install magic works with grub-mkconfig for booting a detached header LUKS volume when used with --crypto-device and --crypto-header. By reading the actual header file that corresponds to that partitcular LUKS volume this allows grub-install/mkconfig to have the proper modules loaded by grub. The grub-install command for /boot located on /dev/sda1 where /dev/sda1 is a detached header LUKS volume and the header is located on the root / directory and we are installing to /dev/sda.
> 
> grub-install --boot-directory=/boot --crypto-device=/dev/sda1 --crypto-header=/header.bin /dev/sda
> grub-mkconfig -o /boot/grub/grub.cfg
> 
> For above patch 4 grub-install needs to be run prior to grub-mkconfig so the proper *.cfg files are created and configured to allow cryptodisk.c and luk.c to create a cryptodisk based off the stated crypto-device.
> 
> A few notes: mattle_opts.cfg is read only by grub-install/mkconfig and must be edited outside of grub using nano/text editor.
> The command line options for grub-install do not alter mattle_opts.cfg so if installing to two different devices i.e a usb stick and a hard drive, mattle_opts.cfg may need to be edited. i.e. depending on where header/key files are stored.
> The easiest setup seems to be /boot/grub on the rootfs and only have the applicable header/key files on the usb either in plain text or in an encrypted partition, and have the boot.img and core.img installed to the usb as well.
> The changes to luks.c should only be in effect for grub utils and not in effect during booting.
> 
> I've also included your first 3 LUKS patches as they would apply after my patches. These patches are based off of grub-2.02-rc2. I tested these to work on x64 version of Ubuntu 16.04 LTS running bios. For the efi with gpt it was tested on a virtual machine x64 Ubuntu 16.04 LTS.
> 
> Best regards,
> Matt
> 
> 
> 
> _______________________________________________
> Help-grub mailing list
> Help-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-grub
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Support for plain dm-crypt and detached LUKS header
  2017-04-09  6:29 ` Support for plain dm-crypt and detached LUKS header Andrei Borzenkov
@ 2017-04-10 10:46   ` Mat628
       [not found]     ` <1bc0f195bbb6b33a9491fedb95e6148e@xenhideout.nl>
  0 siblings, 1 reply; 4+ messages in thread
From: Mat628 @ 2017-04-10 10:46 UTC (permalink / raw)
  To: Andrei Borzenkov; +Cc: grub, help-grub, The development of GNU GRUB


[-- Attachment #1.1: Type: text/plain, Size: 12325 bytes --]

Thank you for the quick response. I just wanted to clarify a few things from your response.

>But at the very least it needs to check whether LUKS device has detached header and abort by default if it has, otherwise we cannot even find device to open at boot time.
grub-2.02rc does abort if a LUKS header is not detected, it may not say it directly but it does state that "grub-install: error: disk `cryptouuid/142d0d6fbcd348b9a25bd1bf1c3b681c' not found. " (for an ext4 on LUKS device) and aborts the installation. This is because grub-install can not find the connection between the proposed /boot/grub install directory and the root device it is on. Or if it LVM on LUKS it will state "grub-install: error: disk `lvmid/3we4r5-vdad-12s3-ds3r-asde-2233-dfea4t/2763tf-324e-NhdY-37d6-3d3r-1234-vaef34' not found." My patched version will state the same errors if none of my add command line options are used i.e. --crypto-device & --crypto-header. Do you find that type of failure to be sufficient?
>It also needs code to detect underlying block device and again abort if partition map does not support PTUUID (i.e. is not MSDOS or GPT), as this is the only means to find it.
The patches in their previously posted form do not explicitly fail due to those reasons but I do have checks in grub-install.c that make sure that if the device that is being stated as the --crypto-device does not have either an MSDOS or GPT type partition table then it will abort the installation in the same manner as stated above. The following patch for grub-install.c/luks.c does have additional error checking and will explicitly fail prior to finishing 'if (crypto_device && crypto_header)' in grub-install. Is that the type of checking and failure you were looking for?

I understand that grub-install is expected to auto-detect everything that is required to access /boot/grub but you also said that it should fail if it detects a LUKS device with a detached header by default. Which it does and I understand the reasons for that. But if it is to fail by default then are you saying it is okay for some user intervention i.e. having the user type 'grub-install --crypto-device=/dev/sda1 --crypto-header=/usb_drive/sda1_header.bin /dev/sdb'. Which is what would be required of the user to use my patches if they wanted to install /boot/grub on the rootfs and have boot.img, core.img and presumably (sda1_header.bin) on /dev/sdb(1) . Along with having them properly configure mattle_opts.cfg which I showed easy examples on how to do that in the patch 3 info. I left mattle_opts.cfg to be manually configured by the user for the purpose of giving them greater freedom in choosing which devices and how many they wanted to use to retrieve keyfiles and detached headers. If the user doesn't change devices for which the header or keyfiles are stored then no modification would be needed to mattle_opts.cfg for repeated grub-install/mkconfig attempts. Given that having a detached header or plain dm-crypt for FDE including /boot is more of an advanced setup do you think it would be too much to ask of the users to do what I am saying is required at this time? I mentioned plain dm-crypt because I have another patch that works with these patches and with just as much user intervention as is required for detached headers, it also allows for grub-install/mkconfig for plain dm-crypt devices. The plain dm-crypt patch is another reason I left mattle_opts.cfg to be manually configured because its easier for the user to type that information in once into a file instead of repeatedly on the command line.
Another note I just wanted to make clear is with the new patch neither patch 3 nor patch 4 will work if the user has not enabled GRUB_ENABLED_CRYPTODISK_MATTLE_OPTS=y in 'etc/default/grub. With that not enabled grub-install/mkconfig will act the same way as if patches 3 and 4 were not applied. Previously only patch 3 would not work if it was not enabled. I did that for the reason that these are more advanced options that do require a little more user intervention and that way someone wouldn't be able to accidentally install grub to or for a LUKS device with a detached header and then subsequently have a non-bootable computer.

Did you get a chance to try to use the patches as they are?

Do you think that the search_pt_uuid module is okay in its format?
best regards,

matt
-------- Original Message --------
Subject: Re: Support for plain dm-crypt and detached LUKS header
Local Time: April 9, 2017 6:29 AM
UTC Time: April 9, 2017 6:29 AM
From: arvidjaar@gmail.com
To: Mat628 <mat628@protonmail.com>, grub@jelmail.com <grub@jelmail.com>, help-grub@gnu.org <help-grub@gnu.org>, The development of GNU GRUB <grub-devel@gnu.org>

Thank you for the patch. Unfortunately it does not solve fundamental
problem - grub-install is expected to auto-detect everything that is
required to access /boot/grub (it violates it now for encrypted /boot,
but I plan to submit patch after release to decouple it from
/etc/default/grub). So any solution that integrates plain
dm-crypt/detached header into grub-install needs to work without user
intervention and provides some means to auto-detect this.

Although we already have some options that cannot be autodetected (e.g.
keys). So may be this can be relaxed.

But at the very least it needs to check whether LUKS device has detached
header and abort by default if it has, otherwise we cannot even find
device to open at boot time. It also needs code to detect underlying
block device and again abort if partition map does not support PTUUID
(i.e. is not MSDOS or GPT), as this is the only means to find it.

In generally, if grub-install completed without error grub should boot -
otherwise we have a bug.

08.04.2017 19:16, Mat628 пишет:
> Hi, I'd like to first say thanks to the additions you made to cryptomount. I came across your patches 2-3 months ago when I was looking to do FDE including /boot for LVM on LUKS. I created a few patches outlined with their features below. I would have messaged sooner but I didn't know about these posts on grub-help until after finding the link from your github. After also coming across the problem of having no way to reliably predict what a device (hd0,msdos1) will map to, I ended up creating an add-on command, that uses the partition UUID/GUID, to search (--pt-uuid) and an accompanying module search.pt_uuid. These two commands mirror the search --fs-uuid and search.fs_uuid where given a uuid it will return the device. When given a disk/partition UUID/GUID that corresponds to a disk that is either a biosdisk or efidisk, or a partition with a partmap name of either "msdos" or "gpt" on one of the previous disks it will return that device.
>
> Patch 1 stops search from printing same device twice if called multiple times.
>
> Patch 2 allows this--->Added module search_pt_uuid. When given a disk/part UUID/GUID it will return the associated device.
> On a biosdisk/mbr it will return the same value for the device (hd0)/(hd0,msdos1) as lsblk -o PARTUUID returns. This should be the same as the NT disk signature located at mbr.code[440] for 4 bytes in little endian format plus the partition number appended if applicable xxxxxxxx-yy. On an efidisk/gpt it will return the same value for the device (hd0)/(hd0,gpt1) as lsblk -o PARTUUID returns. This will be the disk/partition UUID/GUID.
>
> An example of using this command inside load.cfg or directly on the grub command line. This example is for a detached header LUKS volume on (hdX,msdosY) which corresponds to a partuuid of 12345678-01 with the header file stored on a plain text partition either on the same device or a different one with a fs_uuid=5432-7654.
>
> From your site this would look like
>
> cryptomount -H (hd0,1)/header hd1,1
>
> But with my patch it would be.
>
> search.fs_uuid 5432-7654 header_file_device ----Line for setting (hd0,1)
> search.pt_uuid 12345678-01 cryptodevice ----Line for setting (hd1,1)
> cryptomount ($cryptodevice) --header=($header_file_device)/header.bin
>
> Or if the header file is in a separate encrypted LUKS volume. LUKS volume UUID is 12345678-1234-1234-1234-1234567890ab. When the LUKS volume is open the mounted fs_uuid is 11112222-3333-4444-5555-123456654321 for a ext4 partition.
>
> cryptomount -u 12345678-1234-1234-1234-1234567890ab ----Line for opening the LUKS volume with the header file in it.
> search.fs_uuid 11112222-3333-4444-5555-123456654321 header_file_device ----Line for setting (hd0,1)
> search.pt_uuid 12345678-01 cryptodevice ----Line for setting (hd1,1)
> cryptomount ($cryptodevice) --header=($header_file_device)/header.bin ----Line for opening LUKS volume with /boot
>
> Patch 3 allows this---->Inclusion of altered "load.cfg" to grub-install/mkconfig.
> mattle_opts (More Advanced Than Traditional LUKS Encryption Options). Added mattle_opts.cfg file which allows the user to customize load.cfg to allow for extra options for cryptomount. mattle_opts.cfg is located in user-defined/etc/ folder. Same folder as crypttab and fstab. Only affects cryptomount options in load.cfg and only if GRUB_ENABLE_CRYPTODISK_MATTLE_OPTS=y is set in grub.cfg. If not set then normal 'cryptomount -u $uuid' is printed to load.cfg. I altered grub-install and grub-mkconfig to allow it to have essentially an alternate load.cfg (mattle_opts.cfg) to be easily editted by the user prior to running grub-install to allow grub-install to then read from this file and then fprint this alternate files contents into load.cfg to allow your alternate cryptomount commands to be run during boot up. This does not interfere with any of grub-install's other actions with load.cfg it merely replaces the normal 'cryptomount -u $uuid' that is printed from grub-install into load.cfg. This makes it so you don't have to do grub-mkimage and the associated commands. Also added command line options for grub-install/mkconfig to allow an alternate mattle_opts.cfg to allow the user to quickly install grub to another device without having to modify the default mattle_opts.cfg.
>
> Patch 4 allows this----> grub-install and grub-mkconfig magic for /boot on a detached header LUKS volume
> Added grub-install magic for a crypto-device that is on a disk with either an msdos or gpt partition table and either on a biosdisk or efidisk. Grub-install magic works with grub-mkconfig for booting a detached header LUKS volume when used with --crypto-device and --crypto-header. By reading the actual header file that corresponds to that partitcular LUKS volume this allows grub-install/mkconfig to have the proper modules loaded by grub. The grub-install command for /boot located on /dev/sda1 where /dev/sda1 is a detached header LUKS volume and the header is located on the root / directory and we are installing to /dev/sda.
>
> grub-install --boot-directory=/boot --crypto-device=/dev/sda1 --crypto-header=/header.bin /dev/sda
> grub-mkconfig -o /boot/grub/grub.cfg
>
> For above patch 4 grub-install needs to be run prior to grub-mkconfig so the proper *.cfg files are created and configured to allow cryptodisk.c and luk.c to create a cryptodisk based off the stated crypto-device.
>
> A few notes: mattle_opts.cfg is read only by grub-install/mkconfig and must be edited outside of grub using nano/text editor.
> The command line options for grub-install do not alter mattle_opts.cfg so if installing to two different devices i.e a usb stick and a hard drive, mattle_opts.cfg may need to be edited. i.e. depending on where header/key files are stored.
> The easiest setup seems to be /boot/grub on the rootfs and only have the applicable header/key files on the usb either in plain text or in an encrypted partition, and have the boot.img and core.img installed to the usb as well.
> The changes to luks.c should only be in effect for grub utils and not in effect during booting.
>
> I've also included your first 3 LUKS patches as they would apply after my patches. These patches are based off of grub-2.02-rc2. I tested these to work on x64 version of Ubuntu 16.04 LTS running bios. For the efi with gpt it was tested on a virtual machine x64 Ubuntu 16.04 LTS.
>
> Best regards,
> Matt
>
>
>
> _______________________________________________
> Help-grub mailing list
> Help-grub@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-grub
>

[-- Attachment #1.2: Type: text/html, Size: 14966 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Error-checking-in-grub-install-luks.c.patch --]
[-- Type: text/x-patch; name="0001-Error-checking-in-grub-install-luks.c.patch", Size: 11254 bytes --]

From 080525e01fca3abab097b440cf5c8cb3591379f5 Mon Sep 17 00:00:00 2001
From: matt <mat628@protonmail.com>
Date: Mon, 10 Apr 2017 05:24:12 -0400
Subject: [PATCH] Error checking in grub-install/luks.c

---
 grub-core/disk/luks.c |  24 +++++++---
 util/grub-install.c   | 118 +++++++++++++++++++++++++++++---------------------
 2 files changed, 88 insertions(+), 54 deletions(-)

diff --git a/grub-core/disk/luks.c b/grub-core/disk/luks.c
index c776261..00e6ef9 100644
--- a/grub-core/disk/luks.c
+++ b/grub-core/disk/luks.c
@@ -174,7 +174,7 @@ configure_ciphers (grub_disk_t disk, const char *check_uuid,
       the disk. It is only used to make grub-install think this
       is a cryptodisk. Since it really is but without a header
       grub-install does not know this.*/
-      grub_uint8_t num[6] = {'L','U','K','S',0xba,0xbe};
+      /*grub_uint8_t num[6] = {'L','U','K','S',0xba,0xbe};
       grub_memcpy (header.magic, num, sizeof(num));
       header.version = 0x0100;
       grub_strcpy (header.cipherName, "aes");
@@ -187,7 +187,7 @@ configure_ciphers (grub_disk_t disk, const char *check_uuid,
       grub_uint64_t alter_mkDigestSalt[4] = {0x00,0x00,0x00,0x00};
       grub_memcpy (header.mkDigestSalt,alter_mkDigestSalt, sizeof(alter_mkDigestSalt));
       header.mkDigestIterations = 0x0020;
-      grub_strcpy (header.uuid, "01234567-1234-1234-1234-0123456789ab");
+      grub_strcpy (header.uuid, "01234567-1234-1234-1234-0123456789ab");*/
 
       /*This is for reading a header file in from grub-install for a detached header cryptodisk*/
       static FILE *fpcrypto_header_f;         /*file pointer to be used as the local program name for crypto device ptuuid */
@@ -214,15 +214,29 @@ configure_ciphers (grub_disk_t disk, const char *check_uuid,
           if (header_file_name[0] != '\0') /*In case the file is opened but empty. If empty then use above dummy header. */
             {
               fpcrypto_detached_header_f = fopen (header_file_name, "r");
-              if (fread (&header, 1, sizeof (header), fpcrypto_detached_header_f) != sizeof (header))
-                err = GRUB_ERR_READ_ERROR;
+              if (fpcrypto_detached_header_f)
+                {
+                  if (fread (&header, 1, sizeof (header), fpcrypto_detached_header_f) != sizeof (header))
+                    err = GRUB_ERR_READ_ERROR;
+                  /*Test for LUKS magic in detached header*/
+                  if (grub_memcmp (header.magic, LUKS_MAGIC, sizeof (header.magic)))
+                    {
+                      grub_error (GRUB_ERR_BAD_ARGUMENT, "File '%s' is not a valid LUKS device detached header", header_file_name);
+                      return NULL;
+                    }
+                }
+              else
+                {
+                  grub_error (GRUB_ERR_FILE_NOT_FOUND, "Can't find detached header file '%s'", header_file_name);
+                      return NULL;
+                }
               fclose (fpcrypto_detached_header_f);
             }
         }
       fclose (fpcrypto_header_f);
       if (crypto_header_name)
         grub_free (crypto_header_name);
-    }  
+    }
 #endif
 
 
diff --git a/util/grub-install.c b/util/grub-install.c
index 4e8803e..e841e32 100644
--- a/util/grub-install.c
+++ b/util/grub-install.c
@@ -326,8 +326,8 @@ static struct argp_option options[] = {
   {"mattle-opts-file", OPTION_MATTLE_OPTS_FILE, N_("FILE"), 0,
    N_("use FILE instead of using %smattle_opts.cfg "), 2},
   {"crypto-device", OPTION_CRYPTO_DEVICE, N_("DEVICE"), 0, N_("DEVICE is the LUKS crypto "
-      "volume with a detached header that the root filesystem is on. i.e."
-      " LUKS volume is on /dev/sda1 -> /dev/mapper/luks-volume and /boot may be on that device. "
+      "device with a detached header that the root filesystem is on. i.e."
+      " LUKS device is on /dev/sda1 -> /dev/mapper/luks-device and /boot may be on that device. "
       "Usage --crypto-device=/dev/sdXY"), 2},
   {"crypto-header", OPTION_CRYPTO_HEADER, N_("FILE"), 0, N_("FILE is the detached LUKS header file for --crypto-device=DEVICE."
       " A copy of FILE needs to be stored on a different device and must be accessible in order to boot the DEVICE."), 2},
@@ -1209,8 +1209,8 @@ main (int argc, char *argv[])
     }
 
   /*Here is the start to adding code for ability to do grub-install on a detached header
-  LUKS volume i.e --boot-directory=/boot and /boot resides on detached header 
-  LUKS volume. This is placed outside the if (crypto_device) to clear file from
+  LUKS device i.e --boot-directory=/boot and /boot resides on detached header 
+  LUKS device. This is placed outside the if (crypto_device) to clear file from
   seperate grub-install calls. If placed inside then from each call crypto_ptuuid file will 
   retain the info and luks.c will access it even if --crypto-device is not called.*/
   static FILE *fpcrypto_ptuuid_f;         /*file pointer to be used as the local program name for crypto device uuid*/
@@ -1218,53 +1218,73 @@ main (int argc, char *argv[])
   crypto_ptuuid_name = grub_util_path_concat (2, GRUB_SYSCONFDIR, "crypto_ptuuid.cfg");
   fpcrypto_ptuuid_f = grub_util_fopen (crypto_ptuuid_name, "wb");
 
-  if (crypto_device)
+  if (crypto_device && crypto_header)
     {
-      grub_device_t crypto_dev = NULL;
-      char *crypto_grub_devname;
-      crypto_grub_devname = grub_util_get_grub_dev (crypto_device);
-      if (crypto_grub_devname)
-        {
-          char *partuuid = 0;
-          crypto_dev = grub_device_open (crypto_grub_devname);
-          if (crypto_dev && crypto_dev->disk)
-            {
-              grub_disk_t crypto_disk = crypto_dev->disk;
-              grub_partition_t crypto_p = crypto_disk->partition;
-              if (crypto_disk->partition)
-                {
-                  /*This means that it wont find devices like /dev/sdX only /dev/sdXY
-                  And only if /dev/sdXY is an msdos or gpt type partition*/
-                  if (crypto_p && (grub_strcmp (crypto_p->partmap->name, "msdos") == 0 || grub_strcmp (crypto_p->partmap->name, "gpt") == 0 ))
-                    {
-                      if (crypto_disk->partition->number + 1)
-                        {
-                          partuuid = grub_strdup (crypto_p->partuuid);
-                          if (partuuid)
-                            {
-                              fprintf (fpcrypto_ptuuid_f, "%s\n%s", partuuid, crypto_grub_devname);
-                              static FILE *fpcrypto_header_f;         /*file pointer to be used as the local program name for crypto device uuid*/
-                              static char *crypto_header_name;  /*absolute path for crypto_ptuuid file*/
-                              crypto_header_name = grub_util_path_concat (2, GRUB_SYSCONFDIR, "crypto_header.cfg");
-                              fpcrypto_header_f = grub_util_fopen (crypto_header_name, "wb");
-                              if (crypto_header)
-                                {
-                                  fprintf (fpcrypto_header_f, "%s\n", crypto_header);
-                                }
-
-                              fclose (fpcrypto_header_f);  /*closing file*/
-                              free (crypto_header_name);   /*freeing crypto_ptuuid_name*/
-                            }
-                          grub_free (partuuid);
-                        }
-                    }
-                }
-            }
-        }
-      grub_free (crypto_grub_devname);     
-      if (crypto_dev)
-        grub_device_close (crypto_dev);
+    if (config.is_cryptodisk_enabled_mattle_opts)
+      {
+        grub_device_t crypto_dev = NULL;
+        char *crypto_grub_devname;
+        crypto_grub_devname = grub_util_get_grub_dev (crypto_device);
+        grub_printf ("grub_devname is %s\n", crypto_grub_devname);
+        if (crypto_grub_devname)
+          {
+            char *partuuid = 0;
+            crypto_dev = grub_device_open (crypto_grub_devname);
+            if (crypto_dev && crypto_dev->disk)
+              {
+                grub_disk_t crypto_disk = crypto_dev->disk;
+                if (crypto_disk->partition)
+                  {
+                    grub_partition_t crypto_p = crypto_disk->partition;
+                    /*This means that it wont find devices like /dev/sdX only /dev/sdXY
+                    And only if /dev/sdXY is an msdos or gpt type partition*/
+                    if (crypto_p && (grub_strcmp (crypto_p->partmap->name, "msdos") == 0 || grub_strcmp (crypto_p->partmap->name, "gpt") == 0 ))
+                      {
+                        if (crypto_disk->partition->number + 1)
+                          {
+                            partuuid = grub_strdup (crypto_p->partuuid);
+                            if (partuuid)
+                              {
+                                fprintf (fpcrypto_ptuuid_f, "%s\n%s", partuuid, crypto_grub_devname);
+                                static FILE *fpcrypto_header_f;         /*file pointer to be used as the local program name for crypto device uuid*/
+                                static char *crypto_header_name;  /*absolute path for crypto_ptuuid file*/
+                                crypto_header_name = grub_util_path_concat (2, GRUB_SYSCONFDIR, "crypto_header.cfg");
+                                fpcrypto_header_f = grub_util_fopen (crypto_header_name, "wb");
+                                fprintf (fpcrypto_header_f, "%s\n", crypto_header);
+                                fclose (fpcrypto_header_f);  /*closing file*/
+                                free (crypto_header_name);   /*freeing crypto_ptuuid_name*/
+                              }
+                            free (partuuid);
+                          }
+                      }
+                    else
+                      { 
+                        grub_util_error (_("Partition map type is '%s'. Partition map type for disk %s must be either 'MSDOS' or 'GPT'"), crypto_p->partmap->name, crypto_disk->name);
+                      }
+                  }
+                else
+                  {
+                    grub_util_error (_("%s is not a partition. --crypto-device must be used with either an 'MSDOS' or 'GPT' type partition"), crypto_device);
+                  }           
+              }
+          }
+        else
+          {
+        grub_util_error (_("Can't open %s. Check to make sure %s is a valid device"), crypto_device, crypto_device);
+          }
+        free (crypto_grub_devname);     
+        if (crypto_dev)
+          grub_device_close (crypto_dev);
+      }
+    else
+      {
+        grub_util_error (_("Attempt to use detached header for LUKS device without mattle_opts enabled. "
+		       "Set `%s' in file `%s'"), "GRUB_ENABLE_CRYPTODISK_MATTLE_OPTS=y",
+		     grub_util_get_config_filename ());
+      }
     }
+  else if ((crypto_device && !crypto_header) || (!crypto_device && crypto_header))
+    grub_util_error (_("Must use --crypto-header with --crypto-device to install grub to a LUKS device with detached header"));
 
   fclose (fpcrypto_ptuuid_f);  /*closing file*/
   free (crypto_ptuuid_name);   /*freeing crypto_ptuuid_name*/
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: Support for plain dm-crypt and detached LUKS header
       [not found]     ` <1bc0f195bbb6b33a9491fedb95e6148e@xenhideout.nl>
@ 2017-04-11  5:05       ` Mat628
  2017-04-11  5:23       ` Mat628
  1 sibling, 0 replies; 4+ messages in thread
From: Mat628 @ 2017-04-11  5:05 UTC (permalink / raw)
  To: Xen; +Cc: help-grub, The development of GNU GRUB

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

>I would personally assume that something could be done in the dedicated /etc/grub.d/ directories that would allow grub-mkconfig to function as required without changing anything to it?

Xen, that is probably possible, but I chose to modify grub-mkconfig_lib.in because that is where the original code to mount a cryptodisk is echoed to grub.cfg.

Unmodified grub-2.02-rc2 grub-mkconfig_lib.in

prepare_grub_to_access_device ()
{
.
.
.
if [ x$GRUB_ENABLE_CRYPTODISK = xy ]; then
for uuid in `"${grub_probe}" --device $@ --target=cryptodisk_uuid`; do
echo "cryptomount -u $uuid"
done
fi
----------------
"cryptomount -u $uuid" is echoed into grub.cfg as seen below
----------------

menuentry 'Ubuntu GNU/Linux'{
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha1
insmod lvm
insmod ext2
cryptomount -u f804b7d24ec3460aaa45b0bcd8d294ac
set root='lvmid/mi5iPo-r7rN-RZ5n-oD5M-7UNA-espt-Y5JCrX/
----------------

Now with my modified grub-mkconfig_lib.in it replaces all instances of "cryptomount -u $uuid" with the contents of mattle_opts.cfg by echoing the contents instead of echoing "cryptomount -u $uuid". Now to do the same as above but for a LUKS device with detached header.

mattle_opts.cfg file contents -->

search.pt_uuid 12345678-01 luks_device
search.fs_uuid 1234-5678 usb_with_header_file
cryptomount --header=($usb_with_header_file)/header.bin ($luks_device)
----------------
prepare_grub_to_access_device ()
{
.
.
.
if [ x$GRUB_ENABLE_CRYPTODISK = xy ]; then
if [ x$GRUB_ENABLE_CRYPTODISK_MATTLE_OPTS = xy ]; then
.
.
.
if test -f "${prefix}/etc/mattle_opts.cfg"; then
while read -r WHOLE_FILE; do echo "$WHOLE_FILE" ; done < ${prefix}/etc/mattle_opts.cfg
else
gettext_printf "Error: cannot open %s\n" "${prefix}/etc/mattle_opts.cfg" 1>&2
exit 1
fi
else
for uuid in `"${grub_probe}" --device $@ --target=cryptodisk_uuid`; do
echo "cryptomount -u $uuid"
done
fi
fi
----------------
grub.cfg
----------------
menuentry 'Ubuntu GNU/Linux' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod cryptodisk
insmod luks
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha1
insmod lvm
insmod ext2
search.pt_uuid 12345678-01 luks_device
search.fs_uuid 1234-5678 usb_with_header_file
cryptomount --header=($usb_with_header_file)/header.bin ($luks_device)
set root='lvmid/mi5iPo-r7rN-RZ5n-oD5M-7UNA-espt-Y5JCrX/
----------------

The grub.cfg is the same, including loaded modules, with the only difference from mattle_opts.cfg.

[-- Attachment #2: Type: text/html, Size: 5221 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Support for plain dm-crypt and detached LUKS header
       [not found]     ` <1bc0f195bbb6b33a9491fedb95e6148e@xenhideout.nl>
  2017-04-11  5:05       ` Mat628
@ 2017-04-11  5:23       ` Mat628
  1 sibling, 0 replies; 4+ messages in thread
From: Mat628 @ 2017-04-11  5:23 UTC (permalink / raw)
  To: Xen; +Cc: help-grub, The development of GNU GRUB

[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]

>Am I correct in stating that your patches would only require:

>- command line options on each invocation of grub-install to reference a config file of sorts - a config file in a dedicated directory that would allow this config to persist

Xen, yes you are correct. The config file (${prefix}/etc/mattle_opts.cfg) persists in that directory and is opened in "read-only" mode by both grub-install and grub-mkconfig automatically.

Once the config file has been set for a particular setup it does not need to be modified.

Example:
To install grub to /boot/grub on the OS rootfs of a LUKS device (dev/sda1) with detached header file (/mnt/usb/sda1_header.bin) and have boot.img and core.img on usb (/dev/sdb)

----------------
mount /dev/sdb1 /mnt/usb
grub-install --crypto-device=/dev/sda1 --crypto-header=/mnt/usb/sda1_header.bin /dev/sdb

----------------
Then for grub-mkconfig to auto-generate grub.cfg to /boot/grub

----------------
grub-mkconfig -o /boot/grub/grub.cfg

----------------

That is all that would be required of the user for each invocation of grub-install and grub-mkconfig.

The contents of mattle_opts.cfg are fprintf'ed into load.cfg which is inside core.img.

Simply put one thing my patches can do is "reconnect" the detached header to the LUKS device (only in memory, the header is not wrote back to the disk) and from that point on grub-utils will be able to treat the LUKS device as normal.

best regards,

matt

p.s. I hope the formatting was a bit better this time.

[-- Attachment #2: Type: text/html, Size: 1996 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-04-11  5:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <4gDHpwpSsh5XJ-vHQwcowPqEhqLjNLizrokGB4Tb3SlFV--IOCSIYmogammiHB3CmC1AL9Qa1GLO_05eZeTZoHEKBbyoDDUCk3ImfTGDy98=@protonmail.com>
2017-04-09  6:29 ` Support for plain dm-crypt and detached LUKS header Andrei Borzenkov
2017-04-10 10:46   ` Mat628
     [not found]     ` <1bc0f195bbb6b33a9491fedb95e6148e@xenhideout.nl>
2017-04-11  5:05       ` Mat628
2017-04-11  5:23       ` Mat628

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.