[PATCH v3 0/3] Cryptomount detached headers

[PATCH v3 0/3] Cryptomount detached headers

[Glenn Washburn]

Updates since v2:
 * Address uneeded ret variable pointed out by Patrick
 * Rebased onto latest master with keyfile and security changes. I don't think
   this actually changed these patches though.

Conceptually the approach is different than the previous detach header
series because this one uses the disk objects read hook to hook reads to
the disk in scan() and recover_key() such that if there is an associated
header file, the hook will cause the read to return data from the header
file instead of from the source disk.

For this the read hook implementation needed to be upgaded because prior
it didn't get the read buffer sent from the read caller and so could not
modify its contents. Patch #1 updates the hook accordingly and all instances
of its use, but doesn't functionally change how GRUB operates.

The second patch adds the header option to cryptomount and the read hook
to the source disk during the scan() and recover_key() stages.
The benefit of this approach is its simpler/less code and does not require
the modification of backends, except to potentially cause a failure in
scan() if the backend doesn't support the current implementation of detached
headers, as with the GELI backend. This implementation requires that the
crypto volume header reside at the beginning of the volume. GELI has its
header at the end, which is why it can not currently be supported. In
theory, GELI could be supported if extra assumptions about its source
access pattern during scan() and recovery_key() were made. I don't use GELI,
no one seems to be asking for GELI detached headers, and I don't think that
GELI even support detached headers with the official tools. So for me, not
supporting crypto volumes with headers at the end of the disk is not a big
deal. With the patch series each backend gets the header file through cargs,
so it can implement detached headers by solely operating on that file instead
of the hooked source disk. In the the future, a flag can be added to the
cryptodisk_dev_t that backends can sent when registering to enabled/disable
the use of the read hook, if the backend needs to read from both the detached
header file and the source disk.

Glenn

Glenn Washburn (3):
  disk: Allow read hook callback to take read buffer to potentially
    modify it
  cryptodisk: Add support for using detached header files
  docs: Add documentation on detached header option to cryptomount

 docs/grub.texi                 | 13 +++--
 grub-core/commands/blocklist.c | 10 ++--
 grub-core/commands/loadenv.c   |  8 +--
 grub-core/commands/testload.c  |  4 +-
 grub-core/disk/cryptodisk.c    | 92 ++++++++++++++++++++++++++++++++--
 grub-core/disk/geli.c          |  4 ++
 grub-core/fs/hfspluscomp.c     |  4 +-
 grub-core/fs/ntfscomp.c        | 14 +++---
 grub-core/kern/disk.c          | 12 ++---
 grub-core/lib/progress.c       | 11 ++--
 grub-core/net/net.c            |  2 +-
 include/grub/cryptodisk.h      |  2 +
 include/grub/disk.h            |  6 +--
 include/grub/file.h            |  2 +
 14 files changed, 146 insertions(+), 38 deletions(-)

Range-diff against v2:
1:  91fa9a8eb ! 1:  a74dfb620 disk: Allow read hook callback to take read buffer to potentially modify it
    @@ Commit message
         hook. Also changed is that now when the read hook callback is called it can
         also indicate what error code should be sent back to the read caller.
     
    +    Signed-off-by: Glenn Washburn <development@efficientek.com>
    +    Reviewed-by: Patrick Steinhardt <ps@pks.im>
    +
      ## grub-core/commands/blocklist.c ##
     @@ grub-core/commands/blocklist.c: print_blocklist (grub_disk_addr_t sector, unsigned num,
      }
2:  f16d0a8b0 ! 2:  39bbab75c cryptodisk: Add support for using detached header files
    @@ Commit message
         Also add a --header (short -H) option to cryptomount which takes a file
         argument.
     
    +    Signed-off-by: Glenn Washburn <development@efficientek.com>
    +    Reviewed-by: Patrick Steinhardt <ps@pks.im>
    +
      ## grub-core/disk/cryptodisk.c ##
     @@ grub-core/disk/cryptodisk.c: enum
          OPTION_PASSWORD,
    @@ grub-core/disk/cryptodisk.c: cryptodisk_close (grub_cryptodisk_t dev)
     +cryptodisk_read_hook (grub_disk_addr_t sector, unsigned offset,
     +		      unsigned length, char *buf, void *data)
     +{
    -+  grub_err_t ret = GRUB_ERR_NONE;
     +  cryptodisk_read_hook_ctx_t ctx = data;
     +
     +  if (ctx->hdr_file == NULL)
    @@ grub-core/disk/cryptodisk.c: cryptodisk_close (grub_cryptodisk_t dev)
     +      return grub_errno;
     +    }
     +
    -+  return ret;
    ++  return GRUB_ERR_NONE;
     +}
     +
      static grub_cryptodisk_t
    @@ include/grub/cryptodisk.h: struct grub_cryptomount_args
      ## include/grub/file.h ##
     @@ include/grub/file.h: enum grub_file_type
          GRUB_FILE_TYPE_ZFS_ENCRYPTION_KEY,
    -     /* File holding the encryption key */
    +     /* File holding the encryption key. */
          GRUB_FILE_TYPE_CRYPTODISK_ENCRYPTION_KEY,
     +    /* File holding the encryption metadata header */
     +    GRUB_FILE_TYPE_CRYPTODISK_DETACHED_HEADER,
3:  f13a6e840 ! 3:  2deb90d33 docs: Add documentation on detached header option to cryptomount
    @@ Metadata
      ## Commit message ##
         docs: Add documentation on detached header option to cryptomount
     
    +    Signed-off-by: Glenn Washburn <development@efficientek.com>
    +    Reviewed-by: Patrick Steinhardt <ps@pks.im>
    +
      ## docs/grub.texi ##
     @@ docs/grub.texi: Alias for @code{hashsum --hash crc32 arg @dots{}}. See command @command{hashsum}
      @node cryptomount
-- 
2.34.1

[PATCH v3 1/3] disk: Allow read hook callback to take read buffer to potentially modify it

[Glenn Washburn]

It will be desirable in the future to allow having the read hook modify the
data passed back from a read function call on a disk or file. This adds that
infrustructure and has no impact on code flow for existing uses of the read
hook. Also changed is that now when the read hook callback is called it can
also indicate what error code should be sent back to the read caller.

Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Patrick Steinhardt <ps@pks.im>
---
 grub-core/commands/blocklist.c | 10 ++++++----
 grub-core/commands/loadenv.c   |  8 +++++---
 grub-core/commands/testload.c  |  4 +++-
 grub-core/fs/hfspluscomp.c     |  4 ++--
 grub-core/fs/ntfscomp.c        | 14 +++++++-------
 grub-core/kern/disk.c          | 12 ++++++------
 grub-core/lib/progress.c       | 11 +++++++----
 grub-core/net/net.c            |  2 +-
 include/grub/disk.h            |  6 +++---
 9 files changed, 40 insertions(+), 31 deletions(-)

diff --git a/grub-core/commands/blocklist.c b/grub-core/commands/blocklist.c
index 944449b77..48fd85a33 100644
--- a/grub-core/commands/blocklist.c
+++ b/grub-core/commands/blocklist.c
@@ -53,9 +53,9 @@ print_blocklist (grub_disk_addr_t sector, unsigned num,
 }
 
 /* Helper for grub_cmd_blocklist.  */
-static void
+static grub_err_t
 read_blocklist (grub_disk_addr_t sector, unsigned offset, unsigned length,
-		void *data)
+		char *buf __attribute__ ((unused)), void *data)
 {
   struct blocklist_ctx *ctx = data;
 
@@ -70,7 +70,7 @@ read_blocklist (grub_disk_addr_t sector, unsigned offset, unsigned length,
 	}
 
       if (!length)
-	return;
+	return GRUB_ERR_NONE;
       print_blocklist (ctx->start_sector, ctx->num_sectors, 0, 0, ctx);
       ctx->num_sectors = 0;
     }
@@ -87,7 +87,7 @@ read_blocklist (grub_disk_addr_t sector, unsigned offset, unsigned length,
     }
 
   if (!length)
-    return;
+    return GRUB_ERR_NONE;
 
   if (length & (GRUB_DISK_SECTOR_SIZE - 1))
     {
@@ -103,6 +103,8 @@ read_blocklist (grub_disk_addr_t sector, unsigned offset, unsigned length,
       ctx->start_sector = sector;
       ctx->num_sectors = length >> GRUB_DISK_SECTOR_BITS;
     }
+
+  return GRUB_ERR_NONE;
 }
 
 static grub_err_t
diff --git a/grub-core/commands/loadenv.c b/grub-core/commands/loadenv.c
index 3fd664aac..166445849 100644
--- a/grub-core/commands/loadenv.c
+++ b/grub-core/commands/loadenv.c
@@ -352,16 +352,16 @@ struct grub_cmd_save_env_ctx
 };
 
 /* Store blocklists in a linked list.  */
-static void
+static grub_err_t
 save_env_read_hook (grub_disk_addr_t sector, unsigned offset, unsigned length,
-		    void *data)
+		    char *buf __attribute__ ((unused)), void *data)
 {
   struct grub_cmd_save_env_ctx *ctx = data;
   struct blocklist *block;
 
   block = grub_malloc (sizeof (*block));
   if (! block)
-    return;
+    return GRUB_ERR_NONE;
 
   block->sector = sector;
   block->offset = offset;
@@ -374,6 +374,8 @@ save_env_read_hook (grub_disk_addr_t sector, unsigned offset, unsigned length,
   ctx->tail = block;
   if (! ctx->head)
     ctx->head = block;
+
+  return GRUB_ERR_NONE;
 }
 
 static grub_err_t
diff --git a/grub-core/commands/testload.c b/grub-core/commands/testload.c
index ff01a0516..76a8af94c 100644
--- a/grub-core/commands/testload.c
+++ b/grub-core/commands/testload.c
@@ -32,10 +32,11 @@
 GRUB_MOD_LICENSE ("GPLv3+");
 
 /* Helper for grub_cmd_testload.  */
-static void
+static grub_err_t
 read_progress (grub_disk_addr_t sector __attribute__ ((unused)),
 	       unsigned offset __attribute__ ((unused)),
 	       unsigned len,
+	       char *buf __attribute__ ((unused)),
 	       void *data __attribute__ ((unused)))
 {
   for (; len >= GRUB_DISK_SECTOR_SIZE; len -= GRUB_DISK_SECTOR_SIZE)
@@ -43,6 +44,7 @@ read_progress (grub_disk_addr_t sector __attribute__ ((unused)),
   if (len)
     grub_xputs (".");
   grub_refresh ();
+  return GRUB_ERR_NONE;
 }
 
 static grub_err_t
diff --git a/grub-core/fs/hfspluscomp.c b/grub-core/fs/hfspluscomp.c
index 095ea48c9..48ae438d8 100644
--- a/grub-core/fs/hfspluscomp.c
+++ b/grub-core/fs/hfspluscomp.c
@@ -123,7 +123,7 @@ hfsplus_read_compressed_real (struct grub_hfsplus_file *node,
     {
       grub_memcpy (buf, node->cbuf + pos, len);
       if (grub_file_progress_hook && node->file)
-	grub_file_progress_hook (0, 0, len, node->file);
+	grub_file_progress_hook (0, 0, len, NULL, node->file);
       return len;
     }
 
@@ -170,7 +170,7 @@ hfsplus_read_compressed_real (struct grub_hfsplus_file *node,
       grub_memcpy (buf, node->cbuf + (pos % HFSPLUS_COMPRESS_BLOCK_SIZE),
 		   curlen);
       if (grub_file_progress_hook && node->file)
-	grub_file_progress_hook (0, 0, curlen, node->file);
+	grub_file_progress_hook (0, 0, curlen, NULL, node->file);
       buf += curlen;
       pos += curlen;
       len -= curlen;
diff --git a/grub-core/fs/ntfscomp.c b/grub-core/fs/ntfscomp.c
index 3cd97d337..a009f2c2d 100644
--- a/grub-core/fs/ntfscomp.c
+++ b/grub-core/fs/ntfscomp.c
@@ -227,7 +227,7 @@ read_block (struct grub_ntfs_rlst *ctx, grub_uint8_t *buf, grub_size_t num)
 		  grub_memset (buf, 0, nn * GRUB_NTFS_COM_LEN);
 		  buf += nn * GRUB_NTFS_COM_LEN;
 		  if (grub_file_progress_hook && ctx->file)
-		    grub_file_progress_hook (0, 0, nn * GRUB_NTFS_COM_LEN,
+		    grub_file_progress_hook (0, 0, nn * GRUB_NTFS_COM_LEN, NULL,
 					     ctx->file);
 		}
 	    }
@@ -240,7 +240,7 @@ read_block (struct grub_ntfs_rlst *ctx, grub_uint8_t *buf, grub_size_t num)
 		  if (buf)
 		    buf += GRUB_NTFS_COM_LEN;
 		  if (grub_file_progress_hook && ctx->file)
-		    grub_file_progress_hook (0, 0, GRUB_NTFS_COM_LEN,
+		    grub_file_progress_hook (0, 0, GRUB_NTFS_COM_LEN, NULL,
 					     ctx->file);
 		  nn--;
 		}
@@ -271,7 +271,7 @@ read_block (struct grub_ntfs_rlst *ctx, grub_uint8_t *buf, grub_size_t num)
 		  if (grub_file_progress_hook && ctx->file)
 		    grub_file_progress_hook (0, 0,
 					     tt << (ctx->comp.log_spc
-						    + GRUB_NTFS_BLK_SHR),
+						    + GRUB_NTFS_BLK_SHR), NULL,
 					     ctx->file);
 		  buf += tt << (ctx->comp.log_spc + GRUB_NTFS_BLK_SHR);
 		}
@@ -294,7 +294,7 @@ read_block (struct grub_ntfs_rlst *ctx, grub_uint8_t *buf, grub_size_t num)
 		  if (grub_file_progress_hook && ctx->file)
 		    grub_file_progress_hook (0, 0,
 					     nn << (ctx->comp.log_spc
-						    + GRUB_NTFS_BLK_SHR),
+						    + GRUB_NTFS_BLK_SHR), NULL,
 					     ctx->file);
 		}
 	      ctx->target_vcn += nn;
