Intel Skylake release dates leaked

Jeff Thomas at Sage Engineering wrote a blog post yesterday on the new Intel Skylake board.

(Sage is an open source-friendly IBV, they focus on coreboot and Chrome OS, and know a lot more about AMD platforms than I know. Jeff is an active blogger, and a good source of industry news.)

https://www.se-eng.com/2015/07/intel-skylake-comes-out-swinging-aug-5-with-core-i7-and-core-i5-processors/

On a somewhat related note, from an open source OS-level perspective, Skylake has graphics that require non-free firmware blobs, which is IMO unfortunate:
https://01.org/linuxgraphics/intel-linux-graphics-firmwares
https://lists.debian.org/debian-x/2015/06/msg00039.html
https://www.phoronix.com/scan.php?page=news_item&px=Intel-SKL-BXT-Firmware-Blobs

 

FirmWare Test Suite 15.07.00 released

[Update: Colin King also blogged about this release:
http://smackerelofopinion.blogspot.com/2015/07/new-acpi-table-tests-in-fwts150700.html ]

Today Alex Hung of Canonical announced the latest release of FWTS, the FirmWare Test Suite.

Tar: http://fwts.ubuntu.com/release/fwts-V15.07.00.tar.gz
PPA: https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
Release Notes: https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.07.00

Changes to existing Features:
* –uefi and –acpi options renamed to –uefitests and –acpitests
* ACPI table tests in the acpitables test have been moved into specific ACPI tests.

New Features:
* acpi: acpidump: update TCPA table and acpidump accordingly
* acpi: add ACPI TCPA test
* acpi: add XENV table test
* lib: fwts_framework: Append “tests” to –uefi and –acpi
* live-image/fwts-frontend-text: update to –uefitests and –acpitests
* lib: acpi, acpidump: rename slit tables types
* lib: acpi: add in new GICC table fwts_acpi_table_gicc_affinity
* acpi: add SRAT table sanity checking (LP: #1464658)
* acpi: add BERT table sanity checking (LP: #1464712)
* lib: acpi: Add in GAS address types
* acpi: add ECDT table sanity checking (LP: #1464716)
* lib: acpi: Add support for the SPMI table
* acpi: add ACPI SPMI table sanity checking (LP: #1465256)
* acpi: add ACPI SLIT table sanity checking (LP: #1465276)
* lib: acpi: Add support for the HEST family of ACPI tables
* acpi: add ACPI HEST table sanity checking (LP: #1465379)
* acpi: Add BOOT table test (LP: #1465435)
* acpi: Add DBGP table test (LP: #1465441)
* acpi: Add DBG2 table test (LP: #1465710)
* acpi: re-orgainise HPET tests
* acpi: move MADT test from acpitables into new MADT test
* acpi: move GTDT test from acpitables into new GTDT test
* acpi: move XSDT test from acpitables into new XSDT test
* acpi: move RSDP test from acpitables into new RSDP test
* acpi: move RSDT test from acpitables into new RSDT test
* acpi: acpitables: remove no-op MCFG test
* acpi: move SBST test from acpitables into new SBST test
* acpi: move FADT test from acpitables into existing FADT test
* acpi: acpitables: remove redundant acpi table checking
* acpi: allow various ACPI table tests to run without root access
* lib: fwts_acpi_tables: fully pad out fixed up ACPI OEM IDs
* acpi: spcr: add missing white space in error messages
* acpi: add ACPI ERST test (LP: #1467835)
* acpi: correct ACPI BGRT table type
* acpi: add ACPI BGRT test (LP: #1467863)
* acpi: add ACPI CPEP test (LP: #1467870)
* acpi: add ACPI FACS test (LP: #1467966)
* acpi: acpidump: add in missing exponent field to SLIC
* acpi: add CSRT ACPI Table test (LP: #1470116)
* acpi: add LPIT ACPI test (LP: #1470184)
* acpi: add WAET ACPI table test (LP: #1470495)
* acpi: add SLIC table test (LP: #1470518)
* acpi: add MSDM table test (LP: #1470538)
* acpi: add UEFI ACPI data table test (LP: #1471698)
* bios: os2gap: remove ancient legacy test (LP: #1470573)

Fixed Bugs:
* acpi: acpidump: update SMM Communication fields on UEFI table
* lib: make acpidump parser more robust (LP: #1471202)
* fwts: cpufreq: fix theoretical division by zero (LP: #1466905)
* acpi: method: remove extraneous “_” in error message
* lib: fwts_klog: fix vector size and handle errors from pcre_exec (LP: #1461520)
* acpi: lib: fwts_acpi_tables: force fixup when loading tables from /sys/firmware
* lib: acpica: compiler: link in missing objects (LP: #1461936)

Two UEFI Form tools, plus one UEFI C Module complexity tool

UEFI has a “Browser”, and the browser shows various “Forms”. The browser is what you see when you get the OEM/IBV BIOS boot menu. OEMs/OBVs can reskin the browser, to add value, so the user experience will vary by vendor. In addition to the OEM/IBV, IHVs and ISVs can also add forms to a system’s browser. Each .efi binary contains resource strings, which get compiled into UEFI’s form language. The raw strings are IFR, Internal Forms Representation. The resulting view for the end user is VFR, Visual Forms Representation.  The UEFI browser is dynamic, you can programatically add new menu options by running an app. If you add foo.efi to your system, when you run the BIOS boot menu you may now see a new entry for the foo device, service, or application. For example, if you plug in a new device, that IHV’s config code will likely be now be in the BIOS boot menu. This is much nicer than having to run a DOS config.exe command (if you even have the ability to boot DOS), or boot into the vendor’s OEM firmware update CD (if they provide one).

At design-time, the EDK-II contains tools to build forms from source code. See TianoCore.org’s EDK-II tools and sample parsing code (in C and Python). Also see Intel SSG’s training courseware and labs, they have UI examples.

http://tianocore.sourceforge.net/wiki/EDK_II_Specifications
http://tianocore.sourceforge.net/wiki/EDK_II_Tools_List
http://tianocore.sourceforge.net/wiki/HII
http://sourceforge.net/projects/edk2/files/Training/TrainingMaterial/

At run-time, existing ROM images or .efi images may have an IFR in the binary. If you don’t have the source code, how do you evaluate the UI included, besides running it?

1) One tool is the “Universal IFR Extractor”, by Donovan6000. This tool can extract the internal forms representation from both EFI and UEFI modules and convert it into a human readable format. It is a Windows-centric tool, being an old-school native GDI GUI appplication written in C++. It may work on *nix via WINE, I’ve not tried it yet.

https://github.com/donovan6000/Universal-IFR-Extractor

2) Another tool is “Language applications for UEFI BIOS”, by William Leara. This was his University of Texas thesis; he is now a BIOS engineer at Dell. Besides the thesis, there is a github project with source code. He created an ANTLR grammar for VFR and a tool that gives an HTML preview of what the form would look like.

3) He also created an ANTLR grammar for UEFI-based C source code, and performs complexity analysis application uses general-purpose and domain-specific measures to give a complexity score to UEFI BIOS modules. This second tool isn’t form-centric, but it is also interesting, perhaps more interesting to some security researchers; it’s a good foundation to create more sophisticated tools of this kind, too…

https://github.com/WilliamLeara/LangAppUEFIBIOS
http://catalog.lib.utexas.edu/record=b8952762~S29
http://repositories.lib.utexas.edu/handle/2152/26306
http://www.basicinputoutput.com/p/aboutme.html

UEFI SMM vulnerability research: SmmBackdoor

Dmytro ‘Cr4sh’ Oleksiuk has been looking into Intel Systems Management Mode (SMM) on UEFI systems. Yesterday he posted a blog with some information on this research, along with some source code. Check out the blog post, it’s a very long document with lots of figures, very good reading.

More Information:

https://github.com/Cr4sh/SmmBackdoor
http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html

Apple Bitcode

At their recent annual developer conference, Apple mentioned ‘Bitcode’, a new bytecode technology that may give Apple some hardware independence options in the future.

“Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the App Store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the store. For iOS apps, bitcode is the default, but optional. If you provide bitcode, all apps and frameworks in the app bundle need to include bitcode. For watchOS apps, bitcode is required.

Will Bitcode show up on OSX or just be in iOS? Will Bitcode impact Apple firmware? Will Apple firmware use Bitcode instead of EBC (uEFI ByteCode)? I wish I knew, no answers just questions… 😦 Perhaps Bitcode will not impact Apple firmware, and this post is off-topic.

https://developer.apple.com/library/prerelease/watchos/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.html#//apple_ref/doc/uid/TP40012582-CH35-SW2

ARM update on GCC and Clang compilers

A few days ago, the ARM Software Dev Tools blog posted their 2015Q2 update on their use of Open Source Toolchains. The post talks about ARM changes in GNU GCC as well as LLVM. It appears they’re getting ready to present at GNU Cauldron in August. Look at their blog for more information. They’ve got some YouTube video and presentation slides, as well.

One thing this blog post clarified to me was what codebase ARM’s C compiler was based on: LLVM Clang:

“The commercial toolchain we offer to our customers, ARM Compiler 6, is in fact based on open source clang.”

More Information:
http://community.arm.com/groups/tools/blog/2015/06/30/open-source-toolchains–arm-status-update-q2-2015

Intel System Studio now targets FreeBSD

Intel System Studio (ISS) is a GUI IDE to build embedded systems. ISS normally is only available on Windows and Linux. Now it is also available on FreeBSD!

Intel® System Studio (ISS) 2016 for FreeBSD* Beta provides a comprehensive embedded tool suite solution for developing, optimizing, tuning and deploying 64-bit system and application C, C++ code running natively on FreeBSD* host systems. This product release includes the following components:

  • Intel® C++ Compiler 16.0 Beta for FreeBSD* systems
  • Intel® VTune™ Amplifier 2016 Beta for Systems for FreeBSD* Targets

ISS includes the Intel C Compiler, the only C Compiler that targets EBC, the EFI Byte Code. Normally ISS is a commercial-only product, but they sometimes have a shareware-style free edition available during beta periods. AFAIK, there is not a free version of Intel C Compiler.

Thanks to the FreeBSD News site for finding this information.

More Information:

https://www.freebsdnews.com/2015/07/01/intel-system-studio-2016-freebsd-beta/

https://software.intel.com/en-us/articles/intel-system-studio-2016-for-freebsd-beta-0

LibreTrend: new Linux OEM

As reported by Phoronix today, LibreTrend has partnered with Ubuntu Mate, to ship systems with Ubuntu Mate pre-installed. LibreTrend is a relatively new Linux OEM, they apparently launched last year in Portugal. LibreTrend joins the ranks of ThinkPenguin, System76, Purism, Novena, and a few others, OEMs that selling Linux-based systems. Quoting the press release with Ubuntu Mate:

LibreTrend are the designer and manufacturer of the LibreBox, a computer geared towards providing a complete “out of the box” Linux experience, with a heavy focus on hardware compatibility. All the hardware in the LibreBox is Free Software friendly and %100 supported by “blobless” Linux drivers.

The hardware behind this first LibreBox is based on the Intel 1037U Dual Core CPU. I’m not sure what firmware the LibreBox uses. I presume stock BIOS, not coreboot or UEFI.

Again, I don’t know what LibreTrend is doing with their firmware. Most Linux OEMs are merely taking commodity hardware made for Windows PCs, with stock BIOS, many blobs, fairly insecure compared to UEFI. (Novena is an exception, they’ve crowdsourced new Open Hardware development, and don’t use BIOS. Purism may also be exceptional, but I’ve yet to see specifics of what firmware they’re using.) Most other Linux OEMs are not exceptional w/r/t firmware, and could be be improved by using Intel FSP and coreboot, something that Sage Engineering, an open source BIOS vendor, does. That’d be more Open Source firmware (mostly Free Software-based) and fewer blobs than the default BIOS, which their Linux user audience would presumably prefer. Or they could ship a UEFI and get the additional security that Secure Boot brings to the OS; to help with their Linux user audience further, they could remove the Microsoft certs, something they could do as an OEM, or if they worked with their BIOS vendor. Intel and SuSE showed how to have a Microsoft key-free Linux system back at IDF 2013, yet AFAIK no OEM is selling hardware like this to the Linux community. Most Linux OEMs need to improve the firmware of their products.

I’m happy to see LibreTrend selling hardware with Free Software pre-installed, focusing on blobs at the Linux driver level. I hope they start building Open Hardware and use something beyond COTS BIOS, in future models, and also focus on blobs at the firmware level.

More Information:
http://www.libretrend.com/en/hardware
https://ubuntu-mate.org/blog/ubuntu-mate-hardware-partnership-with-libretrend/
http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Mate-Libre-Hardware

AMI announces NIST SP800-155-compatible UEFI

Today AMI announced an update for their Aptio V UEFI Firmware. For security perspective, this release is supposed to be compatible with NIST SP 800-155, BIOS Integrity Measurement Guidelines. Quoting an excerpt from their press release:

“In its Special Publication 800-155, NIST outlines the fundamentals of BIOS integrity measurement. This description includes a method to determine if the BIOS has been modified as well as the method for reporting and mitigating attacks against the BIOS. “These guidelines describe what is needed to establish a chain of trust for the BIOS,” commented Subramonian Shankar, President and CEO of American Megatrends. “In accordance with the NIST SP 800-155 guidelines, our Aptio V Firmware solution provides a means of generating and collecting the original BIOS measurements, called ‘the Golden Measurement Generation’, along with a means of storing the measurements that is either tamper-resistant or tamper-evident, called ‘the Collection Agent’ and a means of conveying the measurements to an analyzing agent, called the ‘Transmission and Reporting Agents’.” “Our goal in developing a NIST SP 800-155 compatible solution for Aptio V was to demonstrate to our customers that AMI is deeply committed to developing the most secure and tamper-resistant UEFI solutions available in the market today,” he commented.

I’m not sure if previous releases or other versions of AMI’s firmware products were/are SP800-155-compatible. Last time I looked at SP800-155, I thought it was still DRAFT, so I am not sure how that impacts compatibility.

On a nontechnical note, look at all the spaces that AMI uses in their press release URLs, yuck.

More Information:

http://ami.com/news/press-releases/?PressReleaseID=318&/American%20Megatrends%20Announces%20New%20Solution%20Compatible%20with%20NIST%20SP%20800-155%20%27BIOS%20Integrity%20Measurement%20Guidelines%27%20for%20Aptio%20V%20UEFI%20Firmware/
http://www.prnewswire.com/news-releases/american-megatrends-announces-new-solution-compatible-with-nist-sp-800-155-bios-integrity-measurement-guidelines-for-aptio-v-uefi-firmware-300107720.html

Apple EFI vulnerabilities: CVE-2015-3693 and CVE-2015-3692

From the security-announce@lists.apple.com announce list, Apple has an EFI update for multiple systems, available from the App Store. Two CVEs are listed:

APPLE-SA-2015-06-30-3 Mac EFI Security Update 2015-001

Mac EFI Security Update 2015-001 is now available and addresses the following:

EFI
Available for:  OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
Impact:  A malicious application with root privileges may be able to modify EFI flash memory
Description:  An insufficient locking issue existed with EFI flash when resuming from sleep states. This issue was addressed through improved locking.
CVE-ID
CVE-2015-3692 : Trammell Hudson of Two Sigma Investments, Xeno Kovah and Corey Kallenberg of LegbaCore LLC, Pedro Vilaca

EFI
Available for:  OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5
Impact:  A malicious application may induce memory corruption to escalate privileges
Description:  A disturbance error, also known as Rowhammer, exists with some DDR3 RAM that could have led to memory corruption. This issue was mitigated by increasing memory refresh rates.
CVE-ID
CVE-2015-3693 : Mark Seaborn and Thomas Dullien of Google, working from original research by Yoongu Kim et al (2014)

More Information:
https://support.apple.com/en-us/HT204934
https://lists.apple.com/mailman/options/security-announce/

coreboot gets Rockchip ‘Veyron Shark’ support

As reported today by Michael Larabel at Phoronix, coreboot recently got support for the Rockchip ‘Veyron Shark’ ARM SoC , used for Chromebook/Chromebox, with code from Google and Rock Chip.

To quote Phoronix:

“Julius Werner of Google’s Chromium team added the Veyron Shark mainboard into Coreboot Git. Shark is in turn is based off a copy of the Coreboot code for Veyron Speedy. Some of the code comes from Google while the rest is from Rockchip Inc. Rockchip’s latest chip series is the RK33xx that is based on an octa-core Cortex-A53 design with a GPU supporting OpenGL ES 3.1 and capable of HDMI 2.0 and 4Kx2K @ 60 FPS H.264/H.265 real-time video playback.”

Rock Chip nor coreboot didn’t didn’t consider this newsworthy, no press release. I’m grateful that Phoronix has such an efficient news gathering system, especially for tracking new features in coreboot.

More Information:

http://www.phoronix.com/scan.php?page=news_item&px=Veyron-Shark-In-Coreboot

NIST SCAP CVE-2014-4768: IBM UEFI vulnerability

[I posted this blog entry a few hours ago, then immediately deleted it, after noticing that that CVE was listed as 2014, not 2015, and thought my search was invalid. But I just re-checked, and the CVE is dated yesterday, 2015-06-28. So I was wrong to delete the post.]

There’s a new NIST SCAP CVE for IBM UEFI for some systems, involving remote attackers. An excerpt of the data is listed below, see below URLs for full release in case you have one of these IBM systems.

Vulnerability Summary for CVE-2014-4768
Original release date: 06/28/2015
Last revised: 06/29/2015
Source: US-CERT/NIST

“IBM UEFI on Flex System x880 X6, System x3850 X6, and System x3950 X6 devices allows remote authenticated users to cause an unspecified temporary denial of service by using privileged access to enable a legacy boot mode.”

More Information:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4768
http://www.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-5098278

PS: Related to firmware and SCAP, but unrelated to this specific CVE: AFAICT, nobody has SCAP OVAL definitions for UEFI, and no SCAP tools look for UEFI issues. Once SCAP has UEFI OVAL definitions, apps like CHIPSEC and Copernicus can start issueing SCAP reports with this metadata, so firmware bugs can be found with SCAP security tools, instead of full-text-search luck. So AFAICT there is no way to use SCAP to properly look for firmware issues, only full-text search and hope that that “UEFI” or “BIOS” or “firmware” are included. I wish (Intel, ARM, UEFI Forum, OpenPOWER, etc.) and other vendors and trade groups who maintain firmware code should also maintain their SCAP metadata, to help keep enterprises more secure. The ecosystem needs more help looking for hardware and firmware-level bugs, they know how to look for kernelspace and userland bugs.

HTTP Boot support in Tianocore

One new feature in UEFI 2.5 is HTTP Boot, an alternative to PXE-based TFTP booting. I’ve made 2 blog posts on it so far:

New UEFI HTTP Boot support in UEFI 2.5

More Info on UEFI 2.5 HTTP Boot Implementations

Right now, HP supports it, and Intel is adding an implementation to Tianocore. In the last day, it appears that Intel’s beginning to add their implementation to the EDK-II trunk. In the NetworkPkg, there are a few new directories, apparently mostly related to a new HttpBootDxe driver. For more information, look at the edk2-devel mailing list archives, or the EDK-II trunk in the NetworkPkg.

Vim syntax highlighting for EDK2 sources

If you use Vim, there are a few projects with syntax highlighting support for TianoCore sources and config files. A recent one, from this year:
https://github.com/fedorov7/vim-uefi
Two others from 2013, with different features from above one:
https://github.com/0xeuclid/UEFI_VIM_Syntax
https://github.com/0xeuclid/vim_for_UEFI

If you use Visual Slick Edit, one firmware engineer at Dell has created some files for EDK-II support:
http://www.basicinputoutput.com/2015/05/syntax-highlighting-for-edkii-files-dec.html

I found no support found for Emacs, perhaps the FSF anti-UEFI campaign has impacted this? I don’t know of any EDK-II support in any other open source programmer’s editors or IDEs.

Besides highlighting C/assembly sources, EDK2 has 7 different build/config files, much more complex than a single Makefile to deal with. The specs for these files are listed below; it would be nice if you spend time in EDK2 sources, if your editor helps you understand these formats.
http://sourceforge.net/projects/edk2/files/Specifications/

tool mini-review: UEFI Firmware Parser

Here’s a short review of “UEFI Firmware Parser”, a UEFi security/diagnostic tool by Teddy ‘theopolis’ Reed.

“The UEFI firmware parser is a simple module and set of scripts for parsing, extracting, and recreating UEFI firmware volumes. This includes parsing modules for BIOS, OptionROM, Intel ME and other formats. Features:
– UEFI Firmware Volumes, Capsules, FileSystems, Files, Sections parsing
– Intel PCH Flash Descriptors
– Intel ME modules parsing (for ARC5)
– Dell PFS (HDR) updates parsing
– Tiano/EFI, and native LZMA (7z) [de]compression
– Complete UEFI Firmware volume object heirarchy display
– Firmware descriptor [re]generation using the parsed input volumes
– Firmware File Section injection”

This package is actually three tools, not just one:

fv_parser.py is a UEFI Firmware Parser, which searches a file for UEFI firmware volumes, there are two other tools/scripts.

uefi_guids.py is another tool, which outputs GUIDs for files, optionally write GUID structure file, and will import GUID labels into IDA.

fv_injector.py is the GUID Injector, which replaces GUIDs on sections within a UEFI firmware file, or on UEFI firmware files within a firmware filesystem.

The tools are written in Python. It requires Python development headers, GCC, and the Python pefile library. To install, use the normal:

$ sudo python ./setup.py install

Usage:

$ python ./scripts/fv_parser.py -h
usage: fv_parser.py [-h] [–type {VARIOUS_TYPES}]
[-b] [-q] [-o OUTPUT] [-e] [-g GENERATE] [–test]
file [file …]
-h, –help            show this help message and exit
–type {VARIOUS_TYPES} Parse files as a specific firmware type.
-b, –brute           The input is a blob and may contain FV headers.
-q, –quiet           Do not show info.
-o OUTPUT, –output OUTPUT Dump EFI Files to this folder.
-e, –extract         Extract all files/sections/volumes.
-g GENERATE, –generate GENERATE Generate a FDF, implies extraction
–test                Test file parsing, output name/success.

$ python ./scripts/uefi_guids.py -h
usage: uefi_guids.py [-h] [-c] [-b] [-d] [-g GENERATE] [-u] file
-h, –help            show this help message and exit
-c, –capsule         The input file is a firmware capsule, do not search.
-b, –brute           The input file is a blob, search for firmware volume headers.
-d, –flash           The input file is a flash descriptor.
-g GENERATE, –generate GENERATE  Generate a behemonth-style GUID output.
-u, –unknowns        When generating also print unknowns.

$ python ./scripts/fv_injector.py -h
usage: fv_injector.py [-h] [-c] [-p] [-f] [–guid GUID] –injection INJECTION
[-o OUTPUT]
file
-h, –help            show this help message and exit
-c, –capsule         The input file is a firmware capsule.
-p, –pfs             The input file is a Dell PFS.
-f, –ff              Inject payload into firmware file.
–guid GUID           GUID to replace (inject).
–injection INJECTION Pre-generated EFI file to inject.
-o OUTPUT, –output OUTPUT Name of the output file.

More Information:

https://raw.githubusercontent.com/theopolis/uefi-firmware-parser/master/README.rst
https://github.com/theopolis/uefi-firmware-parser

Firmware Security document collection project on Github

I just noticed a new github project:

https://github.com/robguti/firmware_security_docs

It is a collection of PDFs about firmware security, mostly security conference presentations, gathered up into a single project.

It is unrelated to this blog, I don’t know the person who created the project.

Funny, I recognize about 1/3 of the collected files by their filenames. 🙂

Be sure to virus-check PDFs before you read them, who knows if malware has been added to to these.

Two Linux firmware articles

1) Linux Vendor Firmware Service launches

In a Phoronix article today, Michael Larabel describes the new Linux Vendor Firmware Service (LVFS) has been announced.

“This site provides a place for hardware vendors to submit packaged firmware updates, typically .cab files. This fire-and-forget service allows vendors to submit firmware updates without generating and hosting AppStream metadata themselves.”

More information:
https://beta-lvfs.rhcloud.com/
http://www.phoronix.com/scan.php?page=news_item&px=Linux-Vendor-Firmware-S
https://github.com/hughsie/fwupd

2) Intel on Linux firmware updates

Brian Richardson posted a blog yesterday, with information on Linux fwupdate, UEFI Capsule (firmware updates), UEFI 2.5 ESRT, and the Fedora firmware update mechanism.

More information:
http://blogs.intel.com/evangelists/2015/06/23/better-firmware-updates-in-linux-using-uefi-capsules/