All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <dkiper@net-space.pl>
To: Glenn Washburn <development@efficientek.com>
Cc: grub-devel@gnu.org,
	Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>,
	Patrick Steinhardt <ps@pks.im>, John Lane <john@lane.uk.net>
Subject: Re: [PATCH v9 5/7] cryptodisk: Add options to cryptomount to support keyfiles
Date: Fri, 29 Apr 2022 15:03:01 +0200	[thread overview]
Message-ID: <20220429130301.clxh2dsothiv43h2@tomti.i.net-space.pl> (raw)
In-Reply-To: <fb33d6810d0e7a7529d3b950e96e2175e31514b1.1649658484.git.development@efficientek.com>

On Mon, Apr 11, 2022 at 06:40:26AM +0000, Glenn Washburn wrote:
> From: John Lane <john@lane.uk.net>
>
> Add the options --key-file, --keyfile-offset, and --keyfile-size to
> cryptomount and code to put read the requested key file data and pass
> via the cargs struct. Note, key file data is for all intents and purposes
> equivalent to a password given to cryptomount. So there is no need to
> enable support for key files in the various crypto backends (eg. LUKS1)
> because the key data is passed just as if it were a password.
>
> Signed-off-by: John Lane <john@lane.uk.net>
> GNUtoo@cyberdimension.org: rebase, patch split, small fixes, commit message
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
> development@efficientek.com: rebase and rework to use cryptomount arg passing,
>   minor fixes, improve commit message
> Signed-off-by: Glenn Washburn <development@efficientek.com>
> ---
>  grub-core/disk/cryptodisk.c | 85 ++++++++++++++++++++++++++++++++++++-
>  include/grub/cryptodisk.h   |  2 +
>  include/grub/file.h         |  2 +
>  3 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/disk/cryptodisk.c b/grub-core/disk/cryptodisk.c
> index 063997d2f0..155cc7f0b4 100644
> --- a/grub-core/disk/cryptodisk.c
> +++ b/grub-core/disk/cryptodisk.c
> @@ -43,6 +43,9 @@ static const struct grub_arg_option options[] =
>      {"boot", 'b', 0, N_("Mount all volumes with `boot' flag set."), 0, 0},
>      {"password", 'p', 0, N_("Password to open volumes."), 0, ARG_TYPE_STRING},
>      {"header", 'H', 0, N_("Read header from file"), 0, ARG_TYPE_STRING},
> +    {"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},
>      {0, 0, 0, 0, 0, 0}
>    };
>
> @@ -1185,6 +1188,84 @@ grub_cmd_cryptomount (grub_extcmd_context_t ctxt, int argc, char **args)
>  	return grub_errno;
>      }
>
> +  if (state[5].set) /* keyfile */
> +    {
> +      const char *p = NULL;
> +      grub_file_t keyfile;
> +      int keyfile_offset;

I think this should be unsigned long if you do grub_strtoul() below.

> +      grub_size_t keyfile_size = 0;

I think this should be unsigned long too.

> +
> +

Please drop this extra line.

> +      if (state[6].set) /* keyfile-offset */
> +	{
> +	  keyfile_offset = grub_strtoul (state[6].arg, &p, 0);

Are you sure you want 0 base?

> +	  if (grub_errno != GRUB_ERR_NONE)
> +	    return grub_errno;
> +
> +	  if (*p != '\0')
> +	    return grub_error (GRUB_ERR_BAD_ARGUMENT,
> +			       N_("unrecognized number"));

This error check is unreliable. Please take a look at the commit
ac8a37dda (net/http: Allow use of non-standard TCP/IP ports) how it
should be done.

> +	}
> +      else
> +	{
> +	  keyfile_offset = 0;
> +	}

Why do not initialize it in definition above? If not please drop {}.

> +      if (state[7].set) /* keyfile-size */
> +	{
> +	  keyfile_size = grub_strtoul (state[7].arg, &p, 0);
> +
> +	  if (*p != '\0')
> +	    return grub_error (GRUB_ERR_BAD_ARGUMENT,
> +			       N_("unrecognized number"));
> +
> +	  if (grub_errno != GRUB_ERR_NONE)
> +	    return grub_errno;

Again, these checks are not reliable...

> +	  if (keyfile_size > GRUB_CRYPTODISK_MAX_KEYFILE_SIZE)
> +	    return grub_error (GRUB_ERR_OUT_OF_RANGE,
> +			       N_("key file size exceeds maximum (%d)"),
> +			       GRUB_CRYPTODISK_MAX_KEYFILE_SIZE);
> +
> +	  if (keyfile_size == 0)
> +	    return grub_error (GRUB_ERR_OUT_OF_RANGE, N_("key file size is 0"));
> +	}
> +
> +      keyfile = grub_file_open (state[5].arg,
> +				GRUB_FILE_TYPE_CRYPTODISK_ENCRYPTION_KEY);
> +      if (keyfile == NULL)

Yeah, I like compare with NULL... :-)

