coreboot adjusts release cycle

A while ago the coreboot project started to do 4 regular releases a year. It appears they are adjusting their release cycle plans a bit. Stefan Reinauer posted a message on the coreboot list with information about this schedule/cycle change, including a long FAQ. Excerpt of Stefan’s message:

“However, releases take a lot of time, and we were not able to tighten the release process with each release, as we had originally hoped, and so, after I talked with Patrick and Martin, we have decided to move to a slightly slower paced release cycle, creating only two releases per year. In turn, we will try to improve the overall quality of the releases in the future. This switch will mean, that the coreboot 4.5 release will happen in fall 2016, rather than this month.”

More info:
https://www.coreboot.org/pipermail/coreboot/2016-July/081677.html

coreboot GSoC updates (RISC-V, FlashROM, SerialICE)

Wow, the coreboot blog is busy, a lot of GSoC activity to catch up to!

Jneuschaefer is doing RISC-V updates to coreboot….

[GSoC] Better RISC-V support, week #2

[GSoC] Better RISC-V support, week #2

[GSoC] Better RISC-V support, week #3

[GSoC] Better RISC-V support, week #3

Hatim Kanchwala is working on FlashROM…

[GSoC] Multiple status register support, week #1 and #2
http://blogs.coreboot.org/blog/2016/06/07/gsoc-multiple-status-register-support-week-1-and-2/

Antonello Dettori is working on SerialICE:

[GSOC] Panic Room, week #2

[GSOC] Panic Room, week #2

coreboot GSoC update: RISC-V and SerialICE

The last two blog posts on the coreboot blog are by two students working on their Google Summer of Code (GSoC) project. Both sound very interesting.

Jonathan Neuschäfer is improving coreboot’s support for RISC-V platforms, which was initially added in 2014.

Antonello Dettori is working on improving SerialICE, “which is one of the main tools used in reverse engineering an OEM BIOS”, including coreboot integration.

More information:

[GSoC] Better RISC-V support, week #1

[GSOC] Panic Room, week #1


http://coreboot.org/
https://www.serialice.com/GSoC
https://riscv.org/

coreboot 4.4 released!

coreboot version 4.4 has been released, which includes 850 commits by 90 authors added 59000 lines to the codebase since their last quarterly release. This release includes OpenPOWER support and experimental U-Boot payload support. It also has an Intel ME tool which is new (at least to me). There are many other changes, excerpting their announcement:

Significant changes:
* Build system (30 commits) – Add postcar stage, ‘timeless’ builds, extend site-local, test toolchain by version string, update dependencies, catch ACPI errors, l add additional macros.
* Toolchain updates (40+ patches) – Update IASL to v20160318 , LLVM to v3.7.1, add GNU make, add nds32le GCC compiler
* Lint tools (30 patches) – Update existing lint utilities, add lint tests for executable bit, make sure site-local isn’t committed, add test to break all lint tests.
* Payloads (60 commits) – Fixes for libpayload, coreinfo and nvramcui, add new payloads, see below.
* Maintainers file – (8 patches) – continue adding maintainers for various areas.
* Documentation for adding Intel FSP-based platforms (20 commits)

New architectures:
* power8
* qemu-power8

New payloads:
* depthcharge: For ChromeOS verified boot
* iPXE: For network booting
* Memtest86+: Updated with fixes for correctly testing coreboot with payloads
* U-Boot (Experimental): Alternate payload for booting an OS

New/updated mainboards:
* asus/kcma-d8
* emulation/qemu-power8
* google/auron_paine
* google/gru
* intel/amenia
* intel/apollolake_rvp
* intel/camelbackmountain_fsp
* intel/galileo
* lenovo/t420
* asus/kgpe-d16
* google/oak
* google/chell
* intel/kunimitsu

New/updated socs:
* intel/apollolake
* intel/fsp_broadwell_de
* intel/quark
* marvell/armada38x
* rockchip/rk3399
* cpuamd/mct_ddr3
* drivers/intel/fsp2_0
* northbridge/intel/sandybridge/raminit
* soc/intel/apollolake
* soc/intel/fsp_baytrail
* soc/intel/skylake
* soc/mediatek/mt8173

New vendorcode directories:
* siemens

New/updated submodules:
* chromeec
* 3rdparty/arm-trusted-firmware (329 commits)
* 3rdparty/vboot (28 commits)
* util/nvidia/cbootimage (13 commits)

New/updated Utilities:
* archive – Concatenates files into a single blob with an indexed header
* chromeos – Download and extract blobs from a ChromeOS image
* futility – vboot Firmware utility
* intelmetool – Shows information about the Intel ME on a platform.
* marvell/doimage_mv – No usage notes
* post – Simple utility to test post cards

