Dracut Enhancements For Dm-verity Verified Root Filesystems With UKIs

by ADMIN 70 views

Overview

In recent discussions regarding the EROFS ticket on GitHub, Amazon Linux proposed 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. 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.

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. This should simplify the UKI creation process by leveraging existing dracut capabilities and 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 as child elements in the <bootloader type="systemd_boot"> configuration when building EFI binaries.

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 via <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, simplifying things for ensuring all the data of root partition is just the root filesystem.

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>

Potential Issues with the Proposals

While the proposed enhancements aim to improve support for Unified Kernel Images (UKIs) and dm-verity verification for root filesystems, there are potential issues to consider:

  • The optional signing of DM-verity hashes may introduce security risks if not properly managed.
  • The UKI integration with Dracut may require significant changes to the existing codebase, potentially introducing new bugs or compatibility issues.
  • The kernel command line integration may require additional configuration options to ensure proper functionality.
  • The dedicated verity partition option may require additional storage space and may not be suitable for all use cases.

Q: What is the purpose of the proposed enhancements to the dm-verity implementation in Kiwi and Dracut?

A: The primary goal of the proposed enhancements is to improve support for Unified Kernel Images (UKIs) and dm-verity verification for root filesystems. This will enable users to create and manage UKIs more efficiently and securely.

Q: What are the current limitations of the dm-verity implementation in Kiwi and Dracut?

A: The current implementation of dm-verity in Kiwi and Dracut has several limitations, including:

  • Mandatory signing of DM-verity hashes, which can be a security risk if not properly managed.
  • Limited support for UKI creation and management.
  • Inefficient kernel command line integration.
  • Lack of dedicated verity partition option.

Q: How will the proposed enhancements address these limitations?

A: The proposed enhancements aim to address these limitations by:

  • Introducing optional signing of DM-verity hashes.
  • Improving UKI creation and management through integration with Dracut.
  • Enhancing kernel command line integration.
  • Adding a dedicated verity partition option.

Q: What are the benefits of the proposed enhancements?

A: The proposed enhancements will provide several benefits, including:

  • Improved security through optional signing of DM-verity hashes.
  • Simplified UKI creation and management.
  • Enhanced kernel command line integration.
  • Increased flexibility through dedicated verity partition option.

Q: What are the potential issues with the proposed enhancements?

A: The proposed enhancements may introduce several potential issues, including:

  • Security risks if optional signing of DM-verity hashes is not properly managed.
  • Compatibility issues with existing codebase.
  • Additional configuration options required for kernel command line integration.
  • Potential storage space requirements for dedicated verity partition option.

Q: How will the proposed enhancements be implemented?

A: The proposed enhancements will be implemented through a series of changes to the Kiwi and Dracut codebases. These changes will include:

  • Introduction of optional signing of DM-verity hashes.
  • Integration of UKI creation and management with Dracut.
  • Enhancement of kernel command line integration.
  • Addition of dedicated verity partition option.

Q: What is the expected timeline for the implementation of the proposed enhancements?

A: The expected timeline for the implementation of the proposed enhancements is several months. The exact timeline will depend on the complexity of the changes and the availability of resources.

Q: How will the proposed enhancements be tested and validated?

A: The proposed enhancements will be tested and validated through a series of tests and validation procedures. These procedures will include:

  • Unit testing of individual components.
  • Integration testing of components.
  • System testing of the entire system.
  • Validation of the proposed enhancements against existing requirements and specifications.

Q: What is the expected impact of the proposed enhancements on the community?

A: The proposed enhancements are expected to have a impact on the community, including:

  • Improved security through optional signing of DM-verity hashes.
  • Simplified UKI creation and management.
  • Enhanced kernel command line integration.
  • Increased flexibility through dedicated verity partition option.

Overall, the proposed enhancements aim to improve the support for Unified Kernel Images (UKIs) and dm-verity verification for root filesystems. While there are potential issues to consider, the benefits of the proposed enhancements are significant and will have a positive impact on the community.