Support verity baked root with verity data from extra partition

[xcawolfe-amzn]

Overview

Hi all, following the discussion from the EROFS ticket #2799, we (Amazon Linux) would like to propose enhancements to the dm-verity implementation in Kiwi and dracut. This proposal focuses on improving support for Unified Kernel Images (UKIs) and dm-verity verification for root filesystems.

Note: Our primary focus is on utilizing measurements for dm-verity verification without strictly addressing secure boot requirements.

Current State

Based on our review of the Kiwi documentation and schema, we understand that Kiwi currently supports:

• Basic dm-verity functionality via verity_blocks and embed_verity_metadata attributes
• Dracut as the default initrd system
• The KIS configuration supports some of what a user might want for a UKI image but its not readily apparent that the use case for KIS matches what users may need for building an image with a verity verified root file systems with a UKI in one config.xml. Specifically KIS seems to assume that the root file system will not be built with the kernel image but users may want to build a root filesystem, UKI, and initramfs all in one go.
  • I was having a hard time seeing if this was a meaningful option that might address the issues below, but reading the legacy PXE documentation it looks like loop mounting is the approach for KIS and may not work for users who want to use a root filesystem directly, am I misunderstanding?

Proposed Enhancements

1. Make Signature Optional for DM-Verity Hashes

• Allow users to optionally sign their DM-verity hashes instead of mandatory signing. Default mode would be to sign the root hash, but if a user wants to simply use the root hash without managing a key they would have the option. This can be useful for experimenting, debugging, and testing.

2. UKI Integration with Dracut

• Enable UKI builds when using --uefi and --kver parameters with dracut via xml attributes/elements
  • See example below for how this might look
• This should simplify the UKI creation process by leveraging existing dracut capabilities
  • and this should reduce dependencies on external tools like systemd-ukify

3. Kernel Command Line Integration

• When using verity, automatically append roothash=<verity_hash> to the kernel command line
• Implement dracut configuration options an an child elements in the <bootloader type="systemd_boot"> configuration when building EFI binaries,
  • see example below and 3a

3a. Enhanced Dracut Configuration Options

• Allow users to extend dracut initramfs options with child elements under <bootloader><dracut>:
• --install "/path/to/veritysetup /path/to/debug_tool" for debugging boot issues and allowing users to easily customize their initramfs via <install> attribute
• --add-drivers/--force-drivers to ensure required kernel modules are included via <add-drivers name=""/> / <force-drivers name=""> elements
• --add flag for including additional dracut modules vial <modules> or <add modules= "">
• Support for debug flags like rd.debug and rd.kiwi.debug is noted, but the ability to install CLI tools into the initramfs would provide additional debugging capabilities

5. Dedicated Verity Partition

• Add option to store verity data in a dedicated partition rather than embedding it in the root partition
• This would maintain logical separation between the root filesystem and its verification data, this simplifies things for ensuring all the data of root partition is just the root filesystem.
  • See example below for implementation idea

Benefits

UKI and Dracut Integration

• Leverages existing Kiwi dracut integration
• Simplifies UKI creation and support
• Reduces external dependencies
• Improves attestation capabilities, especially for secure boot scenarios
• Provides a consistent approach to boot image creation

Verity and Dracut in the xml with OEM type

• Simplifies adding kernel command line options for systemd-generators and verity root hash (and other kernel command line options) using the existing attributes for OEM types
• Consolidates dependencies required for booting and debugging
• Provides flexibility through --add-drivers/--force-drivers and --filesystem/--install flags

Example Configuration

<!-- verity_blocks= implies appending the root hash to the kernel command line -->
<type image="oem" 
  filesystem="erofs"
  firmware="efi"
  efipartsize="100" 
  verity_blocks="all"
  initrd_system="dracut"
  <!-- if set to false, verity_signature_key not required --> 
  verity_signature_required="true"
  verity_signature_key="<path_to_key>" 
  embed_verity_metadata="false" 
  <!-- Both embed_verity_metadata and verity_partition cannot be true, also implies roothash=<hash> is appended to the kernel command line --> 
  verity_partition="true"  
  kernelcmdline=""systemd.verity_root_data=<data_device> systemd.verity_root_hash=<hash_device> systemd.verity_root_options=<options> ..."
  veritypartsize="100">

  <bootloader name="systemd_boot" console="serial">
    <dracut> 
    <bootloader name="systemd_boot" console="serial">
    <dracut><!--  NOTE: not set on element here but looked like this convention is what the install media types use, this is bit different but I think works -->
    <!--  NOTE: Not set on the convention but the below denotes the general idea of dracut flags being child elements --> 
       <install paths="/usr/bin/veritysetup"/>

        <!-- <uki> implies --uefi and --kver dracut flags  --> 
        <uki>
          <kernel name="name_of_kernel"/> 
       </uki>
       <filesystems names="erofs ext4 ..."/>
       <add_drivers names= "erofs ext4 ..." />
       <force_drivers names="erofs ext4 ..."/>
       <add modules="dm-verity etc."/>
       ... 
  </bootloader>