@@ -323,7 +323,7 @@ ntfscomp (grub_uint8_t *dest, grub_disk_addr_t ofs,
 
 	  grub_memcpy (dest, ctx->attr->sbuf + ofs - ctx->attr->save_pos, n);
 	  if (grub_file_progress_hook && ctx->file)
-	    grub_file_progress_hook (0, 0, n, ctx->file);
+	    grub_file_progress_hook (0, 0, n, NULL, ctx->file);
 	  if (n == len)
 	    return 0;
 
@@ -390,7 +390,7 @@ ntfscomp (grub_uint8_t *dest, grub_disk_addr_t ofs,
 	n = len;
       grub_memcpy (dest, &ctx->attr->sbuf[o], n);
       if (grub_file_progress_hook && ctx->file)
-	grub_file_progress_hook (0, 0, n, ctx->file);
+	grub_file_progress_hook (0, 0, n, NULL, ctx->file);
       if (n == len)
 	goto quit;
       dest += n;
@@ -422,7 +422,7 @@ ntfscomp (grub_uint8_t *dest, grub_disk_addr_t ofs,
 
       grub_memcpy (dest, ctx->attr->sbuf, len);
       if (grub_file_progress_hook && file)
-	grub_file_progress_hook (0, 0, len, file);
+	grub_file_progress_hook (0, 0, len, NULL, file);
     }
 
 quit:
diff --git a/grub-core/kern/disk.c b/grub-core/kern/disk.c
index 3a42c007b..01190085e 100644
--- a/grub-core/kern/disk.c
+++ b/grub-core/kern/disk.c
@@ -402,10 +402,10 @@ grub_disk_read_small (grub_disk_t disk, grub_disk_addr_t sector,
   if (err)
     return err;
   if (disk->read_hook)
-    (disk->read_hook) (sector + (offset >> GRUB_DISK_SECTOR_BITS),
-		       offset & (GRUB_DISK_SECTOR_SIZE - 1),
-		       size, disk->read_hook_data);
-  return GRUB_ERR_NONE;
+    err = (disk->read_hook) (sector + (offset >> GRUB_DISK_SECTOR_BITS),
+			     offset & (GRUB_DISK_SECTOR_SIZE - 1),
+			     size, buf, disk->read_hook_data);
+  return err;
 }
 
 /* Read data from the disk.  */
@@ -501,7 +501,7 @@ grub_disk_read (grub_disk_t disk, grub_disk_addr_t sector,
 
 	  if (disk->read_hook)
 	    (disk->read_hook) (sector, 0, agglomerate << (GRUB_DISK_CACHE_BITS + GRUB_DISK_SECTOR_BITS),
-			       disk->read_hook_data);
+			       buf, disk->read_hook_data);
 
 	  sector += agglomerate << GRUB_DISK_CACHE_BITS;
 	  size -= agglomerate << (GRUB_DISK_CACHE_BITS + GRUB_DISK_SECTOR_BITS);
@@ -513,7 +513,7 @@ grub_disk_read (grub_disk_t disk, grub_disk_addr_t sector,
 	{
 	  if (disk->read_hook)
 	    (disk->read_hook) (sector, 0, (GRUB_DISK_CACHE_SIZE << GRUB_DISK_SECTOR_BITS),
-			       disk->read_hook_data);
+			       buf, disk->read_hook_data);
 	  sector += GRUB_DISK_CACHE_SIZE;
 	  buf = (char *) buf + (GRUB_DISK_CACHE_SIZE << GRUB_DISK_SECTOR_BITS);
 	  size -= (GRUB_DISK_CACHE_SIZE << GRUB_DISK_SECTOR_BITS);
diff --git a/grub-core/lib/progress.c b/grub-core/lib/progress.c
index 4b7cbbca6..4f4389dd5 100644
--- a/grub-core/lib/progress.c
+++ b/grub-core/lib/progress.c
@@ -29,10 +29,11 @@ GRUB_MOD_LICENSE ("GPLv3+");
 
 #define UPDATE_INTERVAL 800
 
-static void
+static grub_err_t
 grub_file_progress_hook_real (grub_disk_addr_t sector __attribute__ ((unused)),
                               unsigned offset __attribute__ ((unused)),
-                              unsigned length, void *data)
+                              unsigned length,
+			      char *buf __attribute__ ((unused)), void *data)
 {
   static int call_depth = 0;
   grub_uint64_t now;
@@ -42,11 +43,11 @@ grub_file_progress_hook_real (grub_disk_addr_t sector __attribute__ ((unused)),
   file->progress_offset += length;
 
   if (call_depth)
-    return;
+    return GRUB_ERR_NONE;
 
   e = grub_env_get ("enable_progress_indicator");
   if (e && e[0] == '0') {
-    return;
+    return GRUB_ERR_NONE;
   }
 
   call_depth = 1;
@@ -132,6 +133,8 @@ grub_file_progress_hook_real (grub_disk_addr_t sector __attribute__ ((unused)),
       last_progress_update_time = now;
     }
   call_depth = 0;
+
+  return GRUB_ERR_NONE;
 }
 
 GRUB_MOD_INIT(progress)
diff --git a/grub-core/net/net.c b/grub-core/net/net.c
index 9f09f8e48..064e7114e 100644
--- a/grub-core/net/net.c
+++ b/grub-core/net/net.c
@@ -1662,7 +1662,7 @@ grub_net_fs_read_real (grub_file_t file, char *buf, grub_size_t len)
 	  total += amount;
 	  file->device->net->offset += amount;
 	  if (grub_file_progress_hook)
-	    grub_file_progress_hook (0, 0, amount, file);
+	    grub_file_progress_hook (0, 0, amount, NULL, file);
 	  if (buf)
 	    {
 	      grub_memcpy (ptr, nb->data, amount);
diff --git a/include/grub/disk.h b/include/grub/disk.h
index a17d257c3..25c141ea2 100644
--- a/include/grub/disk.h
+++ b/include/grub/disk.h
@@ -110,9 +110,9 @@ extern grub_disk_dev_t EXPORT_VAR (grub_disk_dev_list);
 
 struct grub_partition;
 
-typedef void (*grub_disk_read_hook_t) (grub_disk_addr_t sector,
-				       unsigned offset, unsigned length,
-				       void *data);
+typedef grub_err_t (*grub_disk_read_hook_t) (grub_disk_addr_t sector,
+					     unsigned offset, unsigned length,
+					     char *buf, void *data);
 
 /* Disk.  */
 struct grub_disk
-- 
2.34.1

[PATCH v3 2/3] cryptodisk: Add support for using detached header files

[Glenn Washburn]

Using the disk read hook mechanism, setup a read hook on the source disk
which will read from the given header file during the scan and recovery
cryptodisk backend functions. Disk read hooks are executed after the data
has been read from the disk. This is okay, because the read hook is given
the read buffer before its sent back to the caller. In this case, the hook
can then overwrite the data read from the disk device with data from the
header file sent in as the read hook data. This is transparent to the
read caller. Since the callers of this function have just opened the
source disk, there are no current read hooks, so there's no need to
save/restore them nor consider if they should be called or not.

This hook assumes that the header is at the start of the volume, which
is not the case for some formats (eg. GELI). So GELI will return an
error if a detached header is specified. It also can only be used
with formats where the detached header file can be written to the
first blocks of the volume and the volume could still be unlocked.
So the header file can not be formatted differently from the on-disk
header. If these assumpts are not met, detached header file processing
must be specially handled in the cryptodisk backend module.

The hook will be called potentially many times by a backend. This is fine
because of the assumptions mentioned and the read hook reads from absolute
offsets and is stateless.

Also add a --header (short -H) option to cryptomount which takes a file
argument.

Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Patrick Steinhardt <ps@pks.im>
---
 grub-core/disk/cryptodisk.c | 92 +++++++++++++++++++++++++++++++++++--
 grub-core/disk/geli.c       |  4 ++
 include/grub/cryptodisk.h   |  2 +
 include/grub/file.h         |  2 +
 4 files changed, 96 insertions(+), 4 deletions(-)

diff --git a/grub-core/disk/cryptodisk.c b/grub-core/disk/cryptodisk.c
index c80cf9907..f1fe0d390 100644
--- a/grub-core/disk/cryptodisk.c
+++ b/grub-core/disk/cryptodisk.c
@@ -43,7 +43,8 @@ enum
     OPTION_PASSWORD,
     OPTION_KEYFILE,
     OPTION_KEYFILE_OFFSET,
-    OPTION_KEYFILE_SIZE
+    OPTION_KEYFILE_SIZE,
+    OPTION_HEADER
   };
 
 static const struct grub_arg_option options[] =
@@ -56,9 +57,16 @@ static const struct grub_arg_option options[] =
     {"key-file", 'k', 0, N_("Key file"), 0, ARG_TYPE_STRING},
     {"keyfile-offset", 'O', 0, N_("Key file offset (bytes)"), 0, ARG_TYPE_INT},
     {"keyfile-size", 'S', 0, N_("Key file data size (bytes)"), 0, ARG_TYPE_INT},
+    {"header", 'H', 0, N_("Read header from file"), 0, ARG_TYPE_STRING},
     {0, 0, 0, 0, 0, 0}
   };
 
+struct cryptodisk_read_hook_ctx
+{
+  grub_file_t hdr_file;
+};
+typedef struct cryptodisk_read_hook_ctx *cryptodisk_read_hook_ctx_t;
+
 /* Our irreducible polynom is x^128+x^7+x^2+x+1. Lowest byte of it is:  */
 #define GF_POLYNOM 0x87
 static inline int GF_PER_SECTOR (const struct grub_cryptodisk *dev)
@@ -1004,6 +1012,30 @@ cryptodisk_close (grub_cryptodisk_t dev)
   grub_free (dev);
 }
 
+static grub_err_t
+cryptodisk_read_hook (grub_disk_addr_t sector, unsigned offset,
+		      unsigned length, char *buf, void *data)
+{
+  cryptodisk_read_hook_ctx_t ctx = data;
+
+  if (ctx->hdr_file == NULL)
+    return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("header file not found"));
+
+  if (grub_file_seek (ctx->hdr_file,
+		      (sector * GRUB_DISK_SECTOR_SIZE) + offset)
+      == (grub_off_t) -1)
+    return grub_errno;
+
+  if (grub_file_read (ctx->hdr_file, buf, length) != (grub_ssize_t) length)
+    {
+      if (grub_errno == GRUB_ERR_NONE)
+	grub_error (GRUB_ERR_OUT_OF_RANGE, N_("header file too small"));
+      return grub_errno;
+    }
+
+  return GRUB_ERR_NONE;
+}
+
 static grub_cryptodisk_t
 grub_cryptodisk_scan_device_real (const char *name,
 				  grub_disk_t source,
@@ -1012,6 +1044,7 @@ grub_cryptodisk_scan_device_real (const char *name,
   grub_err_t ret = GRUB_ERR_NONE;
   grub_cryptodisk_t dev;
   grub_cryptodisk_dev_t cr;
+  struct cryptodisk_read_hook_ctx read_hook_data = {0};
   int askpass = 0;
   char *part = NULL;
 
@@ -1020,11 +1053,46 @@ grub_cryptodisk_scan_device_real (const char *name,
   if (dev)
     return dev;
 
+  if (cargs->hdr_file != NULL)
+    {
+      /*
+       * Set read hook to read header from a file instead of the source disk.
+       * Disk read hooks are executed after the data has been read from the
+       * disk. This is okay, because the read hook is given the read buffer
+       * before its sent back to the caller. In this case, the hook can then
+       * overwrite the data read from the disk device with data from the
+       * header file sent in as the read hook data. This is transparent to the
+       * read caller. Since the callers of this function have just opened the
+       * source disk, there are no current read hooks, so there's no need to
+       * save/restore them nor consider if they should be called or not.
+       *
+       * This hook assumes that the header is at the start of the volume, which
+       * is not the case for some formats (eg. GELI). It also can only be used
+       * with formats where the detached header file can be written to the
+       * first blocks of the volume and the volume could still be unlocked.
+       * So the header file can not be formatted differently from the on-disk
+       * header. If these assumpts are not met, detached header file processing
+       * must be specially handled in the cryptodisk backend module.
+       *
+       * This hook needs only be set once and will be called potentially many
+       * times by a backend. This is fine because of the assumptions mentioned
+       * and the read hook reads from absolute offsets and is stateless.
+       */
+      read_hook_data.hdr_file = cargs->hdr_file;
+      source->read_hook = cryptodisk_read_hook;
+      source->read_hook_data = (void *) &read_hook_data;
+    }
+
   FOR_CRYPTODISK_DEVS (cr)
   {
+    /*
+     * Loop through each cryptodisk backend that is registered (ie. loaded).
+     * If the scan returns NULL, then the backend being tested does not
+     * recognize the source disk, so move on to the next backend.
+     */
     dev = cr->scan (source, cargs);
     if (grub_errno)
-      return NULL;
+      goto error_no_close;
     if (!dev)
       continue;
 
@@ -1041,7 +1109,7 @@ grub_cryptodisk_scan_device_real (const char *name,
 
 	cargs->key_data = grub_malloc (GRUB_CRYPTODISK_MAX_PASSPHRASE);
 	if (cargs->key_data == NULL)
-	  return NULL;
+	  goto error_no_close;
 
 	if (!grub_password_get ((char *) cargs->key_data, GRUB_CRYPTODISK_MAX_PASSPHRASE))
 	  {
@@ -1066,9 +1134,13 @@ grub_cryptodisk_scan_device_real (const char *name,
 
  error:
   cryptodisk_close (dev);
+ error_no_close:
   dev = NULL;
 
  cleanup:
+  if (cargs->hdr_file != NULL)
+    source->read_hook = NULL;
+
   if (askpass)
     {
       cargs->key_len = 0;
@@ -1260,6 +1332,18 @@ grub_cmd_cryptomount (grub_extcmd_context_t ctxt, int argc, char **args)
 	return grub_error (GRUB_ERR_FILE_READ_ERROR, (N_("failed to read key file")));
     }
 
+  if (state[OPTION_HEADER].set) /* header */
+    {
+      if (state[OPTION_UUID].set)
+	return grub_error (GRUB_ERR_BAD_ARGUMENT,
+			   N_("cannot use UUID lookup with detached header"));
+
+      cargs.hdr_file = grub_file_open (state[OPTION_HEADER].arg,
+			    GRUB_FILE_TYPE_CRYPTODISK_DETACHED_HEADER);
+      if (cargs.hdr_file == NULL)
+	return grub_errno;
+    }
+
   if (state[OPTION_UUID].set) /* uuid */
     {
       int found_uuid;
@@ -1473,7 +1557,7 @@ GRUB_MOD_INIT (cryptodisk)
   grub_disk_dev_register (&grub_cryptodisk_dev);
   cmd = grub_register_extcmd ("cryptomount", grub_cmd_cryptomount, 0,
 			      N_("[ [-p password] | [-k keyfile"
-				 " [-O keyoffset] [-S keysize] ] ]"
+				 " [-O keyoffset] [-S keysize] ] ] [-H file]"
 				 " <SOURCE|-u UUID|-a|-b>"),
 			      N_("Mount a crypto device."), options);
   grub_procfs_register ("luks_script", &luks_script);
diff --git a/grub-core/disk/geli.c b/grub-core/disk/geli.c
index 91eb10122..b3c9bbd80 100644
--- a/grub-core/disk/geli.c
+++ b/grub-core/disk/geli.c
@@ -252,6 +252,10 @@ geli_scan (grub_disk_t disk, grub_cryptomount_args_t cargs)
   grub_disk_addr_t sector;
   grub_err_t err;
 
+  /* Detached headers are not implemented yet */
+  if (cargs->hdr_file != NULL)
+    return NULL;
+
   if (2 * GRUB_MD_SHA256->mdlen + 1 > GRUB_CRYPTODISK_MAX_UUID_LENGTH)
     return NULL;
 
diff --git a/include/grub/cryptodisk.h b/include/grub/cryptodisk.h
index 467065f00..d94df68b6 100644
--- a/include/grub/cryptodisk.h
+++ b/include/grub/cryptodisk.h
@@ -20,6 +20,7 @@
 #define GRUB_CRYPTODISK_HEADER	1
 
 #include <grub/disk.h>
+#include <grub/file.h>
 #include <grub/crypto.h>
 #include <grub/list.h>
 #ifdef GRUB_UTIL
@@ -79,6 +80,7 @@ struct grub_cryptomount_args
   grub_uint8_t *key_data;
   /* recover_key: Length of key_data */
   grub_size_t key_len;
+  grub_file_t hdr_file;
 };
 typedef struct grub_cryptomount_args *grub_cryptomount_args_t;
 
diff --git a/include/grub/file.h b/include/grub/file.h
index 153bea86f..a5bf3a792 100644
--- a/include/grub/file.h
+++ b/include/grub/file.h
@@ -92,6 +92,8 @@ enum grub_file_type
     GRUB_FILE_TYPE_ZFS_ENCRYPTION_KEY,
     /* File holding the encryption key. */
     GRUB_FILE_TYPE_CRYPTODISK_ENCRYPTION_KEY,
+    /* File holding the encryption metadata header */
+    GRUB_FILE_TYPE_CRYPTODISK_DETACHED_HEADER,
     /* File we open n grub-fstest.  */
     GRUB_FILE_TYPE_FSTEST,
     /* File we open n grub-mount.  */
-- 
2.34.1

[PATCH v3 3/3] docs: Add documentation on detached header option to cryptomount

[Glenn Washburn]

Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Patrick Steinhardt <ps@pks.im>
---
 docs/grub.texi | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index 1a7cd8e93..3c7217f0e 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4526,19 +4526,26 @@ Alias for @code{hashsum --hash crc32 arg @dots{}}. See command @command{hashsum}
 @node cryptomount
 @subsection cryptomount
 
-@deffn Command cryptomount [ [@option{-p} password] | [@option{-k} keyfile [@option{-O} keyoffset] [@option{-S} keysize] ] ] device|@option{-u} uuid|@option{-a}|@option{-b}
+@deffn Command cryptomount [ [@option{-p} password] | [@option{-k} keyfile [@option{-O} keyoffset] [@option{-S} keysize] ] ] [@option{-H} file] device|@option{-u} uuid|@option{-a}|@option{-b}
 Setup access to encrypted device. A passphrase will be requested interactively,
 if neither the @option{-p} nor @option{-k} options are given. The option
 @option{-p} can be used to supply a passphrase (useful for scripts).
 Alternatively the @option{-k} option can be used to supply a keyfile with
 options @option{-O} and @option{-S} optionally supplying the offset and size,
-respectively, of the key data in the given key file.
-
+respectively, of the key data in the given key file. The @option{-H} options can
+be used to supply cryptomount backends with an alternative header file (aka
+detached header). Not all backends have headers nor support alternative header
+files (currently only LUKS1 and LUKS2 support them).
 Argument @var{device} configures specific grub device
 (@pxref{Naming convention}); option @option{-u} @var{uuid} configures device
 with specified @var{uuid}; option @option{-a} configures all detected encrypted
 devices; option @option{-b} configures all geli containers that have boot flag set.
 
+Devices are not allowed to be given as key files nor as detached header files.
+However, this limitation can be worked around by using blocklist syntax. So
+for instance, @code{(hd1,gpt2)} can not be used, but @code{(hd1,gpt2)0+} will
+achieve the desired result.
+
 GRUB suports devices encrypted using LUKS, LUKS2 and geli. Note that necessary
 modules (@var{luks}, @var{luks2} and @var{geli}) have to be loaded manually
 before this command can be used. For LUKS2 only the PBKDF2 key derivation
-- 
2.34.1

Re: [PATCH v3 0/3] Cryptomount detached headers

[Daniel Kiper]

On Wed, Jun 08, 2022 at 10:34:01AM -0500, Glenn Washburn wrote:
> Updates since v2:
>  * Address uneeded ret variable pointed out by Patrick
>  * Rebased onto latest master with keyfile and security changes. I don't think
>    this actually changed these patches though.
>
> Conceptually the approach is different than the previous detach header
> series because this one uses the disk objects read hook to hook reads to
> the disk in scan() and recover_key() such that if there is an associated
> header file, the hook will cause the read to return data from the header
> file instead of from the source disk.
>
> For this the read hook implementation needed to be upgaded because prior
> it didn't get the read buffer sent from the read caller and so could not
> modify its contents. Patch #1 updates the hook accordingly and all instances
> of its use, but doesn't functionally change how GRUB operates.
>
> The second patch adds the header option to cryptomount and the read hook
> to the source disk during the scan() and recover_key() stages.
> The benefit of this approach is its simpler/less code and does not require
> the modification of backends, except to potentially cause a failure in
> scan() if the backend doesn't support the current implementation of detached
> headers, as with the GELI backend. This implementation requires that the
> crypto volume header reside at the beginning of the volume. GELI has its
> header at the end, which is why it can not currently be supported. In
> theory, GELI could be supported if extra assumptions about its source
> access pattern during scan() and recovery_key() were made. I don't use GELI,
> no one seems to be asking for GELI detached headers, and I don't think that
> GELI even support detached headers with the official tools. So for me, not
> supporting crypto volumes with headers at the end of the disk is not a big
> deal. With the patch series each backend gets the header file through cargs,
> so it can implement detached headers by solely operating on that file instead
> of the hooked source disk. In the the future, a flag can be added to the
> cryptodisk_dev_t that backends can sent when registering to enabled/disable
> the use of the read hook, if the backend needs to read from both the detached
> header file and the source disk.
>
> Glenn
>
> Glenn Washburn (3):
>   disk: Allow read hook callback to take read buffer to potentially
>     modify it
>   cryptodisk: Add support for using detached header files
>   docs: Add documentation on detached header option to cryptomount

For all the patches Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>...

Big thank you for all working on this!

Daniel

[PATCH v3 0/3] Cryptomount detached headers

[brutser]

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


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.




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

Re: [PATCH v3 0/3] Cryptomount detached headers

[Glenn Washburn]

On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
brutser@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

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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

Hi Glenn, 



To explain in more detail how I run my tests, because the whole picture can give you a better understanding as to why it fails with me:

1. As grub payload is used for coreboot, I first build coreboot for the system (default build, nothing special).

2. To build grub:

git clone https://git.savannah.gnu.org/git/grub.git

./bootstrap

./autogen.sh

./configure --with-platform=coreboot --disable-werror

make



3. Change modules in Makefile to match the ones I wrote earlier.

4. make default_payload.elf



5. Installation debian (expert install)

6. Encrypt 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

or LUKS1:

cryptsetup luksFormat --cipher aes-xts-plain64 --hash=sha256 --key-size=512 --header /path/to/header --type luks1 /dev/sda1

7. Create necessary logical volumes and start installation debian

8. add crypttab, copy the header and keyfiles to target system.



This exact same setup works fine with grub 2.04 and john lane's patches: https://grub.johnlane.ie/ (obviously only LUKS1 support).



I will try to debug, not really experience with that, but will try to figure it out.



Van: Glenn Washburn <development@efficientek.com>
Aan: brutser@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;
   dkiper@net-space.pl;
   ps@pks.im

On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
brutser@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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[Maxim Fomin]

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

------- Original Message -------

On Friday, July 29th, 2022 at 6:56 PM, brutser--- via Grub-devel <grub-devel@gnu.org> 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 error message sounds like luks (or luks2) module was not loaded. Did you load it before running cryptomount command?

Best regards,
Maxim Fomin​

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

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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

Maxim, thanks for the reply!

I built the grub payload with the luks2 module as you can see. In the grub config, but also when i test manually, i load at least:



insmod ahci
insmod lvm
insmod cryptodisk
insmod luks2

insmod part_msdos
insmod ext2




Van: Maxim Fomin <maxim@fomin.one>
Aan: The development of GNU GRUB <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 30/07/2022 08:51:51 Europe/Paris

------- Original Message -------

On Friday, July 29th, 2022 at 6:56 PM, brutser--- via Grub-devel <grub-devel@gnu.org> 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 error message sounds like luks (or luks2) module was not loaded. Did you load it before running cryptomount command?



Best regards,

Maxim Fomin​


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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

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 <development@efficientek.com>
Aan: brutser@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;
   dkiper@net-space.pl;
   ps@pks.im

On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
brutser@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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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

Glenn,



The most obvious error that jumps out: 

Read out of range: sector 0x32000 (attempt to read or write outside partition)


Van: brutser--- via Grub-devel <grub-devel@gnu.org>
Aan: grub-devel@gnu.org
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 30/07/2022 11:54:32 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@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 <development@efficientek.com>
Aan: brutser@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;
   dkiper@net-space.pl;
   ps@pks.im

On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
brutser@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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[Glenn Washburn]

On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> Aan: brutser@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;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> brutser@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
> 

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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

Glenn,



Still resorted to screenshots for the debug (with the added dprintf):



https://imgur.com/a/YkVMdBe



Van: Glenn Washburn <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 01/08/2022 22:50:27 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@pks.im

On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> Aan: brutser@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;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> brutser@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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[Glenn Washburn]

On Sat, 30 Jul 2022 20:48:54 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> 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 <grub-devel@gnu.org>
> Aan: grub-devel@gnu.org
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 30/07/2022 11:54:32 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@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 <development@efficientek.com>
> Aan: brutser@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;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> brutser@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 Washburn]

On Tue,  2 Aug 2022 00:21:09 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 01/08/2022 22:50:27 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > Aan: brutser@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;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > brutser@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

[brutser]

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



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 <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 02/08/2022 01:24:47 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@pks.im

On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 01/08/2022 22:50:27 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > Aan: brutser@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;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > brutser@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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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



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 <grub-devel@gnu.org>
Aan: grub-devel@gnu.org
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 02/08/2022 01:47:57 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@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 <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 02/08/2022 01:24:47 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@pks.im

On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 01/08/2022 22:50:27 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > Aan: brutser@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;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > brutser@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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[Glenn Washburn]

Hi Bruster,

Are you able to add your responses inline like I have been doing in my
replies? And not top-post, which is posting at the top.

On Tue,  2 Aug 2022 02:26:58 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> 
> 
> 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.

I'm not sure I understand why you're saying this. Did I ask you to do
something that you think you can't do because your "testing is very
limited"? You've proven capable of modifying the source code to add
debug log messages and successfully reproducing the issue in QEMU. That
makes your testing ability not very limited in my opinion. What am I
missing that you're wanting to convey here?

Since you've reproduced the issue in QEMU and I'm assuming that you're
not running coreboot in QEMU, then I conclude that coreboot is not a
relevant factor here. What exactly was the QEMU commandline you used in
getting the output you previously created? Did you ever try to get the
serial output with the QEMU options I suggested previously?

> 
> If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.

Why do you need another way of testing? As I mentioned above you can
modify the source code of GRUB and run that modified GRUB in QEMU. I
don't think we need another way. Were you having problems adding the
debug message to cryptodisk_read_hook I suggested in my last response?
I'm starting to think there is an issue in the hook mechanism, but I'd
like your help in confirming that.

> 
> Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> Aan: grub-devel@gnu.org
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 01:47:57 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> 
> 
> Debian 11.4 for all the testing.

Thanks for this info, but that wasn't what I was asking for. I asked
for the architecture and endianness. For example, are you running on
x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
little endian. But you could be running on a MIPS architecture that can
be either big or little endian. I want this confirmed so I can get the
full picture. I'm doubting now that this is important, but you never
know.

From your response below, I believe that the host and the target are
the same machine, but are you building GRUB on that machine as well?
Are you running QEMU for testing on that machine as well?

I haven't tried to reproduce this issue locally yet due to time
constraints and it may be a while before I can get to it. But we're
getting close to the point where it may require me doing that.

Glenn

> 
> 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 <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 01:24:47 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 01/08/2022 22:50:27 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > Aan: brutser@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;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > brutser@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
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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


Van: Glenn Washburn <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 02/08/2022 20:58:17 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@pks.im

Hi Bruster,

Are you able to add your responses inline like I have been doing in my
replies? And not top-post, which is posting at the top.

I will reply here, though my mail client is not really doing a great job to get this inline response done, sorry for that.

Let me be clear on my testing environment, I was purely testing latest grub as payload for coreboot, so even on qemu, I am using coreboot for BIOS with my compiled grub as one of the payloads.
I am testing on a basic Thinkpad laptop with x86_64 architecture.

"I'm not sure I understand why you're saying this.", I was basically just expressing that I was testing the functionality purely for my own setup, so if you wanted me to test more general (for example without coreboot), then you could say me.
Not that it shouldn't work with coreboot obviously, but if other testing could give more accurate results and debug logs for example, I am willing to do that, that was all.

On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> 
> 
> 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.

I'm not sure I understand why you're saying this. Did I ask you to do
something that you think you can't do because your "testing is very
limited"? You've proven capable of modifying the source code to add
debug log messages and successfully reproducing the issue in QEMU. That
makes your testing ability not very limited in my opinion. What am I
missing that you're wanting to convey here?

Since you've reproduced the issue in QEMU and I'm assuming that you're
not running coreboot in QEMU, then I conclude that coreboot is not a
relevant factor here. What exactly was the QEMU commandline you used in
getting the output you previously created? Did you ever try to get the
serial output with the QEMU options I suggested previously?

> 
> If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.

Why do you need another way of testing? As I mentioned above you can
modify the source code of GRUB and run that modified GRUB in QEMU. I
don't think we need another way. Were you having problems adding the
debug message to cryptodisk_read_hook I suggested in my last response?
I'm starting to think there is an issue in the hook mechanism, but I'd
like your help in confirming that.

> 
> Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> Aan: grub-devel@gnu.org
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 01:47:57 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> 
> 
> Debian 11.4 for all the testing.

Thanks for this info, but that wasn't what I was asking for. I asked
for the architecture and endianness. For example, are you running on
x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
little endian. But you could be running on a MIPS architecture that can
be either big or little endian. I want this confirmed so I can get the
full picture. I'm doubting now that this is important, but you never
know.

From your response below, I believe that the host and the target are
the same machine, but are you building GRUB on that machine as well?
Are you running QEMU for testing on that machine as well?

I haven't tried to reproduce this issue locally yet due to time
constraints and it may be a while before I can get to it. But we're
getting close to the point where it may require me doing that.

Glenn

> 
> 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 <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 01:24:47 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 01/08/2022 22:50:27 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > Aan: brutser@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;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > brutser@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
> _______________________________________________
> 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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[Glenn Washburn]

On Tue,  2 Aug 2022 22:49:27 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> 
> Van: Glenn Washburn <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 20:58:17 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> Hi Bruster,
> 
> Are you able to add your responses inline like I have been doing in my
> replies? And not top-post, which is posting at the top.
> 
> I will reply here, though my mail client is not really doing a great job to get this inline response done, sorry for that.

Ok, I figured that. However, you've not responded to much of my
comments that I wrote inline. Perhaps you only read the first part of
my response and do not realize that I wrote more response further down.
Please look at the full email until you see my name, which indicates
that I am finished responding. Please respond to all of my questions,
otherwise it makes it difficult to help you and if you don't take the
time to respond to me fully I am less inclined to help. I would like to
get this issue sorted out, but I need you to help me debug it right now.

Also, I have never built GRUB with coreboot, so I don't have a way to
precisely reproduce your setup anyway. And it currently does work for
me.

Glenn

> 
> Let me be clear on my testing environment, I was purely testing latest grub as payload for coreboot, so even on qemu, I am using coreboot for BIOS with my compiled grub as one of the payloads.
> I am testing on a basic Thinkpad laptop with x86_64 architecture.
> 
> "I'm not sure I understand why you're saying this.", I was basically just expressing that I was testing the functionality purely for my own setup, so if you wanted me to test more general (for example without coreboot), then you could say me.
> Not that it shouldn't work with coreboot obviously, but if other testing could give more accurate results and debug logs for example, I am willing to do that, that was all.
> 
> On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> 
> > 
> > 
> > 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.
> 
> I'm not sure I understand why you're saying this. Did I ask you to do
> something that you think you can't do because your "testing is very
> limited"? You've proven capable of modifying the source code to add
> debug log messages and successfully reproducing the issue in QEMU. That
> makes your testing ability not very limited in my opinion. What am I
> missing that you're wanting to convey here?
> 
> Since you've reproduced the issue in QEMU and I'm assuming that you're
> not running coreboot in QEMU, then I conclude that coreboot is not a
> relevant factor here. What exactly was the QEMU commandline you used in
> getting the output you previously created? Did you ever try to get the
> serial output with the QEMU options I suggested previously?
> 
> > 
> > If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.
> 
> Why do you need another way of testing? As I mentioned above you can
> modify the source code of GRUB and run that modified GRUB in QEMU. I
> don't think we need another way. Were you having problems adding the
> debug message to cryptodisk_read_hook I suggested in my last response?
> I'm starting to think there is an issue in the hook mechanism, but I'd
> like your help in confirming that.
> 
> > 
> > Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Aan: grub-devel@gnu.org
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:47:57 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > 
> > 
> > Debian 11.4 for all the testing.
> 
> Thanks for this info, but that wasn't what I was asking for. I asked
> for the architecture and endianness. For example, are you running on
> x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
> little endian. But you could be running on a MIPS architecture that can
> be either big or little endian. I want this confirmed so I can get the
> full picture. I'm doubting now that this is important, but you never
> know.
> 
> From your response below, I believe that the host and the target are
> the same machine, but are you building GRUB on that machine as well?
> Are you running QEMU for testing on that machine as well?
> 
> I haven't tried to reproduce this issue locally yet due to time
> constraints and it may be a while before I can get to it. But we're
> getting close to the point where it may require me doing that.
> 
> Glenn
> 
> > 
> > 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 <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:24:47 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 01/08/2022 22:50:27 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > Aan: brutser@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;
> > > >    dkiper@net-space.pl;
> > > >    ps@pks.im
> > > > 
> > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > > brutser@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
> > _______________________________________________
> > 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

[brutser]

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

See comments below.


Van: Glenn Washburn <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 03/08/2022 21:54:14 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@pks.im

On Tue, 2 Aug 2022 22:49:27 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> 
> Van: Glenn Washburn <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 20:58:17 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> Hi Bruster,
> 
> Are you able to add your responses inline like I have been doing in my
> replies? And not top-post, which is posting at the top.
> 
> I will reply here, though my mail client is not really doing a great job to get this inline response done, sorry for that.

Ok, I figured that. However, you've not responded to much of my
comments that I wrote inline. Perhaps you only read the first part of
my response and do not realize that I wrote more response further down.
Please look at the full email until you see my name, which indicates
that I am finished responding. Please respond to all of my questions,
otherwise it makes it difficult to help you and if you don't take the
time to respond to me fully I am less inclined to help. I would like to
get this issue sorted out, but I need you to help me debug it right now.

Also, I have never built GRUB with coreboot, so I don't have a way to
precisely reproduce your setup anyway. And it currently does work for
me.

Glenn

>>> Comments:
I think I read all your comments and tried to reply as best as possible.

I tried the following test to eliminate the coreboot issue >>

Qemu installation:

1. Minimal Debian 11.4 installation on /dev/sda1
2. git clone latest grub, make & make install, grub-install
3. Reboot Debian iso >
    Expert install Debian 11.4
    Exit to Shell >
    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 100%FREE -n root testvg
4. Complete minimal debian 11.4 installation on encrypted lvm
5. Save header to /dev/sda1
6. Copy header file to target initramfs, populate crypttab, some scripts to finish the encryption

7. Finish installation and reboot.
8. Exit to Grub cmd >
    insmod luks2
    insmod lvm
    insmod cryptodisk
    cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)

result: error: no cryptodisk module can handle this device.

> 
> Let me be clear on my testing environment, I was purely testing latest grub as payload for coreboot, so even on qemu, I am using coreboot for BIOS with my compiled grub as one of the payloads.
> I am testing on a basic Thinkpad laptop with x86_64 architecture.
> 
> "I'm not sure I understand why you're saying this.", I was basically just expressing that I was testing the functionality purely for my own setup, so if you wanted me to test more general (for example without coreboot), then you could say me.
> Not that it shouldn't work with coreboot obviously, but if other testing could give more accurate results and debug logs for example, I am willing to do that, that was all.
> 
> On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> 
> > 
> > 
> > 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.
> 
> I'm not sure I understand why you're saying this. Did I ask you to do
> something that you think you can't do because your "testing is very
> limited"? You've proven capable of modifying the source code to add
> debug log messages and successfully reproducing the issue in QEMU. That
> makes your testing ability not very limited in my opinion. What am I
> missing that you're wanting to convey here?
> 
> Since you've reproduced the issue in QEMU and I'm assuming that you're
> not running coreboot in QEMU, then I conclude that coreboot is not a
> relevant factor here. What exactly was the QEMU commandline you used in
> getting the output you previously created? Did you ever try to get the
> serial output with the QEMU options I suggested previously?
> 
> > 
> > If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.
> 
> Why do you need another way of testing? As I mentioned above you can
> modify the source code of GRUB and run that modified GRUB in QEMU. I
> don't think we need another way. Were you having problems adding the
> debug message to cryptodisk_read_hook I suggested in my last response?
> I'm starting to think there is an issue in the hook mechanism, but I'd
> like your help in confirming that.
> 
> > 
> > Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Aan: grub-devel@gnu.org
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:47:57 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > 
> > 
> > Debian 11.4 for all the testing.
> 
> Thanks for this info, but that wasn't what I was asking for. I asked
> for the architecture and endianness. For example, are you running on
> x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
> little endian. But you could be running on a MIPS architecture that can
> be either big or little endian. I want this confirmed so I can get the
> full picture. I'm doubting now that this is important, but you never
> know.
> 
> From your response below, I believe that the host and the target are
> the same machine, but are you building GRUB on that machine as well?
> Are you running QEMU for testing on that machine as well?
> 
> I haven't tried to reproduce this issue locally yet due to time
> constraints and it may be a while before I can get to it. But we're
> getting close to the point where it may require me doing that.
> 
> Glenn
> 
> > 
> > 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 <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:24:47 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 01/08/2022 22:50:27 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > Aan: brutser@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;
> > > >    dkiper@net-space.pl;
> > > >    ps@pks.im
> > > > 
> > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > > brutser@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
> > _______________________________________________
> > 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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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

New comments below.

See comments below.


Van: Glenn Washburn <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 03/08/2022 21:54:14 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@pks.im

On Tue, 2 Aug 2022 22:49:27 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> 
> Van: Glenn Washburn <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 20:58:17 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> Hi Bruster,
> 
> Are you able to add your responses inline like I have been doing in my
> replies? And not top-post, which is posting at the top.
> 
> I will reply here, though my mail client is not really doing a great job to get this inline response done, sorry for that.

Ok, I figured that. However, you've not responded to much of my
comments that I wrote inline. Perhaps you only read the first part of
my response and do not realize that I wrote more response further down.
Please look at the full email until you see my name, which indicates
that I am finished responding. Please respond to all of my questions,
otherwise it makes it difficult to help you and if you don't take the
time to respond to me fully I am less inclined to help. I would like to
get this issue sorted out, but I need you to help me debug it right now.

Also, I have never built GRUB with coreboot, so I don't have a way to
precisely reproduce your setup anyway. And it currently does work for
me.

Glenn

>>> Comments:
I think I read all your comments and tried to reply as best as possible.

I tried the following test to eliminate the coreboot issue >>

Qemu installation:

1. Minimal Debian 11.4 installation on /dev/sda1
2. git clone latest grub, make & make install, grub-install
3. Reboot Debian iso >
    Expert install Debian 11.4
    Exit to Shell >
    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 100%FREE -n root testvg
4. Complete minimal debian 11.4 installation on encrypted lvm
5. Save header to /dev/sda1
6. Copy header file to target initramfs, populate crypttab, some scripts to finish the encryption

7. Finish installation and reboot.
8. Exit to Grub cmd >
    insmod luks2
    insmod lvm
    insmod cryptodisk
    cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)

result: error: no cryptodisk module can handle this device.

>>> New comments:

Getting closer to a solution here, I was just playing around with it and suddenly I was asked passphrase when entering this line:
cryptomount -H (hd0,msdos1)/header.bin (hd0)

or when I tried this in the coreboot setup, I changed to: cryptomount -H (ahci0,msdos1)/header.bin (ahci0)

wrong passphrase and I get the correct error and correct passphrase and I get Slot "0" opened and "ls /" is showing me: (crypto0)

though it can't handle the logical volume and a simple "ls (crypto0)/" will give error: unknown filesystem.

But why does it accept (hd0), while we clearly encrypted the 2nd partition /dev/sda2 (hd0,msdos2) ?

Anyway, hope this helps.



> 
> Let me be clear on my testing environment, I was purely testing latest grub as payload for coreboot, so even on qemu, I am using coreboot for BIOS with my compiled grub as one of the payloads.
> I am testing on a basic Thinkpad laptop with x86_64 architecture.
> 
> "I'm not sure I understand why you're saying this.", I was basically just expressing that I was testing the functionality purely for my own setup, so if you wanted me to test more general (for example without coreboot), then you could say me.
> Not that it shouldn't work with coreboot obviously, but if other testing could give more accurate results and debug logs for example, I am willing to do that, that was all.
> 
> On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> 
> > 
> > 
> > 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.
> 
> I'm not sure I understand why you're saying this. Did I ask you to do
> something that you think you can't do because your "testing is very
> limited"? You've proven capable of modifying the source code to add
> debug log messages and successfully reproducing the issue in QEMU. That
> makes your testing ability not very limited in my opinion. What am I
> missing that you're wanting to convey here?
> 
> Since you've reproduced the issue in QEMU and I'm assuming that you're
> not running coreboot in QEMU, then I conclude that coreboot is not a
> relevant factor here. What exactly was the QEMU commandline you used in
> getting the output you previously created? Did you ever try to get the
> serial output with the QEMU options I suggested previously?
> 
> > 
> > If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.
> 
> Why do you need another way of testing? As I mentioned above you can
> modify the source code of GRUB and run that modified GRUB in QEMU. I
> don't think we need another way. Were you having problems adding the
> debug message to cryptodisk_read_hook I suggested in my last response?
> I'm starting to think there is an issue in the hook mechanism, but I'd
> like your help in confirming that.
> 
> > 
> > Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Aan: grub-devel@gnu.org
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:47:57 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > 
> > 
> > Debian 11.4 for all the testing.
> 
> Thanks for this info, but that wasn't what I was asking for. I asked
> for the architecture and endianness. For example, are you running on
> x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
> little endian. But you could be running on a MIPS architecture that can
> be either big or little endian. I want this confirmed so I can get the
> full picture. I'm doubting now that this is important, but you never
> know.
> 
> From your response below, I believe that the host and the target are
> the same machine, but are you building GRUB on that machine as well?
> Are you running QEMU for testing on that machine as well?
> 
> I haven't tried to reproduce this issue locally yet due to time
> constraints and it may be a while before I can get to it. But we're
> getting close to the point where it may require me doing that.
> 
> Glenn
> 
> > 
> > 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 <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:24:47 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 01/08/2022 22:50:27 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > Aan: brutser@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;
> > > >    dkiper@net-space.pl;
> > > >    ps@pks.im
> > > > 
> > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > > brutser@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
> > _______________________________________________
> > 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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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

Debug logs: https://imgur.com/a/onRBSMd



New comments below.

See comments below.


Van: Glenn Washburn <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 03/08/2022 21:54:14 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@pks.im

On Tue, 2 Aug 2022 22:49:27 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> 
> Van: Glenn Washburn <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 20:58:17 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> Hi Bruster,
> 
> Are you able to add your responses inline like I have been doing in my
> replies? And not top-post, which is posting at the top.
> 
> I will reply here, though my mail client is not really doing a great job to get this inline response done, sorry for that.

Ok, I figured that. However, you've not responded to much of my
comments that I wrote inline. Perhaps you only read the first part of
my response and do not realize that I wrote more response further down.
Please look at the full email until you see my name, which indicates
that I am finished responding. Please respond to all of my questions,
otherwise it makes it difficult to help you and if you don't take the
time to respond to me fully I am less inclined to help. I would like to
get this issue sorted out, but I need you to help me debug it right now.

Also, I have never built GRUB with coreboot, so I don't have a way to
precisely reproduce your setup anyway. And it currently does work for
me.

Glenn

>>> Comments:
I think I read all your comments and tried to reply as best as possible.

I tried the following test to eliminate the coreboot issue >>

Qemu installation:

1. Minimal Debian 11.4 installation on /dev/sda1
2. git clone latest grub, make & make install, grub-install
3. Reboot Debian iso >
    Expert install Debian 11.4
    Exit to Shell >
    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 100%FREE -n root testvg
4. Complete minimal debian 11.4 installation on encrypted lvm
5. Save header to /dev/sda1
6. Copy header file to target initramfs, populate crypttab, some scripts to finish the encryption

7. Finish installation and reboot.
8. Exit to Grub cmd >
    insmod luks2
    insmod lvm
    insmod cryptodisk
    cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)

result: error: no cryptodisk module can handle this device.

>>> New comments:

Getting closer to a solution here, I was just playing around with it and suddenly I was asked passphrase when entering this line:
cryptomount -H (hd0,msdos1)/header.bin (hd0)

or when I tried this in the coreboot setup, I changed to: cryptomount -H (ahci0,msdos1)/header.bin (ahci0)

wrong passphrase and I get the correct error and correct passphrase and I get Slot "0" opened and "ls /" is showing me: (crypto0)

though it can't handle the logical volume and a simple "ls (crypto0)/" will give error: unknown filesystem.

But why does it accept (hd0), while we clearly encrypted the 2nd partition /dev/sda2 (hd0,msdos2) ?

Anyway, hope this helps.



> 
> Let me be clear on my testing environment, I was purely testing latest grub as payload for coreboot, so even on qemu, I am using coreboot for BIOS with my compiled grub as one of the payloads.
> I am testing on a basic Thinkpad laptop with x86_64 architecture.
> 
> "I'm not sure I understand why you're saying this.", I was basically just expressing that I was testing the functionality purely for my own setup, so if you wanted me to test more general (for example without coreboot), then you could say me.
> Not that it shouldn't work with coreboot obviously, but if other testing could give more accurate results and debug logs for example, I am willing to do that, that was all.
> 
> On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> 
> > 
> > 
> > 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.
> 
> I'm not sure I understand why you're saying this. Did I ask you to do
> something that you think you can't do because your "testing is very
> limited"? You've proven capable of modifying the source code to add
> debug log messages and successfully reproducing the issue in QEMU. That
> makes your testing ability not very limited in my opinion. What am I
> missing that you're wanting to convey here?
> 
> Since you've reproduced the issue in QEMU and I'm assuming that you're
> not running coreboot in QEMU, then I conclude that coreboot is not a
> relevant factor here. What exactly was the QEMU commandline you used in
> getting the output you previously created? Did you ever try to get the
> serial output with the QEMU options I suggested previously?
> 
> > 
> > If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.
> 
> Why do you need another way of testing? As I mentioned above you can
> modify the source code of GRUB and run that modified GRUB in QEMU. I
> don't think we need another way. Were you having problems adding the
> debug message to cryptodisk_read_hook I suggested in my last response?
> I'm starting to think there is an issue in the hook mechanism, but I'd
> like your help in confirming that.
> 
> > 
> > Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Aan: grub-devel@gnu.org
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:47:57 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > 
> > 
> > Debian 11.4 for all the testing.
> 
> Thanks for this info, but that wasn't what I was asking for. I asked
> for the architecture and endianness. For example, are you running on
> x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
> little endian. But you could be running on a MIPS architecture that can
> be either big or little endian. I want this confirmed so I can get the
> full picture. I'm doubting now that this is important, but you never
> know.
> 
> From your response below, I believe that the host and the target are
> the same machine, but are you building GRUB on that machine as well?
> Are you running QEMU for testing on that machine as well?
> 
> I haven't tried to reproduce this issue locally yet due to time
> constraints and it may be a while before I can get to it. But we're
> getting close to the point where it may require me doing that.
> 
> Glenn
> 
> > 
> > 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 <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:24:47 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 01/08/2022 22:50:27 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > Aan: brutser@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;
> > > >    dkiper@net-space.pl;
> > > >    ps@pks.im
> > > > 
> > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > > brutser@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
> > _______________________________________________
> > 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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[brutser]

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

More testing done:

the problem most likely is triggered when encrypting partitions (see all my other comments to get a better picture).

I tested encrypting a complete device /dev/sdb with detached header and this worked fine, no issues, with logical volumes created.



So the problem now is consistent, coreboot, or no coreboot, when encrypting a partition, in my tests /dev/sda2, with a detached header, you cannot decrypt successfully using cryptomount.



cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)

will ALWAYS result in the error: 



"no cryptodisk module can handle this device"



Strange is that it seems to be possible to ignore the partition and simply try to 'decrypt the device', which should not be possible of course, but it validates the passphrase (as seen below in comments), but

although it opens a crypto0 slot, this is not usable decrypted data.







Debug logs: https://imgur.com/a/onRBSMd



New comments below.

See comments below.


Van: Glenn Washburn <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 03/08/2022 21:54:14 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@pks.im

On Tue, 2 Aug 2022 22:49:27 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> 
> Van: Glenn Washburn <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 02/08/2022 20:58:17 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> Hi Bruster,
> 
> Are you able to add your responses inline like I have been doing in my
> replies? And not top-post, which is posting at the top.
> 
> I will reply here, though my mail client is not really doing a great job to get this inline response done, sorry for that.

Ok, I figured that. However, you've not responded to much of my
comments that I wrote inline. Perhaps you only read the first part of
my response and do not realize that I wrote more response further down.
Please look at the full email until you see my name, which indicates
that I am finished responding. Please respond to all of my questions,
otherwise it makes it difficult to help you and if you don't take the
time to respond to me fully I am less inclined to help. I would like to
get this issue sorted out, but I need you to help me debug it right now.

Also, I have never built GRUB with coreboot, so I don't have a way to
precisely reproduce your setup anyway. And it currently does work for
me.

Glenn

>>> Comments:
I think I read all your comments and tried to reply as best as possible.

I tried the following test to eliminate the coreboot issue >>

Qemu installation:

1. Minimal Debian 11.4 installation on /dev/sda1
2. git clone latest grub, make & make install, grub-install
3. Reboot Debian iso >
    Expert install Debian 11.4
    Exit to Shell >
    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 100%FREE -n root testvg
4. Complete minimal debian 11.4 installation on encrypted lvm
5. Save header to /dev/sda1
6. Copy header file to target initramfs, populate crypttab, some scripts to finish the encryption

7. Finish installation and reboot.
8. Exit to Grub cmd >
    insmod luks2
    insmod lvm
    insmod cryptodisk
    cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)

result: error: no cryptodisk module can handle this device.

>>> New comments:

Getting closer to a solution here, I was just playing around with it and suddenly I was asked passphrase when entering this line:
cryptomount -H (hd0,msdos1)/header.bin (hd0)

or when I tried this in the coreboot setup, I changed to: cryptomount -H (ahci0,msdos1)/header.bin (ahci0)

wrong passphrase and I get the correct error and correct passphrase and I get Slot "0" opened and "ls /" is showing me: (crypto0)

though it can't handle the logical volume and a simple "ls (crypto0)/" will give error: unknown filesystem.

But why does it accept (hd0), while we clearly encrypted the 2nd partition /dev/sda2 (hd0,msdos2) ?

Anyway, hope this helps.



> 
> Let me be clear on my testing environment, I was purely testing latest grub as payload for coreboot, so even on qemu, I am using coreboot for BIOS with my compiled grub as one of the payloads.
> I am testing on a basic Thinkpad laptop with x86_64 architecture.
> 
> "I'm not sure I understand why you're saying this.", I was basically just expressing that I was testing the functionality purely for my own setup, so if you wanted me to test more general (for example without coreboot), then you could say me.
> Not that it shouldn't work with coreboot obviously, but if other testing could give more accurate results and debug logs for example, I am willing to do that, that was all.
> 
> On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> 
> > 
> > 
> > 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.
> 
> I'm not sure I understand why you're saying this. Did I ask you to do
> something that you think you can't do because your "testing is very
> limited"? You've proven capable of modifying the source code to add
> debug log messages and successfully reproducing the issue in QEMU. That
> makes your testing ability not very limited in my opinion. What am I
> missing that you're wanting to convey here?
> 
> Since you've reproduced the issue in QEMU and I'm assuming that you're
> not running coreboot in QEMU, then I conclude that coreboot is not a
> relevant factor here. What exactly was the QEMU commandline you used in
> getting the output you previously created? Did you ever try to get the
> serial output with the QEMU options I suggested previously?
> 
> > 
> > If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.
> 
> Why do you need another way of testing? As I mentioned above you can
> modify the source code of GRUB and run that modified GRUB in QEMU. I
> don't think we need another way. Were you having problems adding the
> debug message to cryptodisk_read_hook I suggested in my last response?
> I'm starting to think there is an issue in the hook mechanism, but I'd
> like your help in confirming that.
> 
> > 
> > Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Aan: grub-devel@gnu.org
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:47:57 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > 
> > 
> > Debian 11.4 for all the testing.
> 
> Thanks for this info, but that wasn't what I was asking for. I asked
> for the architecture and endianness. For example, are you running on
> x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
> little endian. But you could be running on a MIPS architecture that can
> be either big or little endian. I want this confirmed so I can get the
> full picture. I'm doubting now that this is important, but you never
> know.
> 
> From your response below, I believe that the host and the target are
> the same machine, but are you building GRUB on that machine as well?
> Are you running QEMU for testing on that machine as well?
> 
> I haven't tried to reproduce this issue locally yet due to time
> constraints and it may be a while before I can get to it. But we're
> getting close to the point where it may require me doing that.
> 
> Glenn
> 
> > 
> > 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 <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 01:24:47 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 01/08/2022 22:50:27 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > Aan: brutser@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;
> > > >    dkiper@net-space.pl;
> > > >    ps@pks.im
> > > > 
> > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > > brutser@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
> > _______________________________________________
> > 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


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[Glenn Washburn]

On Thu,  4 Aug 2022 18:56:40 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> More testing done:
> 
> the problem most likely is triggered when encrypting partitions (see all my other comments to get a better picture).
> 
> I tested encrypting a complete device /dev/sdb with detached header and this worked fine, no issues, with logical volumes created.

Ok, this is progress. It looks like there may be an issue with using
partitions. I haven't tested that.

> 
> 
> 
> So the problem now is consistent, coreboot, or no coreboot, when encrypting a partition, in my tests /dev/sda2, with a detached header, you cannot decrypt successfully using cryptomount.
> 
> 
> 
> cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)

