Open Community Firmware/LTS Firmware
Community Driven Open Source Firmware Proposal (KangKang Shen) first discussed 15 August 2019 LDCG SC meeting.
SAN19 Presentation https://static.sched.com/hosted_files/linaroconnectsandiego/11/SAN1-508%20Open%20Source%20UEFI%20Firmware%20V3.pdf
Rationale
Many enterprise companies have a lot of hardware products, the life cycle of hardware can be more than 10 years, especially for telecoms industry. Linux has been used widely in this market, Linux kernel has an LTS management project, so it can match the long term support requirements, this proposal is to work towards the same with EDK2.
Intel effectively has LTS concept with its UDKxxxx releases, we wish to replicate this on ARM.
Decreased code complexity allows for easier audits and backports of essential fixes to core code.
Increase the usage of standardized interfaces between layers in the firmware.
Scope
EDK2 "kernel code only"
Silicon and platform code is out of scope of this proposal (except SBSA QEMU Machine as a reference implementation)
Goals/Objectives
Phase 1
Separate EDK2 kernel from silicon code
Separate Silicon code from platform code
Increase the modularity of the code, make advanced features installable extras.
Phase 2
Establish LTS team for EDK2 in conjunction with Intel
Backport CVE (and other security patches) to EDK2 kernel code (and relevant open source silicon/platform)
Target Hardware Platforms
Implement for SBSA QEMU Machine as the simplest hardware platform
Deliverables
Patches for EDK2 to create the minimal platform concept on ARM
Regular releases tied to stable tag on EDK2
Selected releases pushed to LTS project for maintenance.
Validation Plan
Server ACS to be run against firmware on QEMU SBSA Machine
Other relevant testsuites to be investigated
Resourcing
Phase 1
1 Futurewei LT engineer + 1 additional member engineer
Fast server class machine for running QEMU based CI
Member target machines(s) for minimal firmware testing.
Phase 2
2 Member engineers from Linaro + engineers from Intel for LTS team
Multiple server class machines for QEMU based CI.
Member target machine(s) for LTS firmware testing.
High-level Timeline
Pre-project preperation SAN19-BUD20 cycle
Project kickoff BUD20
Phase 1 implementation BUD20 + six months cycle
Phase 2 implementation Post BUD20 connect + six months cycle.
High-level Risks and Mitigation Plans
Only high-level risks which need to be taken into consideration when approving a Project Proposal should be noted here. Detailed risks and issues are tracked during project delivery
Risk | Mitigation |
|---|---|
Intel does not want to form cross platform LTS team | Increase the resources in people needed for phase 2 implementation |
|
|
Reference
Any external references.