Enable building systemd-ukify and systemd-boot on ARM64

[SeanDougherty]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

This PR updates systemd to build systemd-ukify and systemd-boot for both ARM64 architecture as well as the original x86_64 architecture. Additionally, systemd-boot-signed is updated to enable building on aarch64.

Signed-off-by: Sean Dougherty [email protected]

Does this affect the toolchain?

NO

Associated issues

• https://dev.azure.com/mariner-org/mariner/_workitems/edit/14252

Test Methodology

• Pipeline: https://dev.azure.com/mariner-org/mariner/_build/results?buildId=890974&view=results

[christopherco]

Consider dropping the changes in systemd-boot-signed and just bumping the release number on the spec for the time being.
Then once you've hooked up the infra side to produce the signed systemd-bootaa64.efi binary, you can make this update to systemd-boot-signed so we start getting officially signed systemd-bootaa64.efi artifacts.

[christopherco]

The copy step for source1 into systemd-bootaa64.efi on aarch64 is missing, thus making this step copy the unsigned version of systemd-bootaa64.efi from the original RPM (source0), instead of the signed version.

[SeanDougherty]

Taking note for when we come back to systemd-boot-signed with these changes. Thank you Chris!

[SeanDougherty]

Consider dropping the changes in systemd-boot-signed and just bumping the release number on the spec for the time being. Then once you've hooked up the infra side to produce the signed systemd-bootaa64.efi binary, you can make this update to systemd-boot-signed so we start getting officially signed systemd-bootaa64.efi artifacts.

Dropped changes as per recommendation. Release has been bumped to align with systemd.spec

[CBL-Mariner-Bot]

🚨 PR Check Failed - Critical Issues Found

Found 1 critical/error issue(s) that must be fixed.

🔍 Critical Issues Detected:

1. Missing Patch File (ERROR)
   • Patch file 'https://github.com/systemd/systemd/pull/26494.patch' is referenced in the spec but not found in the directory
   • 💡 Fix: Add the missing patch file or update the Patch reference

🤖 AI Analysis Summary:

Brief Analysis:
The changes bump the release numbers for both systemd-boot-signed and systemd packages and add ARM64 support in systemd.spec while referencing a new CVE patch (CVE-2023-7008).

Critical Issues Found:
• CVE-2023-7008.patch is referenced but its presence in the package directory isn’t confirmed.

Recommended Actions:
• Verify that CVE-2023-7008.patch (and any other referenced CVE patches) is included in the repository.
• Add a changelog entry for the CVE fix in systemd.spec to document the security remediation.
• Double-check that patch application directives (e.g., %autosetup, %patch) properly apply all patches.

---

📋 For detailed analysis and recommendations, check the Azure DevOps pipeline logs.

[SeanDougherty]

🚨 PR Check Failed - Critical Issues Found

Found 1 critical/error issue(s) that must be fixed.

🔍 Critical Issues Detected:

1. Missing Patch File (ERROR)

   • Patch file 'https://github.com/systemd/systemd/pull/26494.patch' is referenced in the spec but not found in the directory
   • 💡 Fix: Add the missing patch file or update the Patch reference

🤖 AI Analysis Summary:

Brief Analysis: These changes update the release number and add ARM64 support while retaining pre‐existing patch definitions—including a CVE patch (CVE-2023-7008).

Critical Issues Found: • No explicit application of patch directives is visible for the CVE patch; ensure it’s applied correctly. • The changelog does not mention the CVE fix corresponding to CVE-2023-7008.

Recommended Actions: • Verify that CVE-2023-7008.patch (and other declared patches) is present in the package directory and that it is applied via %patch or %autopatch in the %prep section. • Update the changelog with a clear entry for the CVE fix. • Confirm that ARM64 changes use the same patch management best practices as the x86_64 code.

📋 For detailed analysis and recommendations, check the Azure DevOps pipeline logs.

This appears to be a false alarm. '26494.patch' is present in /SPEC/systemd/ , however, this referencing of patch0001 using the github url is new to me.

How does this play with RPM?

This has been in the spec since 255, so I'm curious if this issue is benign.

EDIT: Further review shows that this Patch path format follow similarly to our Source#: fields. Only the final portion of the path is used by rpmbuild. This is not a typical format for Patch files in Azure Linux, but it is not incorrect. We can confirm this is a false alarm from CBLMariner-Bot.

Seperately, CBLMariner-Bot also raised concerns over a missing CVE-2023-7008 patch. This is also a false alarm, the patch was contributed 7 months ago and still exists and is being applied.