Full announcement:

Announcing coreboot 4.4


https://www.coreboot.org/releases/

coreboot convention June 13-16, San Francisco

A coreboot convention is in the works for this June in San Francisco area! Excerpt from announcement:

We are going to hold a 4 day coreboot convention in San Francisco, CA, Monday June 13 – Thursday June 16. Google has agreed to host two very nice conference rooms for those 4 days and we are also working to get a block of rooms in a nearby hotel for a reasonable rate.

We plan for two days of talks structured talks, followed by two days of informal discussion and classes. We will have the smaller room open for hacking all four days. We’ll provide flashing equipment and other useful tools; let us know what you need.

There will be a fee for this convention – $250 for corporate employees and $100 for students or individual contributors.  If this is an issue, please let us know on the form and we’ll work with you on a fee waiver.

We have set up an outing on Tuesday night to the Long Now Foundation for the first 40 paid registrations (Long Now has space limits) and we’re working on a visit to a local Hackerspace.

Whether you are part of the Open Source community, working for a silicon vendor supporting coreboot already, or are just interested in getting some hands on experience, our goal is to make this an interesting and valuable meeting for all of us.  You are welcome to present talk proposals and subject areas you think we should cover. We will be having a talk on RISC-V from Andrew Waterman of SiFive, classes by senior members of the community, and discussions on future directions.

Full announcement:
https://www.coreboot.org/pipermail/coreboot/2016-March/081010.html
http://goo.gl/forms/f8uqHHFL2S.
https://www.coreboot.org/Coreboot_conference_San_Francisco_2016

coreboot update

The coreboot project posted their regular project status update. In the last two week period, there have been: 105 commits by 25 authors, adding 13K and removing 3K lines of code. There were updates for multiple boards and chipsets, including Intel Galileo board and Quark chip, Intel Sandy Bridge/Ivy Bridge, Intel Skylake, Intel Bay Trail, Intel Apollo Lake, ARM ARM7 QEMU board, QEMU POWER8, and RISC-V. There were also updates to ARM Trusted Firmware and Verified Boot. Excerpting the announcement:

Payloads got some attention during this period, adding a way to include additional modules into the GRUB2 build. An option was added to build and include coreinfo as a ‘secondary’ payload, allowing it to be run from another payload. We also added U-Boot as a coreboot payload. This is currently still just in development, and needs additional work before it will act as a generic payload for all platforms.

We added LZ4 compression to the build with runtime decompression for cbfs. LZ4’s speed should be roughly the same as LZMA, trading a smaller compressed size for slightly slower decompressoin. LZ4’s main advantage is that it requires much less memory to do the decompression, allowing for compression of stages that couldn’t previously be compressed.

The suite of board-status scripts got several updates, fixing timestamp handling for the sanitized path names, handling when the script is run as super-user in a better way, and adding a script that will set up a Ubuntu Live-image to allow users to more easily run the board-status script.

In the build tools and utilities, we had some fixes for the toolchain builder, updating the GDB builds for x86_64 and MIPS. A couple of scripts were also added. One utility downloads and extracts binary blobs from Chrome OS recovery images, and the other new script allow easier testing of POST cards.

It is always hard to excerpt coreboot blog posts, they have a lot of good data which I’ve omitted. Full post:

coreboot changelog Feb 17 – March 1

Coreboot adds U-Boot as a Payload

Michael Larabel of Phoronix reports that Coreboot now supports U-Boot as another payload option:

Coreboot users have generally relied upon the SeaBIOS or TianoCore payloads for booting up into a Linux distribution, but now a U-Boot payload is supported as another option. Intel-based Chromebooks have long been using U-Boot as a payload for Coreboot while now all of that support is going upstream. A commit today adds U-Boot as a possible payload for x86 systems when configured via the new Kconfig options. The commit by Google’s Martin Roth explains, “Graphics worked in U-Boot correctly by initializing the VBIOS and setting up a console mode. Tested in QEMU and on Minnowboard Max.”

More information:

http://www.phoronix.com/scan.php?page=news_item&px=Coreboot-U-Boot-Payload

http://anzwix.com/a/Coreboot/PayloadsAddUBootAsACorebootpayload

coreboot update

The coreboot project does regular blog posts on their project status, which is very nice. (By comparison, the UEFI Forum doesn’t do any such status updates of their Tianocore EDK-II codebase. Neither does the U-Boot project, AFAICT. For all 3, you can track their source tree, and for UEFI you can track their occasional spec updates. But coreboot’s status updates make it a lot easier to see what is happening with the project, without reading source deltas and sifting through threads of checkin emails.)

