qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Yong Huang <yong.huang@smartx.com>
Cc: qemu-devel@nongnu.org,  Kevin Wolf <kwolf@redhat.com>,
	 Hanna Reitz <hreitz@redhat.com>,  Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH] qapi: Craft the BlockdevCreateOptionsLUKS comment
Date: Wed, 28 Feb 2024 07:43:51 +0100	[thread overview]
Message-ID: <87v8693x7c.fsf@pond.sub.org> (raw)
In-Reply-To: <CAK9dgmZOEqd=EgBjsiZZoK3R+VQRMqSdUrK_WwKHfP7LiWzQMQ@mail.gmail.com> (Yong Huang's message of "Wed, 21 Feb 2024 16:49:57 +0800")

Yong Huang <yong.huang@smartx.com> writes:

> On Wed, Feb 21, 2024 at 4:26 PM Markus Armbruster <armbru@redhat.com> wrote:
>
>> Yong Huang <yong.huang@smartx.com> writes:
>>
>> > On Wed, Feb 21, 2024 at 2:43 PM Markus Armbruster <armbru@redhat.com>
>> wrote:
>> >
>> >> Hyman Huang <yong.huang@smartx.com> writes:
>> >>
>> >> > Add comment in detail for commit 433957bb7f (qapi:
>> >> > Make parameter 'file' optional for
>> >> > BlockdevCreateOptionsLUKS).
>> >> >
>> >> > Signed-off-by: Hyman Huang <yong.huang@smartx.com>
>> >> > ---
>> >> >  qapi/block-core.json | 20 +++++++++++++++++++-
>> >> >  1 file changed, 19 insertions(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/qapi/block-core.json b/qapi/block-core.json
>> >> > index ab5a93a966..42b0840d43 100644
>> >> > --- a/qapi/block-core.json
>> >> > +++ b/qapi/block-core.json
>> >> > @@ -4973,7 +4973,25 @@
>> >> >  ##
>> >> >  # @BlockdevCreateOptionsLUKS:
>> >> >  #
>> >> > -# Driver specific image creation options for LUKS.
>> >> > +# Driver specific image creation options for LUKS. Note that
>> >> > +# @file is required if @preallocation is specified and equals
>> >> > +# PREALLOC_MODE_ON. The following three scenarios determine how
>> >> > +# creation logic behaves when @preallocation is either equal to
>> >> > +# PREALLOC_MODE_OFF or is not given:
>> >> > +#
>> >> > +#  1) When @file is given only, format the block device referenced
>> >> > +#     by @file as the LUKS specification and trunk it to the @size.
>> >>
>> >> Do you mean "truncate it to @size"?
>> >>
>> > Yes, :( sorry for the spelling mistake.
>>
>> Writing good documentation in a second language is *hard*.  All we can
>> reasonably expect from contributors to try their best.  And then we
>> improve the text together in review.  Just like we do for code :)
>>
>> >> > +#     In this case, the @size should reflect amount of space made
>> >> > +#     available to the guest, so the trunk size must take account
>> >> > +#     of that which will be used by the crypto header.
>> >> > +#
>> >> > +#  2) When @header is given only, just format the block device
>> >> > +#     referenced by @header as the LUKS specification.
>> >> > +#
>> >> > +#  3) When both @file and @header are given, block device
>> >> > +#     referenced by @file should be trunked to @size, and block
>> >> > +#     device referenced by @header should be formatted as the LUKS
>> >> > +#     specification.
>> >> >  #
>> >> >  # @file: Node to create the image format on, mandatory except when
>> >> >  #        'preallocation' is not requested
>> >>
>> >> Let's see whether I understand.
>> >>
>> >> blockdev-create with "driver": "luks" can work in three different ways:
>> >>
>> >> 1. Create an image with a LUKS header
>> >>
>> >> 2. Create just a detached LUKS header
>> >>
>> >> 3. Create an image and a detached LUKS header
>> >>
>> >> Correct?
>> >>
>> >
>> > Yes
>> >
>> >
>> >> @file and @header are BlockdevRef, which means they refer to existing
>> >> images with arbitrary driver.  Could be "file", "qcow2", or anything.
>> >>
>> >> Correct?
>> >>
>> > Yes
>> >
>> >
>> >>
>> >> To get 1., specify @file, but not @header.
>> >>
>> >> To get 2., specify @header, but not @file.
>> >>
>> >> To get 3., specify both.
>> >>
>> >> Specifying neither is an error.
>> >>
>> >> Correct?
>> >>
>> >
>> > Yes
>> >
>> >
>> >> In any case, @size is the logical size of the image (how much data it
>> >> can hold).
>> >>
>> >
>> > Yes
>> >
>> >
>> >>
>> >> With 1., the actual image size is a bit larger due to the LUKS header.
>> >> The @file image is resized to that size: if it's shorter, it's grown, if
>> >> it's longer, it's truncated.
>> >>
>> >
>> > Yes
>> >
>> >
>> >> With 2., @size is merely recorded in the detached LUKS header.
>> >>
>> >
>> > In LUKS1 specification, payload data size is not contained in the header,
>> > so in this case, @size is not recorded in the detached LUKS header.
>> > The creation logic just does the LUKS header formatting only.
>>
>> Is @size unused then?
>>
>
> IIUC, yes. Creation logic will ignore the @size. See the following code
> in function block_crypto_co_create_luks:
>
>     if (luks_opts->header) {
>         /* LUKS volume with detached header */
>         hdr_bs = bdrv_co_open_blockdev_ref(luks_opts->header, errp);
>         if (hdr_bs == NULL) {
>             return -EIO;
>         }
>
>         cflags |= QCRYPTO_BLOCK_CREATE_DETACHED;
>
>         /* Format the LUKS header node, here just ignore the size
>           * and passed zero to block_crypto_co_create_generic */
>         ret = block_crypto_co_create_generic(hdr_bs, 0, &create_opts,
>                                              PREALLOC_MODE_OFF, cflags, errp);
>         if (ret < 0) {
>             goto fail;
>         }
>
>         /* Format the LUKS payload node */
>         if (luks_opts->file) {
>             ret = block_crypto_co_format_luks_payload(luks_opts, errp);
>             if (ret < 0) {
>                 goto fail;
>             }
>         }

@size is a required argument, but silently ignored when @header is
present and @file is absent (2. Create just a detached LUKS header).
Feels awkward.

Should @size be optional, absent when and only when @header is present
and @file is absent?

Kevin or Hanna, got an opinion?

>> >> With 3., @size is recorded in the detached LUKS header, and the @file
>> >> image is resized as with 1.
>> >>
>> >
>> > Same reason as above, @size is not recorded and @file image is
>> > resized to @size exactly.
>> >
>> >
>> >>
>> >> Correct?
>> >>
>> >>
>> > Thanks for the comment,
>> >
>> > Yong
>>
>>



  reply	other threads:[~2024-02-28  6:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-21  3:36 [PATCH] qapi: Craft the BlockdevCreateOptionsLUKS comment Hyman Huang
2024-02-21  6:43 ` Markus Armbruster
2024-02-21  7:08   ` Yong Huang
2024-02-21  8:26     ` Markus Armbruster
2024-02-21  8:49       ` Yong Huang
2024-02-28  6:43         ` Markus Armbruster [this message]
2024-02-28 10:17           ` Kevin Wolf
2024-02-28 10:23             ` Daniel P. Berrangé
2024-02-28 11:21               ` Kevin Wolf
2024-02-28 11:26                 ` Daniel P. Berrangé
2024-02-28 11:30             ` Daniel P. Berrangé
2024-02-28 11:58               ` Kevin Wolf
2024-02-29  2:04                 ` Yong Huang

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=87v8693x7c.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yong.huang@smartx.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).