What if you do this instead:

  insmod loopback
  loopback loop (hd0,msdos2)+
  cryptomount -H (hd0,msdos1)/header.bin (loop)

Does this give the same error?

> 
> will ALWAYS result in the error: 
> 
> 
> 
> "no cryptodisk module can handle this device"
> 
> 
> 
> Strange is that it seems to be possible to ignore the partition and simply try to 'decrypt the device', which should not be possible of course, but it validates the passphrase (as seen below in comments), but
> 
> although it opens a crypto0 slot, this is not usable decrypted data.

This is expected behavior. As long as you enter a correct password or
use a keyfile that is valid for one of the key slots in the detached
header, then it doesn't matter what disk device you give to
cryptomount, it will always be decrypted "successfully". But it will
not be usable unless it is the right block device.

You still never answered my question about what exact QEMU commandline
options you were using, nor if you'd tried to use the options I
suggested for getting the serial output as text. Also, you never put in
the debug log message for the read hook in cryptodisk like I asked.

Glenn

> 
> 
> 
> 
> 
> 
> 
> Debug logs: https://imgur.com/a/onRBSMd
> 
> 
> 
> New comments below.
> 
> See comments below.
> 
> 
> Van: Glenn Washburn <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 03/08/2022 21:54:14 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Tue, 2 Aug 2022 22:49:27 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> 
> > 
> > Van: Glenn Washburn <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 20:58:17 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > Hi Bruster,
> > 
> > Are you able to add your responses inline like I have been doing in my
> > replies? And not top-post, which is posting at the top.
> > 
> > I will reply here, though my mail client is not really doing a great job to get this inline response done, sorry for that.
> 
> Ok, I figured that. However, you've not responded to much of my
> comments that I wrote inline. Perhaps you only read the first part of
> my response and do not realize that I wrote more response further down.
> Please look at the full email until you see my name, which indicates
> that I am finished responding. Please respond to all of my questions,
> otherwise it makes it difficult to help you and if you don't take the
> time to respond to me fully I am less inclined to help. I would like to
> get this issue sorted out, but I need you to help me debug it right now.
> 
> Also, I have never built GRUB with coreboot, so I don't have a way to
> precisely reproduce your setup anyway. And it currently does work for
> me.
> 
> Glenn
> 
> >>> Comments:
> I think I read all your comments and tried to reply as best as possible.
> 
> I tried the following test to eliminate the coreboot issue >>
> 
> Qemu installation:
> 
> 1. Minimal Debian 11.4 installation on /dev/sda1
> 2. git clone latest grub, make & make install, grub-install
> 3. Reboot Debian iso >
>     Expert install Debian 11.4
>     Exit to Shell >
>     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 100%FREE -n root testvg
> 4. Complete minimal debian 11.4 installation on encrypted lvm
> 5. Save header to /dev/sda1
> 6. Copy header file to target initramfs, populate crypttab, some scripts to finish the encryption
> 
> 7. Finish installation and reboot.
> 8. Exit to Grub cmd >
>     insmod luks2
>     insmod lvm
>     insmod cryptodisk
>     cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)
> 
> result: error: no cryptodisk module can handle this device.
> 
> >>> New comments:
> 
> Getting closer to a solution here, I was just playing around with it and suddenly I was asked passphrase when entering this line:
> cryptomount -H (hd0,msdos1)/header.bin (hd0)
> 
> or when I tried this in the coreboot setup, I changed to: cryptomount -H (ahci0,msdos1)/header.bin (ahci0)
> 
> wrong passphrase and I get the correct error and correct passphrase and I get Slot "0" opened and "ls /" is showing me: (crypto0)
> 
> though it can't handle the logical volume and a simple "ls (crypto0)/" will give error: unknown filesystem.
> 
> But why does it accept (hd0), while we clearly encrypted the 2nd partition /dev/sda2 (hd0,msdos2) ?
> 
> Anyway, hope this helps.
> 
> 
> 
> > 
> > Let me be clear on my testing environment, I was purely testing latest grub as payload for coreboot, so even on qemu, I am using coreboot for BIOS with my compiled grub as one of the payloads.
> > I am testing on a basic Thinkpad laptop with x86_64 architecture.
> > 
> > "I'm not sure I understand why you're saying this.", I was basically just expressing that I was testing the functionality purely for my own setup, so if you wanted me to test more general (for example without coreboot), then you could say me.
> > Not that it shouldn't work with coreboot obviously, but if other testing could give more accurate results and debug logs for example, I am willing to do that, that was all.
> > 
> > On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> > 
> > > 
> > > 
> > > 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.
> > 
> > I'm not sure I understand why you're saying this. Did I ask you to do
> > something that you think you can't do because your "testing is very
> > limited"? You've proven capable of modifying the source code to add
> > debug log messages and successfully reproducing the issue in QEMU. That
> > makes your testing ability not very limited in my opinion. What am I
> > missing that you're wanting to convey here?
> > 
> > Since you've reproduced the issue in QEMU and I'm assuming that you're
> > not running coreboot in QEMU, then I conclude that coreboot is not a
> > relevant factor here. What exactly was the QEMU commandline you used in
> > getting the output you previously created? Did you ever try to get the
> > serial output with the QEMU options I suggested previously?
> > 
> > > 
> > > If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.
> > 
> > Why do you need another way of testing? As I mentioned above you can
> > modify the source code of GRUB and run that modified GRUB in QEMU. I
> > don't think we need another way. Were you having problems adding the
> > debug message to cryptodisk_read_hook I suggested in my last response?
> > I'm starting to think there is an issue in the hook mechanism, but I'd
> > like your help in confirming that.
> > 
> > > 
> > > Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Aan: grub-devel@gnu.org
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 02/08/2022 01:47:57 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > 
> > > 
> > > Debian 11.4 for all the testing.
> > 
> > Thanks for this info, but that wasn't what I was asking for. I asked
> > for the architecture and endianness. For example, are you running on
> > x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
> > little endian. But you could be running on a MIPS architecture that can
> > be either big or little endian. I want this confirmed so I can get the
> > full picture. I'm doubting now that this is important, but you never
> > know.
> > 
> > From your response below, I believe that the host and the target are
> > the same machine, but are you building GRUB on that machine as well?
> > Are you running QEMU for testing on that machine as well?
> > 
> > I haven't tried to reproduce this issue locally yet due to time
> > constraints and it may be a while before I can get to it. But we're
> > getting close to the point where it may require me doing that.
> > 
> > Glenn
> > 
> > > 
> > > 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 <development@efficientek.com>
> > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 02/08/2022 01:24:47 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > > Datum: 01/08/2022 22:50:27 Europe/Paris
> > > > Cc: brutser@perso.be;
> > > >    dkiper@net-space.pl;
> > > >    ps@pks.im
> > > > 
> > > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > > Aan: brutser@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;
> > > > >    dkiper@net-space.pl;
> > > > >    ps@pks.im
> > > > > 
> > > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > > > brutser@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
> > > _______________________________________________
> > > 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