Last week, coreboot just released version 4.3. The current blog post mentions that version 4.4 is expected towards the end of April. In the last week, they had 30 authors — including 8 new authors! — with 131 commits. A brief excerpt from their blog post, on board support changes during last week:

“We had significant updates to a number of mainboards and the related chipsets in the past week as well. Intel had a large number of changes for their Braswell SoC and its reference board, Strago, merged this week. These included fixes for GPIOs, clocks, SD cards, and thermal support, as well as FSP integration updates. The Asus kgpe-d16 mainboard, along with the AMD Fam10h-Fam15h processor directory and the SB700 soutbridge had numerous patches to improve stability, fix IRQ routing and APIC identification, and improve ACPI. The winbond w83667hg-a was added to the coreboot codebase for the board as well. The Intel d510mo board had some improvements related to native graphics initialization, GPIOs and ACPI. The gigabyte ga-g41m-es2l and the Intel x4x northbridge code had some general cleanup and improvements to cbmem and memory initialization. We also saw the introduction of the initial framework for the new Intel Apollo Lake SoC. We’ll be seeing many more patches related to Apollo Lake in the coming weeks. Other changes of note included code to initialize the PS/2 aux port, a way to access memory address 0 without GCC “optimizing” it into a crash, and the addition of some documentation from Intel about developing new FSP based boards and chipsets. Finally, the Intel sklrvp Skylake reference board was dropped in favor of using the kunimitsu board.”

Full post:

coreboot changelog Jan 27 – Feb 2

coreboot 4.3 released

Patrick Georgi of the coreboot project has announced version 4.3 of coreboot! There are too many changes for me to excerpt the release, so I’m including most of the announcement below, with some minor whitespace editing:

Since the last release, 1030 commits by 114 authors added a net total of 17500 lines to the source code. Thank you to all who contributed! Besides the usual addition of new mainboards (14) and chipsets (various), a big theme of the development since 4.2 was cleaning up the code: 20 mainboards were removed that aren’t on the market for years (and even hard to get on Ebay). For several parts of the tree, we established tighter controls, making errors out of what were warnings (and cleaning up the code to match) and provided better tests for various aspects of the tree, and in general tried to establish a more consistent structure across the code base. Besides that, we had various improvements across the tree, each important when using the hardware, but to numerous for individual shout outs. Martin compiled a list that’s best posted verbatim. Thanks Martin!

Added 14 mainboards:
– asus/kfsn4-dre_k8: Native init Dual AMD K8 CPUs & Nvidia CK804 southbridge
– esd/atom15: Bay Trail SOC mainboard using Intel’s FSP
– gigabyte/ga-g41m-es2l: Intel Core 2 / Native init x4x NB / I82801GX SB
– google/guado: Intel Broadwell chromebox (Asus Chromebox CN62)
– google/oak: Mediatek MT8173 SoC chromebook
– google/tidus: Intel Broadwell chromebox (Lenovo ThinkCentre Chromebox)
– google/veyron_emile: Rockchip RK3288 SoC board
– intel/d510mo: Native init Intel Pineview with Intel I82801GX southbridge
– intel/littleplains: Intel Atom c2000 (Rangeley) SoC board
– intel/stargo2: Intel Ivy Bridge / Cave Creek usint Intel’s FSP
– lenovo/r400: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB
– lenovo/t500: Intel Core 2 / Native init GM45 NB / Intel I82801IX SB
– purism/librem13: Intel Broadwell Laptop using Intel MRC
– sunw/ultra40m2: Native init Dual AMD K8 Processors & Nvidia MCP55 SB

Removed 20 mainboards:
– arima/hdama
– digitallogic/adl855pc
– ibm/e325, e326
– intel/sklrvp
– iwill/dk8s2, dk8x
– newisys/khepri
– tyan/s2735, s2850, s2875, s2880, s2881 & s2882
– tyan/s2885, s2891, s2892, s2895, s4880 & s4882

Improvements to mainboards:
– amd/bettong: fixes to Interrupts, Memory config, S4, EMMC, UARTS
– asus/kgpe-d16: IOMMU and memory fixes, Add CMOS options, Enable GART
– intel/strago: GPIO, DDR, & SD config, FSP updates, Clock fixes
– ACPI fixes across various platforms
– Many individual fixes to other mainboards
Continued updates for the Intel Skylake platform
– google/chell, glados, & lars: FSP & Memory updates, Add Fan & NHLT support
– intel/kunimitsu: FSP & GPIO updates, Add Fan & NHLT (audio) support