> +	return grub_errno;
> +
> +      if (grub_file_seek (keyfile, keyfile_offset) == (grub_off_t)-1)

Space before -1 please...

> +	return grub_errno;
> +
> +      if (keyfile_size > 0)
> +	{
> +	  if (keyfile_size > (keyfile->size - keyfile_offset))

What if somebody passes keyfile_offset larger than keyfile->size?
I would use grub_sub() here and check for underflow.

> +	    return grub_error (GRUB_ERR_FILE_READ_ERROR,
> +			       N_("keyfile is too small: "
> +				  "requested %" PRIuGRUB_SIZE " bytes, "
> +				  "but the file only has %" PRIuGRUB_UINT64_T
> +				  " bytes"),
> +			       keyfile_size,
> +			       keyfile->size);
> +
> +	  cargs.key_len = keyfile_size;
> +	}
> +      else
> +	{
> +	  cargs.key_len = keyfile->size - keyfile_offset;

grub_sub() again?

> +	}

Please drop {} here...

> +      cargs.key_data = grub_malloc (cargs.key_len);
> +      if (cargs.key_data == NULL)
> +	return GRUB_ERR_OUT_OF_MEMORY;
> +
> +      if (grub_file_read (keyfile, cargs.key_data, cargs.key_len) != (grub_ssize_t) cargs.key_len)
> +	return grub_error (GRUB_ERR_FILE_READ_ERROR, (N_("reading key file")));
> +    }
> +
>    if (state[0].set) /* uuid */
>      {
>        int found_uuid;
> @@ -1397,7 +1478,9 @@ GRUB_MOD_INIT (cryptodisk)
>  {
>    grub_disk_dev_register (&grub_cryptodisk_dev);
>    cmd = grub_register_extcmd ("cryptomount", grub_cmd_cryptomount, 0,
> -			      N_("[-p password] [-H file] <SOURCE|-u UUID|-a|-b>"),
> +			      N_("[ [-p password] | [-k keyfile"
> +				 " [-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/include/grub/cryptodisk.h b/include/grub/cryptodisk.h
> index 9fe451de92..d94df68b65 100644
> --- a/include/grub/cryptodisk.h
> +++ b/include/grub/cryptodisk.h
> @@ -62,6 +62,8 @@ typedef enum
>  #define GRUB_CRYPTODISK_MAX_KEYLEN 128
>  #define GRUB_CRYPTODISK_MAX_PASSPHRASE 256
>
> +#define GRUB_CRYPTODISK_MAX_KEYFILE_SIZE 8192

This constant is not used here. I think it should be used in this patch
to check limits. Probably somewhere around proposed grub_sub(). Than
maybe we do not need grub_sub().

Daniel


  reply	other threads:[~2022-04-29 13:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11  6:40 [PATCH v9 0/7] Cryptodisk detached headers and key files Glenn Washburn
2022-04-11  6:40 ` [PATCH v9 1/7] cryptodisk: luks: Unify grub_cryptodisk_dev function names Glenn Washburn
2022-04-28 12:01   ` Daniel Kiper
2022-04-11  6:40 ` [PATCH v9 2/7] cryptodisk: geli: " Glenn Washburn
2022-04-28 12:02   ` Daniel Kiper
2022-04-11  6:40 ` [PATCH v9 3/7] cryptodisk: Add --header option to cryptomount and fail to implement it in the backends Glenn Washburn
2022-04-28 12:39   ` Daniel Kiper
2022-04-11  6:40 ` [PATCH v9 4/7] cryptodisk: Add support for LUKS1 detached headers Glenn Washburn
2022-04-28 12:46   ` Daniel Kiper
2022-04-11  6:40 ` [PATCH v9 5/7] cryptodisk: Add options to cryptomount to support keyfiles Glenn Washburn
2022-04-29 13:03   ` Daniel Kiper [this message]
2022-05-05 23:03     ` Glenn Washburn
2022-04-11  6:40 ` [PATCH v9 6/7] luks2: Add detached header support Glenn Washburn
2022-04-29 13:12   ` Daniel Kiper
2022-04-11  6:40 ` [PATCH v9 7/7] docs: Add documentation on keyfile and detached header options to cryptomount Glenn Washburn
2022-04-29 13:15   ` Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220429130301.clxh2dsothiv43h2@tomti.i.net-space.pl \
    --to=dkiper@net-space.pl \
    --cc=GNUtoo@cyberdimension.org \
    --cc=development@efficientek.com \
    --cc=grub-devel@gnu.org \
    --cc=john@lane.uk.net \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.