[brutser]

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

See below.


Van: Glenn Washburn <development@efficientek.com>
Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
Datum: 05/08/2022 07:00:51 Europe/Paris
Cc: brutser@perso.be;
   dkiper@net-space.pl;
   ps@pks.im

On Thu, 4 Aug 2022 18:56:40 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> More testing done:
> 
> the problem most likely is triggered when encrypting partitions (see all my other comments to get a better picture).
> 
> I tested encrypting a complete device /dev/sdb with detached header and this worked fine, no issues, with logical volumes created.

Ok, this is progress. It looks like there may be an issue with using
partitions. I haven't tested that.

> 
> 
> 
> So the problem now is consistent, coreboot, or no coreboot, when encrypting a partition, in my tests /dev/sda2, with a detached header, you cannot decrypt successfully using cryptomount.
> 
> 
> 
> cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)

What if you do this instead:

insmod loopback
loopback loop (hd0,msdos2)+
cryptomount -H (hd0,msdos1)/header.bin (loop)

Does this give the same error?

No, this will work normal, ask the passphrase and decrypt the partition!

But when setting linux kernel, this error appears:
attempt to read or write outside of disk 'crypto0'

> 
> will ALWAYS result in the error: 
> 
> 
> 
> "no cryptodisk module can handle this device"
> 
> 
> 
> Strange is that it seems to be possible to ignore the partition and simply try to 'decrypt the device', which should not be possible of course, but it validates the passphrase (as seen below in comments), but
> 
> although it opens a crypto0 slot, this is not usable decrypted data.

