“[…]Since 4.10 there were 1630 new commits by over 130 developers. Of these, about 30 contributed to coreboot for the first time.[…] Verified Boot: The vboot feature that Chromebooks brought into coreboot was extended to work on devices that weren’t specially adapted for it: In addition to its original device family it’s now supported on various Lenovo laptops, Open Compute Project systems and Siemens industrial machines. Eltan’s support for measured boot continues to be integrated with vboot, sharing data structures and generally working together where possible.[…]”
coreboot 4.9 has been released. There are lots of changes, but the project does a great job summarizing the changes in their announcement:
[…]In the little more than 7 months since 4.8.1 we had 175 authors commit 2610 changes to master. The changes were, for the most part, all over the place, touching every part of the repository: chipsets, mainboards, tools, build system, documentation. In that time we also had 70 authors made their first commit to coreboot.[…]
* ACPICA: Update to version 20181031 * olog:olog.json: Update OPAL skiboot errors to check on olog scan * acpi: button: check fixed hardware & control method power buttons * kernelscan: add -k option to specify klog json filename * README: update package dependency notes for RHEL * acpica: fix linker issues when building with ACPI disabled * src/lib: add module probing helper functions * lib: fwts_efi_module: use the new module loading helper functions * lib/fwts_cpu: use new use the new module loading helper functions * snapcraft: update confinement and plugs * lib: fwts_coreboot_cbmem: don’t use void * pointer arithmetic * lib: fwts_coreboot_cbmem: shift UL values rather than signed int values * lib: fwts_log: shift UL values rather than signed int values * acpi: syntaxcheck: rename syntaxcheck_table to syntaxcheck_single_table * dmicheck: fix Maximum Capacity checking range * mcfg: fix MMIO config space checking * madt: fix the Local APIC NMI processor UID checking * auto-packager: mkpackage.sh: add disco
[…]This provides specific guidance for firmware based upon the EFI Developer Kit II (EDKII) and coreboot. Because this document deals with host firmware internal requirements, it is not intended to provide side channel mitigation guidance for general application developers.
Scope: This addresses bare-metal firmware runtime risks and mitigation suggestions for the bounds check bypass, branch target injection, rogue data cache load, rogue system register read, and speculative store bypass side channel methods. Our examples and context are primarily focused on ring 0 firmware runtimes (for example: EFI Developer Kit II, PI SMM, and coreboot SMM). Other firmware execution environments are out of scope.[…]
UEFI Payload (UefiPayloadPkg) aims to be an upgrade to CorebootModulePkg and CorebootPayloadPkg. Features: – Supporting Slim Bootloader in addition to Coreboot – Source level configuration using .ini format – User Extension using simple “C” codes – Platform support library for adding platform specific codes
Can confirm. A lot of the changes on Google’s “campfire” branch of coreboot resemble those that MrChromebox & I made on the older Haswell, Bay Trail and Skylake chromebooks to unofficially boot & run Windows. (Though some of those changes were merged)https://t.co/ZoiFkaI9cg
Blog post describing how we got Coreboot ported to the 51nb X210 weird Thinkpad thing – including reverse engineering via grep, rescuing hardware by running it out of tolerance and using i2cdetect to make RAM appear: https://t.co/myXdT92LAb
[…]The other fun thing about it is that none of the firmware flashing protection is enabled, including Intel Boot Guard. This means running a custom firmware image is possible, and what would a ridiculous custom Thinkpad be without ridiculous custom firmware? A shadow of its potential, that’s what. So, I read the Coreboot motherboard porting guide and set to.[…]
At Scaleway we started to design our servers with the ARM C1. Later we switched to a x86 architecture to provide the C2 and Dedibox SC2016. In both ARM and x86, a BIOS is required to start the server. BIOS software got many legacy and backward compatible software to ensure a reliable behavior accross many boards. I was in charge of the BIOS development for our new generation of x86 servers. This article presents technical choices we used during our development.[…]
As part of the @conservancy project we are a non-profit organization taking care of the #coreboot infrastructure ourself. #Donate now https://t.co/ycRmUSYULX and help us to support our free software developers which do testing, QA and infrastructure work in their free time!!
Embedded Software Engineer – Bootloaders Qualcomm processors provide integrated solutions for millions of diverse mobile and new emerging platforms across IoT, Automotive and Compute markets. It all starts with the Boot Firmware the first mission critical code to execute on our SoC(System on chip) and prepare the system for operation. We design and develop the software we put in mask boot ROM, along with system boot-loaders. Features we work on include image authentication, multicore setup, the UEFI pre-boot environment, configuration of next-generation DDR memories, ARM CPU and custom Qualcomm DSP/microprocessors, MMU/Cache memory management and advanced driver development for multiple boot/storage devices including eMMC, UFS, NAND, SPI-NOR, QSPI and flashless boot transport interfaces such as PCIe, SDIO, USB. Embedded Bootloader design & development involves architecting solutions to address different use cases and feature requirements in the early bootloader environment before the handoff to the High Level Operating System kernel. Engineer is expected to work with different Qualcomm build infrastructure tools and ARM compiler tool chains to enable different drivers and services for Bootloaders, optimizing them both for boot time, internal memory size constraints and power metrics. * Design, development and integration of custom and/or open source Bootloaders for QCT mobile platforms. * ThreadX, Linux, Android, Windows Boot process knowhow * UEFI (Unified Extensible Firmware Interface) based bootloader and device driver model experience * coreboot, uboot based bootloader experiences
The UEFI Forum likes to frame UEFI -vs- BIOS, and has a 3-5 Class heirarchy of those systems, including having to deal with UEFI systems that also provide BIOS via Compatibility Support Module (CSM), referring to BIOS as Legacy Mode. If you look at BIOS outside of the framing of the UEFI Forum, it is usually based security, and UEFI has some security where BIOS has none. But there’s another ‘class’: non-UEFI coreboot, optionally secured with Verified Boot, with a BIOS payload. UEFI Forum doesn’t include this in their Class heirarchy… AFAICT, the mainstream IBVs have given up on BIOS and migrated to UEFI. The only places where BIOS will probably remain are in Purism boxes, where they will use TPM+Heads to secure BIOS, or on Chrome boxes, where they will use coreboot Verified Boot to secure BIOS, or in SeaBIOS-based VMs. When Intel stops offering Intel’s implementation of BIOS, maybe this means that the remaining BIOS users will switch to the open source SeaBIOS project, which is great news. Getting rid of the complex class of dual UEFI/BIOS systems will be a joy. 🙂