Build system:
– Update build to use FMAP based firmware layout with multiple cbfs sections
– Enable Kconfig strict mode – Kconfig warnings are no longer allowed.
– Enable ACPI warnings are errors in IASL – warnings are no longer allowed.
– Tighten checking on toolchains and give feedback to users if there are issues
– Updates to get the ADA compiler to work correctly for coreboot
– Various improvements to Makefiles and build scripts
– Cleanup of CBFS file handling

Utilities:
– cleanups and improvements to many of the utilities
– cbfstool: Many fixes and extensions to integrate with FMAP
– Add amdfwtool to combine AMD firmware blobs instead of using shell scripts.
– Toolchain updates: new versions of GMP & MPFR. Add ADA.
– Updates for building on NetBSD & OS X

Payloads:
– SeaBIOS: Update stable release to 1.9.0
– coreinfo: fix date, hide cursor, use crosscompiler to build
– libpayload: updates for cbfs, XHCI and DesignWare HCD controllers

ARM:
– Added 1 soc: mediatek/mt8173
– Various fixes for ARM64 platforms

X86:
– Added 2 northbridges: intel/pineview & x4x
– Removed 1 northbridge: intel/i440lx
– Added 1 southbridge: intel/fsp_i89xx
– Removed 2 southbridge(s): intel/esb6300 & i82801cx
– Rename amd/model_10xxx to family_10h-family_15h.
– ACPI: fix warnings, Add functions for IVRS, DMAR I/O-APIC and HPET entries
– Work in many areas fixing issues compiling in 64-bit
– Numerous other fixes across the tree
Areas with significant work on updates and fixes
– cpu/amd/model_fxx
– intel/fsp1_x: Fix timestanps & postcodes, add native CAR & microcode
– nb/amd/amdfam10: Add S3, voltage & ACPI, speed fixes & MANY other changes
– nb/amd/amdmct: Add S3, mem voltage, Fix performance & MANY other changes
– nb/intel/sandybridge: Add IOMMU & ACPI DMAR support, Memory cleanup
– soc/intel/braswell: FSP & ACPI updates, GPIO & clock Fixes
– soc/intel/fsp_baytrail: GPIO, microcode and Interrupt updates.
– soc/intel/skylake: FSP, Power/Thermal & GPIO Updates, Add NHLT support
– sb/amd/sb700: Add ACPI & CMOS Setting support, SATA & clock Fixes

MIPS:
– Imgtec Pistachio: Memory, PLL & I2C fixes, add reset

SuperIO:
– Expand functionality for ite/it8718f & nuvoton/nct5572d superio devices
Added 3 SIOs
– intel/i8900
– winbond/w83667hg-a & wpcd376i
Removed 6 SIOs
– fintek/f71889
– ite/it8661f
– nsc/pc8374 & pc97307
– nuvoton/nct6776
– smsc/fdc37m60x

Lib:
– Several updates for reading EDID tables

MISC:
– Commonlib: continued updates for cbfs changes
– Work on getting license headers on all coreboot files
– Drop the third paragraph of GPL copyright header across all of coreboot

Submodules:
3rdparty/blobs: Update to CarrizoPI 1.1.0.1 (Binary PI 1.5)

Full announcement:

Announcing coreboot 4.3

 

coreboot update

coreboot is nearing it’s 4.3 release. Their last post shows stats of project activity for a single week this month, especially 36 contributors, 11 of them new. The week before there were 13 new contributors!

– Total commits: 111
– New authors: 11
– Total authors: 36
– Total lines added: 10885
– Total lines removed: -604
– Delta: 10281

Two new mainboards – the Google Tidus board (Lenovo ThinkCentre Chromebox), and the Purism Librem 13 laptop are added.

There’s even Ada compiler support added to the toolchain. There are many other changes, not mentioned here, see the full post:

coreboot changelog Jan 20 – Jan 26

Libreboot introduction and Lenovo X60/X200 tutorial

There’s a talk from Kyle Rankin of Final Inc, on using Libreboot. It covers coreboot, Intel ME, Intel AMT, and covers replacing Lenovo X60 and X200 firmware with Libreboot, as well as covering use of Arduino as part of the reflashing solution.

https://twitter.com/lordbaco/status/691711050727702532

http://greenfly.org/talks/security/libreboot.html

https://github.com/bibanon/Coreboot-ThinkPads/wiki/Hardware-Flashing-with-Raspberry-Pi