This is expected behavior. As long as you enter a correct password or
use a keyfile that is valid for one of the key slots in the detached
header, then it doesn't matter what disk device you give to
cryptomount, it will always be decrypted "successfully". But it will
not be usable unless it is the right block device.

>>> Ok makes sense.

You still never answered my question about what exact QEMU commandline
options you were using

>>> sudo qemu-system-x86_64 -serial stdio -drive file=~/disk2.img,format=raw,index=0,media=disk -m 3840 -boot d -M q35 --accel kvm

, nor if you'd tried to use the options I
suggested for getting the serial output as text. 

>>> yes I tried, but I still had no idea how to get the output and since there was a little progress, I didn't want to spend too much time on it:
qemu-system-x86_64: -fw_cfg name=etc/sercon-port,string=0: warning: externally provided fw_cfg item names should be prefixed with "opt/"
but i guess it makes it much easier if I can copy the debug logs, so maybe we should make this work, can you explain how i can get the logs more detailed?

Also, you never put in
the debug log message for the read hook in cryptodisk like I asked.

>>> yes, I somehow did not read that part, so I will do that right now.

Glenn

> 
> 
> 
> 
> 
> 
> 
> Debug logs: https://imgur.com/a/onRBSMd
> 
> 
> 
> New comments below.
> 
> See comments below.
> 
> 
> Van: Glenn Washburn <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 03/08/2022 21:54:14 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Tue, 2 Aug 2022 22:49:27 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> 
> > 
> > Van: Glenn Washburn <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 02/08/2022 20:58:17 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > Hi Bruster,
> > 
> > Are you able to add your responses inline like I have been doing in my
> > replies? And not top-post, which is posting at the top.
> > 
> > I will reply here, though my mail client is not really doing a great job to get this inline response done, sorry for that.
> 
> Ok, I figured that. However, you've not responded to much of my
> comments that I wrote inline. Perhaps you only read the first part of
> my response and do not realize that I wrote more response further down.
> Please look at the full email until you see my name, which indicates
> that I am finished responding. Please respond to all of my questions,
> otherwise it makes it difficult to help you and if you don't take the
> time to respond to me fully I am less inclined to help. I would like to
> get this issue sorted out, but I need you to help me debug it right now.
> 
> Also, I have never built GRUB with coreboot, so I don't have a way to
> precisely reproduce your setup anyway. And it currently does work for
> me.
> 
> Glenn
> 
> >>> Comments:
> I think I read all your comments and tried to reply as best as possible.
> 
> I tried the following test to eliminate the coreboot issue >>
> 
> Qemu installation:
> 
> 1. Minimal Debian 11.4 installation on /dev/sda1
> 2. git clone latest grub, make & make install, grub-install
> 3. Reboot Debian iso >
>     Expert install Debian 11.4
>     Exit to Shell >
>     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 100%FREE -n root testvg
> 4. Complete minimal debian 11.4 installation on encrypted lvm
> 5. Save header to /dev/sda1
> 6. Copy header file to target initramfs, populate crypttab, some scripts to finish the encryption
> 
> 7. Finish installation and reboot.
> 8. Exit to Grub cmd >
>     insmod luks2
>     insmod lvm
>     insmod cryptodisk
>     cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)
> 
> result: error: no cryptodisk module can handle this device.
> 
> >>> New comments:
> 
> Getting closer to a solution here, I was just playing around with it and suddenly I was asked passphrase when entering this line:
> cryptomount -H (hd0,msdos1)/header.bin (hd0)
> 
> or when I tried this in the coreboot setup, I changed to: cryptomount -H (ahci0,msdos1)/header.bin (ahci0)
> 
> wrong passphrase and I get the correct error and correct passphrase and I get Slot "0" opened and "ls /" is showing me: (crypto0)
> 
> though it can't handle the logical volume and a simple "ls (crypto0)/" will give error: unknown filesystem.
> 
> But why does it accept (hd0), while we clearly encrypted the 2nd partition /dev/sda2 (hd0,msdos2) ?
> 
> Anyway, hope this helps.
> 
> 
> 
> > 
> > Let me be clear on my testing environment, I was purely testing latest grub as payload for coreboot, so even on qemu, I am using coreboot for BIOS with my compiled grub as one of the payloads.
> > I am testing on a basic Thinkpad laptop with x86_64 architecture.
> > 
> > "I'm not sure I understand why you're saying this.", I was basically just expressing that I was testing the functionality purely for my own setup, so if you wanted me to test more general (for example without coreboot), then you could say me.
> > Not that it shouldn't work with coreboot obviously, but if other testing could give more accurate results and debug logs for example, I am willing to do that, that was all.
> > 
> > On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> > 
> > > 
> > > 
> > > 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.
> > 
> > I'm not sure I understand why you're saying this. Did I ask you to do
> > something that you think you can't do because your "testing is very
> > limited"? You've proven capable of modifying the source code to add
> > debug log messages and successfully reproducing the issue in QEMU. That
> > makes your testing ability not very limited in my opinion. What am I
> > missing that you're wanting to convey here?
> > 
> > Since you've reproduced the issue in QEMU and I'm assuming that you're
> > not running coreboot in QEMU, then I conclude that coreboot is not a
> > relevant factor here. What exactly was the QEMU commandline you used in
> > getting the output you previously created? Did you ever try to get the
> > serial output with the QEMU options I suggested previously?
> > 
> > > 
> > > If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.
> > 
> > Why do you need another way of testing? As I mentioned above you can
> > modify the source code of GRUB and run that modified GRUB in QEMU. I
> > don't think we need another way. Were you having problems adding the
> > debug message to cryptodisk_read_hook I suggested in my last response?
> > I'm starting to think there is an issue in the hook mechanism, but I'd
> > like your help in confirming that.
> > 
> > > 
> > > Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Aan: grub-devel@gnu.org
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 02/08/2022 01:47:57 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > 
> > > 
> > > Debian 11.4 for all the testing.
> > 
> > Thanks for this info, but that wasn't what I was asking for. I asked
> > for the architecture and endianness. For example, are you running on
> > x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
> > little endian. But you could be running on a MIPS architecture that can
> > be either big or little endian. I want this confirmed so I can get the
> > full picture. I'm doubting now that this is important, but you never
> > know.
> > 
> > From your response below, I believe that the host and the target are
> > the same machine, but are you building GRUB on that machine as well?
> > Are you running QEMU for testing on that machine as well?
> > 
> > I haven't tried to reproduce this issue locally yet due to time
> > constraints and it may be a while before I can get to it. But we're
> > getting close to the point where it may require me doing that.
> > 
> > Glenn
> > 
> > > 
> > > 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 <development@efficientek.com>
> > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 02/08/2022 01:24:47 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > > Datum: 01/08/2022 22:50:27 Europe/Paris
> > > > Cc: brutser@perso.be;
> > > >    dkiper@net-space.pl;
> > > >    ps@pks.im
> > > > 
> > > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > > Aan: brutser@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;
> > > > >    dkiper@net-space.pl;
> > > > >    ps@pks.im
> > > > > 
> > > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > > > brutser@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
> > > _______________________________________________
> > > 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
> 

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


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

