.png){kind=small}
Day 2
Intro
In previous post we have presented some thoughts that evolved during the OSFC 2020 day 1. If you haven’t read the previous part, we recommend you to do so, because this post is a continuation of our shares around day 2 and 3. Remember, presented descriptions are only our humble opinion, not official statements of presenters. To watch the full video and get your own opinion, click the chosen title.
Marcin explained how to port edk2 for Armada8k allowed for being adapted on new platforms and presented firmware development goals for high-end ARM-based hardware (SBSA/SBBR, SystemReady ES), as it provides a sufficient interface to boot most operating systems (Fedora, Debian, Centos, FreeBSD, OpenBSD and VMware). During the discussion after the presentation, we realized that boards based on Marvel Armada 8k like SolidRun ClearFog 8k or Marvell MACCHIATObin are S-CRTM (aka Secure Boot aka Verified Boot) capable. In 2021 we definitely want to look more into that. FOSDEM 2021 talk from Maciej can be a good excuse “Overview of Secure Boot state in the ARM-based SoCs”
Interesting talk about Security Protocol and Data Model standard (1.0 and 1.1) and openspdm with it’s design and specification. Explicitly presented communication between Requester and Responder, Transport Layer Binding, and features, finished with demo covering init connection, challeng/auth, session creation and secured message. We recognize SPDM as an important part of Platform Firmware Resiliency as described in NIST 800-193. We would love to dive deeper, but the tight schedule keeps us away from this technology. Maybe 2021 can bring commercial projects related to that matter.
The talk proudly held by our team. It described the plans of porting the POWER9 architecture to coreboot along with Talos II and Talos II Lite machines. We also presented details of coreboot port for POWER9 will covering hostboot, skiboot and petitboot and how they fit into coreboot firmware model. We have briefly described use cases, the project’s development roadmap, the next steps within Dasharo project, seamless integration of Intel FSP or AMD AGESA with UEFI-compliant and legacy OS interface. Contributions. For those who want to dive deeper, or join the forces we hold a community call every 2 weeks about port progress and publish minutes here.
BMC firmware for Intel. Interested improvements for ipmi password, ARM security (TEE) for protecting the password, and initial secret and safe/trusted execution environment. Widely discussed hardware requirements, boot requirements, and other prerequisites that are necessary for secure storage on the BMC. Presenters showed also planned improvements and the next steps of the development. 3mdeb, despite being proficient in Yocto, as the official Yocto Participants have a hard time to enter BMC development. Maybe OpenPOWER or some Dasharo Server projects will bring our Embedded Linux expertise to the OSF world.
The talk went through the main features implemented in meta-amd for OpenBMC, enabling it on AMD customer reference boards and upstream support for AMD system interfaces. Very detailed and exciting journey. Kudos to AMD for your work. Definitely worth to mention at FOSDEM 2021 “Open Source Firmware status on AMD platforms 2021” talk.
- Introducing open firmware development model for the Programmable Service Engine’s in Intel Atom x6000E Series by Loo Tung Lun
Session described Internal CPU based on ARM Cortex M7 core, introduced in Elkhart Lake. Mentioned iotg-fbu to support PSE development. Overall, the presenters showed how to develop and customize the PSE firmware for Intel platform, by explaining the mechanisms of PSE firmware and system boot firmware cooperation with the open source software tools for integration and development. For the OSF community this is definitely a technology to worry about - another weird processing unit as part of our platform. From a business point, feature can be beneficial for various embedded use cases, where remote access is huge problem.
The presenters described ConTest - a modular framework aimed at automating system testing workflows and building board-specific testing infrastructure on top of it. It is an interesting project co-organized by Facebook + 9elements, presenting ConTest as a major framework for OCP (Scenario OCP Deltalake). What is very important about this presentation that it tries to highlight the effort of creating a validation framework and services for OSF community. 3mdeb will definitely take part in that especially that we have long-standing (5+ years) of experience with firmware validation, which we productize as part of Dasharo Compatibility module. Kudos for sharing!
Very Rust talk dedicated to the project X aimed at existing binary blobs from the x86 part of Zen CPUs. Ron presented oreboot on the AMD Fam17h. He discussed the main problem of the Open System Firmware requirement for buildable, installable, redistributable firmware, the approaches to it, and the next steps.
Some of the key points of that are:
- Not everyone can get/borrow AMD EPYC CRB
- There are some hw platforms on market, but are those without vendor lock-in?
- Also expensive for OSF vendor without justified business
- Code initializes minimal set of low-speed interfaces to boot Linux
- To fully utilize platform using OSF there is way more work, which probably would be hard to do without correct™ coordination
More information can be found in the FOSDEM'21 3mdeb’s presentation and Reddit post.
The important status of the project that aims at porting LinuxBoot on HPE platforms. A brief description of a live demo with the approached challenges, proof of concept, and next steps. What seems to be interesting HPE seems to provide LinuxBoot-enabled Facebook servers – “private customer.” Thanks HPE for the status.
The second talk of our team describing the progress of the TrenchBoot project. Overall status, added features and 3mdeb support development for the AMD Secure Startup. Presenters described the most key changes introduced into the project: the DRTM event log and the possibility to boot Xen Hypervisor with measured launch. Interestingly there was a quite long discussion with Eugene and Jeremiah about the importance of open-source implementation of D-RTM that works across the platforms. More to that we received information that open-sourcing AMD SMM Supervisor is planned.
Day 3
- oreboot status report by Ryan O’Leary, Ronald g. Minnich
oreboot is a downstream fork of coreboot, with all C removed, and all code written in Rust. Since we spoke of oreboot a year ago, a lot has happened, and we want to go over the status.
We’ve got a few interesting facts:
- oreboot works on booting TockOS (Rust)
- it can be tried on QEMU
- works with OpenTITAN chips (FPGA)
Another great project, which we would happy to triage if only there would be enough resources in our pocket.
Interesting facts about the benefits of moving to a community-driven RTOS instead of using our custom kernel, presentation of ChromiumOS Embedded Controller and information about google plans in contributing to Zephyr OS. This is definitely a big deal for us since we are engaged in Zephyr OS-based IoT firmware development for quite some time. You can check our blog posts about it here. We looking for a commercial assignment that involves Zephyr-based EC.
The Arm SystemReady (Arm SR) program was explained in the first half of the presentation. It is an extension of the Arm ServerReady program that tries to describe a new set of standards and a compliance certification program which goal is to make standard OSes and hypervisors “just work” on ARM devices. The program is based on a set of minimum hardware requirements (BSA), firmware requirements (BBR), and certification requirements (ACS). The second half of the presentation shows how the SystemReady certification can be achieved using open source projects such as TF-A, TianoCore or U-Boot. The lesson ended with the presentation of devices that have already received the Arm SR certification (e.g. RPi4 - Arm SR ES certified) or whose certification is in progress (e.g. NXP LS1046A FRWY/RDB).
Just a few keynotes:
- BBR consist of in SBBR (Server BBR), EBBR (embedded BBR) and LBBR (using LinuxBoot)
- additional BBSR (BaseBoot Secure Requirements) which is for secure boot and firmware update
- there is no ISV ecosystem that Arm endorse for certification
Summary
We, in 3mdeb, believe in Freedom and Open Source Software (FOSS) that is why it was a both a pleasure and honor to participate in the project that aims at changing the way of firmware development, collaboration, and knowledge share. Thank you, the community for this fruitful meeting and common share of thoughts and trust.
If you think we can help in improving the security of your firmware or you are
looking for a training that can boost your team of developers inside UEFI,
coreboot or Yocto area, feel free to
book a call with us or
drop us email to contact<at>3mdeb<dot>com. If you are interested in similar
content feel free to sign up for our newsletter
