[systemd-devel] systemd-repart HOWTO + demo code

[Thayne Harbaugh]

Response in line:

On Sat, 2024-10-19 at 20:36 -0400, Adrian Vovk wrote:
> Hello,
> I might have spotted something 

Thank you for reviewing my long email.

> You tell repart to encrypt with a keyfile, but it seems like you
> don't pass in which keyfile to use.

Maybe I'm confused about how Encrypt= and EncryptedVolume= interact.

>From repart.d(5) v256.7:

    EncryptedVolume=
        Specify how the encrypted partition should be set up. Takes at
        least one and at most three fields separated with a colon
        (":"). The first field specifies the encrypted volume name
        under /dev/mapper/. If not specified, "luks-UUID" will be used
        where "UUID" is the LUKS UUID.  The second field specifies the
        keyfile to use following the same format as specified in
        crypttab. The third field specifies a comma-delimited list of
        crypttab options. These fields correspond to the first, third
        and fourth column of the crypttab(5) format.

        Note that this setting is only taken into account when
        --generate-crypttab= is specified on the systemd-repart
        command line.

        Added in version 256.

My (possibly incorrect) understanding is that EncryptedVolume=
specifies the key-file in the second position - which in my demo code
is the following:

  Encrypt=key-file
  EncryptedVolume=dc-xdata:/run/fscrypt.sock:luks,discard

Which would then be /run/fscrypt.sock.  Am I confused about Encrypt=
and EncryptedVolume= ?

> By default, repart will encrypt
> with a null key in that case. IIRC, you have to pass in the keyfile
> (or maybe socket) to use in your drop-in.

I feel like I should know what my "drop-in" ... but I have no idea.
Is thet the repart.d/30-xdata.conf?  Is it the override I made to
systemd-repart.service as
systemd-repart.service.d/systemd-repart-gen_tabs.conf ?

> Apologies if I'm wrong. I'm on my phone and haven't pulled up the
> docs to verify.

Maybe you can send something with more details when you have access to
a system.

Thank you for the response.

> Best,
> Adrian 
> 
> On Sat, Oct 19, 2024, 20:21 Thayne Harbaugh <thayne at mastodonlabs.com>
> wrote:
> > Greetings - apologies if this isn't the proper list - please
> > redirect
> > me.
> > 
> > I'm writing a systemd-repart HOWTO with demo code for various use
> > cases:
> > 
> >   https://github.com/plastikos/repart_howto
> > 
> > The HOWTO is a typical document while the demos are minimal cases
> > built with mkosi and available for growing into larger solutions.
> > 
> > Initially it has two use-case demos:
> > 
> >   1. Creating a new partition (xdata) on first boot
> > 
> >   2. Creating a new partition (xdata) with encryption on first boot
> > 
> > Currently #1 works.  It's simple.  I still need to create more
> > details
> > around growing partitions and other ideas.
> > 
> > The encryption case #2, however, does not work and I'm looking for
> > some assistance.  While there is significant documentation around
> > the
> > systemd ecosystem of tools I feel like I have possibly missed some
> > detail or may not be understanding how to synthesize the
> > information
> > into a working model.
> > 
> > The encryption demo is identical to case #1 of adding a partition
> > with
> > the following changes:
> > 
> >   1. The /usr/lib/repart.d/30-xdata.conf file adds the following:
> > 
> >        Encrypt=key-file
> >        EncryptedVolume=dc-xdata:/run/fscrypt.sock:luks,discard
> > 
> >   2. a /usr/lib/systemd/system/fscrypt.socket file is added along
> > with
> >      a fscrypt at .service file (see the project source, please).
> > 
> >   3. A /usr/bin/getkey file is added for fscrypt at .service to call.
> >      getkey provides a simplistic way of producing an encryption
> > key
> >      for *demonstration* purposes *ONLY*.
> > 
> >   4. A /var/lib/key.bin is added as a binary encryption key that
> >      getkey retrieves - for *demonstration* purposes *ONLY*.
> > 
> > When built into a disk image by mkosi and started with qemu it
> > fails
> > to create the new xdata partition.  I see quite a few journal
> > messages
> > from systemd-repart and related udev events.  I have verified a few
> > things:
> > 
> >   1. /run/fscrypt.sock does get created
> > 
> >   2. getkey does emit the encryption key to stdout
> > 
> >   3. systemd-repart is started and initiates creating a partition
> > with
> >      LUKS
> > 
> > There are two notable details that cause me concern and might be
> > where
> > the problem lies:
> > 
> >   1. There is no evidence that getkey is invoked even when I
> >      instrument it to generate side-effects.
> > 
> >   2. There are messages in the journal that indicate that
> >      systemd-repart never exits and that it might be in deadlock
> > waiting
> >      for child events.
> > 
> > The messages around the possible deadlock of #2 above are the
> > following:
> > 
> >   Oct 19 12:08:48.510843 localhost systemd-repart[276]: loop0:
> > Acquired exclusive lock.
> >   Oct 19 12:08:48.512130 localhost systemd-repart[276]:
> > Successfully acquired /dev/loop0, devno=7:0, nr=0, diskseq=11
> >   Oct 19 12:08:48.516941 localhost systemd-repart[276]: Encrypting
> > future partition 2...
> >   Oct 19 12:08:48.517077 localhost systemd-repart[276]: Allocating
> > context for crypt device /dev/loop0.
> >   <SNIP/>
> >   Oct 19 12:08:49.114118 localhost (udev-worker)[299]: loop0:
> > Processing device (SEQNUM=1996, ACTION=change)
> >   Oct 19 12:08:49.114972 localhost (udev-worker)[299]: loop0:
> > Failed to flock(/dev/loop0): Resource temporarily unavailable
> >   Oct 19 12:08:49.114979 localhost (udev-worker)[299]: loop0: Block
> > device is currently locked, requeueing the event.
> >   <SNIP/>
> >   Oct 19 12:08:49.328308 localhost (udev-worker)[296]: loop0:
> > Processing device (SEQNUM=1996, ACTION=change)
> >   Oct 19 12:08:49.328345 localhost (udev-worker)[296]: loop0:
> > Failed to flock(/dev/loop0): Resource temporarily unavailable
> >   Oct 19 12:08:49.328352 localhost (udev-worker)[296]: loop0: Block
> > device is currently locked, requeueing the event.
> >   <SNIP/>
> > 
> > Those last three messages about failing to lock repeat until QEMU
> > is
> > shut down.
> > 
> > There are quite a few additional diagnostic details and logs that
> > may
> > be of interest but it might be easier to clone the repart_howto
> > project from github and run it:
> > 
> >   >$ ./demo crypt
> > 
> > Once it executes all of the mkosi configuration files and disk
> > image
> > are in the build-crypt sub-directory.  All relevant files specific
> > to
> > partition creation and encryption are in build-crypt/mkosi.extra -
> > there are not many since I'm trying to keep the demo as simple as
> > possible.  All relevant journal events and state information can be
> > extracted from build-crypt/image.raw.
> > 
> > Thanks for either directing me to a more appropriate help resource
> > and/or providing direct assistance.
> > 
> > 
> > P.S. If you want to run demo #1 of partition creation sans
> > encryption
> > then execute the following from the project source tree:
> > 
> >   >$ ./demo clear

-- 
Big Solutions