Re: [PATCH v3 0/3] Cryptomount detached headers

[Glenn Washburn]

On Fri,  5 Aug 2022 11:43:51 +0200 (CEST)
brutser--- via Grub-devel <grub-devel@gnu.org> wrote:

> See below.
> 
> 
> Van: Glenn Washburn <development@efficientek.com>
> Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> Datum: 05/08/2022 07:00:51 Europe/Paris
> Cc: brutser@perso.be;
>    dkiper@net-space.pl;
>    ps@pks.im
> 
> On Thu, 4 Aug 2022 18:56:40 +0200 (CEST)
> brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> 
> > More testing done:
> > 
> > the problem most likely is triggered when encrypting partitions (see all my other comments to get a better picture).
> > 
> > I tested encrypting a complete device /dev/sdb with detached header and this worked fine, no issues, with logical volumes created.
> 
> Ok, this is progress. It looks like there may be an issue with using
> partitions. I haven't tested that.

I now see where the issue is. Because the encrypted volume is on a
partition, the reads to the disk device which contains the partition
are offset into the disk by the partition start position. This
adjustment to account for the partition is done in the grub_disk_read()
before the read hook gets called. So the read hook gets called with the
offsets already adjusted. Then the read hook will read into the header
file at the offset adjusted for the partition, but the header file is
at the beginning of the file, not at the offset of the partition.