</type>

Any issues with the proposals above? As discussed in the erofs issue, we will look into investigating into this issue and will create a PR (or PRs) Thanks!

[schaefi]

Make Signature Optional for DM-Verity Hashes

This is done with the enhancement in #2800 for the kiwi-verity module.

When using verity, automatically append roothash=<verity_hash> to the kernel command line

That I don't agree with because there is support for /etc/veritytab which is supposed to read by the systemd-verity-generator and it is also read by the kiwi-verity module. So the information to open the verity devices should come from /etc/veritytab which also implemented as part of #2800

UKI Integration with Dracut

Can we please handle this part as a separate issue. There is already an open Issue for support of UKI here: #2408

Enhanced Dracut Configuration Options

I would also keep this as a separate feature request. As of today we intentionally did not expose the dracut.conf.d capabilities into the image description. Actually you can easily add an overlay file e.g etc/dracut.conf.d/some.conf and place all the mentioned settings you need.

Dedicated Verity Partition. This would maintain logical separation between the root filesystem and its verification data, this simplifies things for ensuring all the data of root partition is just the root filesystem.

I do not understand where the simplification lives in this regard ? imho there is no difference in an offset of the same partition compared to an offset address living in the partition table :) In fact I see an extra partition to store the verification blocks as additional overhead which can make things more complicated. In addition an extra partition creates an easy attack vector whereas you have to know the offset address in the other case which at least requires to extract the initrd and lookup the veritytab. So I would be very interested to understand the real benefit of this separation ?

Thanks

[xcawolfe-amzn]

Make Signature Optional for DM-Verity Hashes

This is done with the enhancement in #2800 for the kiwi-verity module.

Awesome, I'll take a look!

When using verity, automatically append roothash=<verity_hash> to the kernel command line

That I don't agree with because there is support for /etc/veritytab which is supposed to read by the systemd-verity-generator and it is also read by the kiwi-verity module. So the information to open the verity devices should come from /etc/veritytab which also implemented as part of #2800

O okay, if using the /etc/veritytab will handle finding and storing the root hash for the root filesystem then that will work, we'll take a look at using this approach. Looking at your PR it seems like you have it covered in disk.sh#1358

UKI Integration with Dracut

Can we please handle this part as a separate issue. There is already an open Issue for support of UKI here: #2408

Enhanced Dracut Configuration Options

I would also keep this as a separate feature request. As of today we intentionally did not expose the dracut.conf.d capabilities into the image description. Actually you can easily add an overlay file e.g etc/dracut.conf.d/some.conf and place all the mentioned settings you need.

Will do! I'll create a couple of new issues for these and take a look at the Issue for UKIs.

I do not understand where the simplification lives in this regard ? imho there is no difference in an offset of the same partition compared to an offset address living in the partition table :) In fact I see an extra partition to store the verification blocks as additional overhead which can make things more complicated. In addition an extra partition creates an easy attack vector whereas you have to know the offset address in the other case which at least requires to extract the initrd and lookup the veritytab. So I would be very interested to understand the real benefit of this separation ?

We will get back to you on this one, for now we will try out the using the existing functionality for adding the hash blocks to the root filesystem partition.

[schaefi]

We will get back to you on this one, for now we will try out the using the existing functionality for adding the hash blocks to the root filesystem partition.

That's great, thanks. Don't get me wrong I'm always open for changes but I'd like to understand the benefit when we add that functionality. Thanks again

[schaefi]

As a summary just that I don't forget what this issue is all about:

• UKI support, there is already an issue open for that part. See RFE: Add support for direct UKI boot #2408
• Make systemd-veritysetup-generator work, such that kiwi-verity becomes optional: https://www.freedesktop.org/software/systemd/man/latest/systemd-veritysetup-generator.html. My attempts with Tumbleweed failed, for some reason it does not work with the veritytab in the initrd whereas there is no problem on a manual veritysetup open call with that information
• Add support for extra verity data partition in addition to the default verity blocks baked on the same partition

From my perspective it would be useful to close this one and create two extra issues for the remaining tasks because they can be handled independent from each other

[github-actions]

This issue is stale because it has been open 60 days with no activity. stale label was set.