coreboot 4.11 released

“[…]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.[…]”

Detailed blog post:
https://blogs.coreboot.org/blog/2019/11/19/announcing-coreboot-4-11/

coreboot 4.9 released

https://twitter.com/coreboot_org/status/1075809504556736512

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.[…]

Announcing coreboot 4.9

FWTS 18.11.00 is released

* 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

https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V18.11.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/18.11.00

Intel security guidance: Host Firmware Speculative Execution Side Channel Mitigation

[…]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.[…]

https://software.intel.com/security-software-guidance/api-app/insights/host-firmware-speculative-execution-side-channel-mitigation

more info:

https://software.intel.com/security-software-guidance/software-guidance

UefiPayloadPkg: UEFI Payload Project: supports Coreboot and Slim Bootloader

A freshly-created Github project:

https://github.com/BenjaminYou/UEFIPayload

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

ChromeBook CampFire?

https://twitter.com/coolstarorg/status/1028677996578660352

Everything we know about Campfire, Google’s secretive project to get Windows 10 running on Chromebooks.[…]

https://www.xda-developers.com/chromebooks-chrome-os-windows-10-dual-boot-apple-boot-camp-campfire/

 

Installing Coreboot on Lenovo X210

[…]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[1] motherboard porting guide and set to.[…]

https://mjg59.dreamwidth.org/50924.html

Lenovo should be giving Matthew a free X210 for this effort:

coreboot 4.8 released

https://www.phoronix.com/scan.php?page=news_item&px=Coreboot-4.8-Released

https://coreboot.org/releases/coreboot-4.8-relnotes.txt

https://mail.coreboot.org/pipermail/coreboot/2018-May/086729.html

https://mail.coreboot.org/pipermail/coreboot/2018-May/086757.html

https://mail.coreboot.org/pipermail/coreboot/2018-May/086700.html

Scaleway: Open Source BIOS at Scale

Open Source Bios at Scale
Julien Viard de Galbert

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.[…]

https://blog.online.net/2018/03/15/open-source-bios-at-scale/

Qualcomm seeks bootloader engineer

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

 

https://jobs.qualcomm.com/public/jobDetails.xhtml?requisitionId=1960693

AMI on Intel’s BIOS end-of-life announcement

 

https://ami.com/en/tech-blog/intel-says-bye-to-bios-by-2020/

Click to access Brian_Richardson_Intel_Final.pdf

 

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. 🙂