So what needs to be done in the read hook is to, only if the disk is on
a partition, unadjust the offset so that we are reading into the header
file as if it were at the beginning of the disk. This will need to
account for the encrypted volume being nested in many partitions.

> 
> > 
> > 
> > 
> > So the problem now is consistent, coreboot, or no coreboot, when encrypting a partition, in my tests /dev/sda2, with a detached header, you cannot decrypt successfully using cryptomount.
> > 
> > 
> > 
> > cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)
> 
> What if you do this instead:
> 
> insmod loopback
> loopback loop (hd0,msdos2)+
> cryptomount -H (hd0,msdos1)/header.bin (loop)
> 
> Does this give the same error?
> 
> No, this will work normal, ask the passphrase and decrypt the partition!
> 
> But when setting linux kernel, this error appears:
> attempt to read or write outside of disk 'crypto0'

Interesting, this might be a different bug.

> 
> > 
> > will ALWAYS result in the error: 
> > 
> > 
> > 
> > "no cryptodisk module can handle this device"
> > 
> > 
> > 
> > Strange is that it seems to be possible to ignore the partition and simply try to 'decrypt the device', which should not be possible of course, but it validates the passphrase (as seen below in comments), but
> > 
> > although it opens a crypto0 slot, this is not usable decrypted data.
> 
> This is expected behavior. As long as you enter a correct password or
> use a keyfile that is valid for one of the key slots in the detached
> header, then it doesn't matter what disk device you give to
> cryptomount, it will always be decrypted "successfully". But it will
> not be usable unless it is the right block device.
> 
> >>> Ok makes sense.
> 
> You still never answered my question about what exact QEMU commandline
> options you were using
> 
> >>> sudo qemu-system-x86_64 -serial stdio -drive file=~/disk2.img,format=raw,index=0,media=disk -m 3840 -boot d -M q35 --accel kvm

