847fd39b25
Encapsulate all UEFI Secure Boot required settings in one Kas configuration file. Introduce SBSIGN_KEYS_DIR variable where UEFI keys will be generated to sign UEFI binaries. Introduce uefi-secureboot machine feature, which is being used to conditionally set the proper UEFI settings in recipes. Replace Grub bootloader with systemd-boot, which it makes easier to enable Secure Boot. Advantages using systemd as Init Manager: - Extending secure boot to userspace is a lot easier with systemd than with sysvinit where custom scripts will need to be written for all use cases. - systemd supports dm-verity and TPM devices for encryption usecases out of the box. Enabling them is a lot easier than writing custom scripts for sysvinit. - systemd also supports EUFI signing the UKI binaries which merge kernel, command line and initrd which helps in bringing secure boot towards rootfs. - systemd offers a modular structure with unit files that are more predictable and easier to manage than the complex and varied scripts used by SysVinit. This modularity allows for better control and customization of the boot process, which is beneficial in Secure Boot environments. - Add CI settings to build and test UEFI Secure Boot. Add one test to verify Secure Boot using OE Testing infraestructure: $ kas build ci/qemuarm64-secureboot.yml:ci/meta-secure-core.yml:ci/uefi-secureboot.yml:ci/testimage.yml ... RESULTS - uefi_secureboot.UEFI_SB_TestSuite.test_uefi_secureboot: PASSED (0.62s) ... SUMMARY: core-image-base () - Ran 73 tests in 28.281s core-image-base - OK - All required tests passed (successes=19, skipped=54, failures=0, errors=0) Signed-off-by: Javier Tia <javier.tia@linaro.org> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> [yml file include fix] Signed-off-by: Jon Mason <jon.mason@arm.com>
Introduction
This repository contains the Arm layers for OpenEmbedded.
-
meta-arm
This layer contains general recipes for the Arm architecture, such as firmware, FVPs, and Arm-specific integration.
-
meta-arm-bsp
This layer contains machines for Arm reference platforms, for example FVP Base, Corstone1000, and Juno.
-
meta-arm-toolchain
This layer contains recipes for Arm's binary toolchains (GCC and Clang for -A and -M), and a recipe to build Arm's GCC.
Other Directories
-
ci
This directory contains gitlab continuous integration configuration files (KAS yaml files) as well as scripts needed for this.
-
documentation
This directory contains information on the files in this repository, building, and other relevant documents.
-
kas
This directory contains KAS yaml files to describe builds for systems not used in CI.
-
scripts
This directory contains scripts used in running the CI tests.
Mailing List
To interact with the meta-arm developer community, please email the meta-arm mailing list at meta-arm@lists.yoctoproject.org. Currently, it is configured to only allow emails to members from those subscribed. To subscribe to the meta-arm mailing list, please go to https://lists.yoctoproject.org/g/meta-arm
Contributing
Currently, we only accept patches from the meta-arm mailing list. For general information on how to submit a patch, please read https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
E-mail meta-arm@lists.yoctoproject.org with patches created using this process. You can configure git-send-email to automatically use this address for the meta-arm repository with the following git command:
$ git config --local --add sendemail.to meta-arm@lists.yoctoproject.org
Commits and patches added should follow the OpenEmbedded patch guidelines:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
The component being changed in the shortlog should be prefixed with the layer name (without the meta- prefix), for example:
arm-bsp/trusted-firmware-a: decrease frobbing level
arm-toolchain/gcc: enable foobar v2
All contributions are under the MIT License.
For a quick start guide on how to build and use meta-arm, go to quick-start.md.
For information on the continuous integration done on meta-arm and how to use it, go to continuous-integration-and-kas.md.
Backporting
Backporting patches to older releases may be done upon request, but only after a version of the patch has been accepted into the master branch. This is done by adding the branch name to email subject line. This should be between the square brackets (e.g., "[" and "]"), and before or after the "PATCH". For example,
[nanbield PATCH] arm/linux-yocto: backport patch to fix 6.5.13 networking issues
Automatic backporting will be done to all branches if the "Fixes: " wording is added to the patch commit message. This is similar to how the Linux kernel community does their LTS kernel backporting. For more information see the "Fixes" portion of https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submittingpatches
Releases and Release Schedule
We follow the Yocto Project release methodology, schedule, and stable/LTS support timelines. For more information on these, please reference:
- https://docs.yoctoproject.org/ref-manual/release-process.html
- https://wiki.yoctoproject.org/wiki/Releases
- https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS
For more in-depth information on the meta-arm release and branch methodology, go to </documentation/releases.md>.
Reporting bugs
E-mail meta-arm@lists.yoctoproject.org with the error encountered and the steps to reproduce the issue.
Security and Reporting Security Issues
For information on the security of meta-arm and how to report issues, please consult SECURITY.md.
Maintainer(s)
- Jon Mason jon.mason@arm.com
- Ross Burton ross.burton@arm.com