Overview

Hello, I am Caleb from Amazon Linux and we are interested in adding support for EROFS to Kiwi NG for OEM image types. This would enable creating bootable images with EROFS as the root filesystem, providing the benefits of EROFS to the base image, particularly for security-critical and attestable workloads.

Benefits would include:

• Immutable root filesystems for enhanced security
• Robust attestation of root filesystems with DM-Verity
• Efficient compression of the root filesystem
• Enhanced security posture for sensitive workloads

Background

EROFS is already available as a filesystem and image type in kiwi but is not a provided as filesystem for the OEM image type. EROFS is helpful creating attestable images that can run secure workloads with integrity. Adding EROFS support to the root filesystem will allow users to secure images and attest the root filesystems contents.

What we would like to implement

Based on my initial work, the implementation would require:

1. Adding EROFS to the list of supported filesystems in Kiwi's schema for oem types
2. Implementing the create_on_device function to the erofs.py module to handle EROFS filesystem creation for OEM images
3. Implement targeted overlays for the EROFS root filesystem to minimize what is modifiable and still allow the image to function (i.e. keep /var,/etc and possible /home writable)
4. Updating the OEM image builder to support EROFS as a root filesystem as an XML attribute
5. Implementing optional DM-Verity integration for attestation scenarios
6. Adding support for generating filesystem measurement manifests

Why EROFS support in OEM is needed

It's important to note that simply supporting EROFS as a filesystem is not sufficient for attesting images. For this feature to be truly useful for attestation, we need to ensure that:

1. OEM image type compatibility: EROFS needs to be fully supported in the OEM image type, allowing for bootable images with EROFS as the root filesystem.
   1. Likely this will imply that overlays will be required, fortunately kiwi already provides this feature.
   2. We may also want to add the ability to target specific directories for overlays, thus minimizing what is modifiable in the root filesystem
2. Initrd/initramfs support: The initial ramdisk must be able to recognize and mount EROFS root filesystems.
3. Measurement and attestation hooks: Support for filesystem measurements that can be used in attestation flows.

Security benefits for attestable workloads

1. Tamper-evident filesystem: EROFS combined with DM-Verity creates a tamper-evident root filesystem where any modification can be cryptographically detected.
2. Supply chain security: Helps maintain the integrity of the software supply chain by ensuring that deployed images match exactly what was built and signed.
3. Runtime integrity: Prevents runtime modifications to system binaries and libraries, protecting against certain classes of persistent threats.

Example configuration

Here's how EROFS could be configured in a Kiwi XML file:

<!-- OEM image with EROFS root filesystem -->
<preferences>
    <type image="oem" filesystem="erofs" erofscompression="zstd,level=12">
        <bootloader name="systemd_boot"/>
    </type>
</preferences>

<!-- Secure OEM image with EROFS and DM-Verity -->
<preferences>
    <type image="oem" filesystem="erofs" erofscompression="zstd,level=9" verity="true" verity_hash_algorithm="sha256">
        <bootloader name="systemd_boot" secure_boot="true"/>
    </type>
</preferences>

<!-- Live ISO with EROFS root -->
<preferences>
    <type image="iso" filesystem="erofs" erofscompression="zstd,level=12">
        <bootloader name="grub2" console="serial" timeout="10"/>
    </type>
</preferences>

Next steps

I'm willing to contribute this implementation with a PR and we've already done some preliminary work and testing that demonstrates the feasibility and benefits of this approach.

Would the maintainers be interested in this feature? Any specific requirements or considerations I should be aware of before proceeding with a pull request?