Actually, for future reference, you should be able to run the grub-shell
script in the build directory like so:

cat >>EOF | ./grub-shell --disk disk2.img
insmod luks2
insmod lvm
insmod cryptodisk
cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)
EOF

If this works, you can then run with shell tracing on to see the exact
QEMU commandline its using.

> 
> , nor if you'd tried to use the options I
> suggested for getting the serial output as text. 
> 
> >>> yes I tried, but I still had no idea how to get the output and since there was a little progress, I didn't want to spend too much time on it:
> qemu-system-x86_64: -fw_cfg name=etc/sercon-port,string=0: warning: externally provided fw_cfg item names should be prefixed with "opt/"

This is an expected warning and can be ignored.

> but i guess it makes it much easier if I can copy the debug logs, so maybe we should make this work, can you explain how i can get the logs more detailed?

Are you getting any output to the console or just that warning?

Glenn

> 
> Also, you never put in
> the debug log message for the read hook in cryptodisk like I asked.
> 
> >>> yes, I somehow did not read that part, so I will do that right now.
> 
> Glenn
> 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Debug logs: https://imgur.com/a/onRBSMd
> > 
> > 
> > 
> > New comments below.
> > 
> > See comments below.
> > 
> > 
> > Van: Glenn Washburn <development@efficientek.com>
> > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > Datum: 03/08/2022 21:54:14 Europe/Paris
> > Cc: brutser@perso.be;
> >    dkiper@net-space.pl;
> >    ps@pks.im
> > 
> > On Tue, 2 Aug 2022 22:49:27 +0200 (CEST)
> > brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> > 
> > > 
> > > Van: Glenn Washburn <development@efficientek.com>
> > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > Datum: 02/08/2022 20:58:17 Europe/Paris
> > > Cc: brutser@perso.be;
> > >    dkiper@net-space.pl;
> > >    ps@pks.im
> > > 
> > > Hi Bruster,
> > > 
> > > Are you able to add your responses inline like I have been doing in my
> > > replies? And not top-post, which is posting at the top.
> > > 
> > > I will reply here, though my mail client is not really doing a great job to get this inline response done, sorry for that.
> > 
> > Ok, I figured that. However, you've not responded to much of my
> > comments that I wrote inline. Perhaps you only read the first part of
> > my response and do not realize that I wrote more response further down.
> > Please look at the full email until you see my name, which indicates
> > that I am finished responding. Please respond to all of my questions,
> > otherwise it makes it difficult to help you and if you don't take the
> > time to respond to me fully I am less inclined to help. I would like to
> > get this issue sorted out, but I need you to help me debug it right now.
> > 
> > Also, I have never built GRUB with coreboot, so I don't have a way to
> > precisely reproduce your setup anyway. And it currently does work for
> > me.
> > 
> > Glenn
> > 
> > >>> Comments:
> > I think I read all your comments and tried to reply as best as possible.
> > 
> > I tried the following test to eliminate the coreboot issue >>
> > 
> > Qemu installation:
> > 
> > 1. Minimal Debian 11.4 installation on /dev/sda1
> > 2. git clone latest grub, make & make install, grub-install
> > 3. Reboot Debian iso >
> >     Expert install Debian 11.4
> >     Exit to Shell >
> >     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 100%FREE -n root testvg
> > 4. Complete minimal debian 11.4 installation on encrypted lvm
> > 5. Save header to /dev/sda1
> > 6. Copy header file to target initramfs, populate crypttab, some scripts to finish the encryption
> > 
> > 7. Finish installation and reboot.
> > 8. Exit to Grub cmd >
> >     insmod luks2
> >     insmod lvm
> >     insmod cryptodisk
> >     cryptomount -H (hd0,msdos1)/header.bin (hd0,msdos2)
> > 
> > result: error: no cryptodisk module can handle this device.
> > 
> > >>> New comments:
> > 
> > Getting closer to a solution here, I was just playing around with it and suddenly I was asked passphrase when entering this line:
> > cryptomount -H (hd0,msdos1)/header.bin (hd0)
> > 
> > or when I tried this in the coreboot setup, I changed to: cryptomount -H (ahci0,msdos1)/header.bin (ahci0)
> > 
> > wrong passphrase and I get the correct error and correct passphrase and I get Slot "0" opened and "ls /" is showing me: (crypto0)
> > 
> > though it can't handle the logical volume and a simple "ls (crypto0)/" will give error: unknown filesystem.
> > 
> > But why does it accept (hd0), while we clearly encrypted the 2nd partition /dev/sda2 (hd0,msdos2) ?
> > 
> > Anyway, hope this helps.
> > 
> > 
> > 
> > > 
> > > Let me be clear on my testing environment, I was purely testing latest grub as payload for coreboot, so even on qemu, I am using coreboot for BIOS with my compiled grub as one of the payloads.
> > > I am testing on a basic Thinkpad laptop with x86_64 architecture.
> > > 
> > > "I'm not sure I understand why you're saying this.", I was basically just expressing that I was testing the functionality purely for my own setup, so if you wanted me to test more general (for example without coreboot), then you could say me.
> > > Not that it shouldn't work with coreboot obviously, but if other testing could give more accurate results and debug logs for example, I am willing to do that, that was all.
> > > 
> > > On Tue, 2 Aug 2022 02:26:58 +0200 (CEST)
> > > brutser--- via Grub-devel <grub-devel@gnu.org> wrote:
> > > 
> > > > 
> > > > 
> > > > 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.
> > > 
> > > I'm not sure I understand why you're saying this. Did I ask you to do
> > > something that you think you can't do because your "testing is very
> > > limited"? You've proven capable of modifying the source code to add
> > > debug log messages and successfully reproducing the issue in QEMU. That
> > > makes your testing ability not very limited in my opinion. What am I
> > > missing that you're wanting to convey here?
> > > 
> > > Since you've reproduced the issue in QEMU and I'm assuming that you're
> > > not running coreboot in QEMU, then I conclude that coreboot is not a
> > > relevant factor here. What exactly was the QEMU commandline you used in
> > > getting the output you previously created? Did you ever try to get the
> > > serial output with the QEMU options I suggested previously?
> > > 
> > > > 
> > > > If you got suggestions with this setup, how i can do another way of testing, let me know and I will do it.
> > > 
> > > Why do you need another way of testing? As I mentioned above you can
> > > modify the source code of GRUB and run that modified GRUB in QEMU. I
> > > don't think we need another way. Were you having problems adding the
> > > debug message to cryptodisk_read_hook I suggested in my last response?
> > > I'm starting to think there is an issue in the hook mechanism, but I'd
> > > like your help in confirming that.
> > > 
> > > > 
> > > > Van: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > > Aan: grub-devel@gnu.org
> > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > > Datum: 02/08/2022 01:47:57 Europe/Paris
> > > > Cc: brutser@perso.be;
> > > >    dkiper@net-space.pl;
> > > >    ps@pks.im
> > > > 
> > > > 
> > > > 
> > > > Debian 11.4 for all the testing.
> > > 
> > > Thanks for this info, but that wasn't what I was asking for. I asked
> > > for the architecture and endianness. For example, are you running on
> > > x86_64 or i386 (64-bit vs 32-bit) x86 architecture? These are always
> > > little endian. But you could be running on a MIPS architecture that can
> > > be either big or little endian. I want this confirmed so I can get the
> > > full picture. I'm doubting now that this is important, but you never
> > > know.
> > > 
> > > From your response below, I believe that the host and the target are
> > > the same machine, but are you building GRUB on that machine as well?
> > > Are you running QEMU for testing on that machine as well?
> > > 
> > > I haven't tried to reproduce this issue locally yet due to time
> > > constraints and it may be a while before I can get to it. But we're
> > > getting close to the point where it may require me doing that.
> > > 
> > > Glenn
> > > 
> > > > 
> > > > 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 <development@efficientek.com>
> > > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > > Datum: 02/08/2022 01:24:47 Europe/Paris
> > > > Cc: brutser@perso.be;
> > > >    dkiper@net-space.pl;
> > > >    ps@pks.im
> > > > 
> > > > On Tue, 2 Aug 2022 00:21:09 +0200 (CEST)
> > > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > > Aan: brutser--- via Grub-devel <grub-devel@gnu.org>
> > > > > Onderwerp: Re: [PATCH v3 0/3] Cryptomount detached headers
> > > > > Datum: 01/08/2022 22:50:27 Europe/Paris
> > > > > Cc: brutser@perso.be;
> > > > >    dkiper@net-space.pl;
> > > > >    ps@pks.im
> > > > > 
> > > > > On Sat, 30 Jul 2022 11:54:32 +0200 (CEST)
> > > > > brutser--- via Grub-devel <grub-devel@gnu.org> 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 <development@efficientek.com>
> > > > > > Aan: brutser@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;
> > > > > >    dkiper@net-space.pl;
> > > > > >    ps@pks.im
> > > > > > 
> > > > > > On Fri, 29 Jul 2022 20:56:18 +0200 (CEST)
> > > > > > brutser@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
> > > > _______________________________________________
> > > > 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
> > 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>