Wikipedia’s BIOS security roadmap

You’d think that with a blog called ‘firmware security’, I’d know about the ‘Wikipedia BIOS feature comparison’ page. But I did not, sad. 😦  The other day I was wishing someone would create a comparision of BIOS implementations and their security features. Luckily, Kevin O’Conner of the SeaBIOS project was kind enough to point this out to me, when I was looking for a SeaBIOS security roadmap:

https://en.wikipedia.org/wiki/BIOS_features_comparison

I’ve been learning more about SeaBIOS, and am impressed with it’s features. I wonder why some Linux OEMs still ship closed-source BIOS systems from IBVs? Given their audience demographic, you’d think they’d be using Linux-based coreboot, and on x86/x64 systems using SeaBIOS. They could be using coreboot Verified Boot + SeaBIOS’s TPM support for a much more secure than they are today. If you’re buying a System76 or ThinkPenguin or other Linux-centric site, ask them what firmware solution they’re giving you.

Why no ExitRunTimeServices() for UEFI?

The other week, at the 3rd RISC-V Workshop, there were 2 firmware presentations, coreboot and UEFI, pitching their solution for the new RISC-V chip.

One point mentioned in the coreboot presentation that seems worth raising here on a firmware security blog: the distinction between firmware that fully exits -vs- firmware that stays resident while the operating system runs. An interesting way to frame it.

Click to access Tues1345%20riscvcoreboot.pdf

Starting with the IBM PC’s BIOS, Intel systems have had firmware that runs in the background. The OS or an ap would issue a BIOS (or DOS) interrupt, and the BIOS responded to low-level interrupts, like Int 13h for disk, 10h for video, etc. On original PCs, IHVs extended BIOS via Option ROMs via the same extensibility method that IBM PC-DOS ‘services’ (TSRs, ‘terminate and stay resident’) used: hook an interrupt and replace it with yours. So, BIOS is kind of a ‘terminate and stay resident’ firmware.

UEFI uses the same model, presuming firmware to be present in background for OS to call, the resident portion are called UEFI RunTime Services. Once the operating system initializes, it calls UEFI’s ExitBootServices() function, which terminate most — but not all — of UEFI, discarding the init code and only keeping the runtime service code.

http://wiki.phoenix.com/wiki/index.php/EFI_BOOT_SERVICES#ExitBootServices.28.29

Coreboot — and U-Boot — initialize the hardware, but do not stay resident. However, on Intel systems, use of a BIOS payload in coreboot, eg, SeaBIOS, will result in that BIOS payload staying resident, responding to BIOS interrupts that the OS (or an app) may call.

So, the resident -vs- nonresident firmware seems to be tied to Intel -vs- non-Intel: coreboot on ARM for example has no SeaBIOS payload, and RISC-V likey won’t use an Intel-centric BIOS payload.

As the coreboot presentation points out, the resident firmware is an additional attack vector, UEFI has a larger surface than coreboot — or U-Boot — due to UEFI Runtime Services. UEFI currently only  has the option to terminate Boot Time Services — via ExitBootServices(). I wonder if UEFI could have an additional mode, with an ExitRuntimeServices(), that could make UEFI competitive with coreboot/U-Boot w/r/t attack surface? That could be interesting.

AMD, Zen, and coreboot

There is speculation about AMD support of coreboot on Zen systems:

http://techfrag.com/2016/01/11/exclusive-amd-wont-support-coreboot-for-new-zen-processors/

“However, one thing we’re still confused about is whether the next-gen platform will support Coreboot as an optional open-source firmware to replace the proprietary UEFI/BIOS.”

http://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-Will-It-Coreboot

“More worrying about the prospects for Coreboot on future hardware is that since the end of 2014, AMD stopped providing open-source AGESA code. AGESA releases by AMD are now binary-only, with this being the bootstrap protocol needed to initialize AMD processor cores, memory, and HyperTransport. Binary AGESA is similar to Intel not opening up their firmware support packages.”

From an email-based interview I did with AMD’s firmware engineer, I get the impression that AMD has chosen UEFI as it’s main firmware, and coreboot is part of the AMD embedded team’s options:

AMD clarifies firmware strategy

AMD’s evolution from legacy BIOS to UEFI has happened over the last ten years in sync with the schedules of our industry partners (IBV’s, OEM’s) and their code bases.  We’re not seeing any demand for legacy BIOS enablement anymore, so we no longer focus any effort there.  Coreboot is the only remaining legacy code base we enable.  Coreboot enablement is provided by AMD’s embedded group for a market-appropriate subset of our chips.