Project ONIE: UEFI support, and Firmware Update Mechanism

Yesterday Curt Brune of Cumulus Networks announced the latest release of Project ONIE, by the Open Compute Project:

This release contains a number of new hardware platforms, along with the usual enhancements and bug fixes. Some firmware excerpts from the announcement:

Documentation:
Updated x86 design specification to cover UEFI support:
https://github.com/opencomputeproject/onie/wiki/Design-Spec-x86-UEFI

Support for UEFI firmware machines:
42c7448 UEFI: initial support for ONIE on UEFI
a16e630 kvm_x86_64 vm: Update INSTALL instructions for UEFI

Firmware Update Mechanism:
a8e712b pending firmware update discovery mechanism
477cd47 x86 firmware update: add onie-fwpkg CLI tool

More Information:

https://github.com/opencomputeproject/onie/releases/tag/2015.08
http://lists.opencompute.org/pipermail/opencompute-onie/2015-August/000840.html

Using FreeBSD, ZFS, and UEFI

Jashank Jeremy wrote an article on using FreeBSD, ZFS, GPT, and UEFI, on a 64-bit system.

Apparently, the trick to is to use GRUB’s kFreeBSD mode. Full information here:

Hmm, WordPress imbeds the entire source file listing of a Git.Github URL. So I’m splitting this URL, you’ll have to combine it yourself:

https://
gist.github.com/jashank
/9ec2f72126552068434c

Also check out the reply from Felix Khrohn on Jashank’s Twitter post, with an URL to alternative method by Ganael Laplanche.

Immunity: free Infiltrate tickets for improving BinNavi

Dave Aitel of Immunity has announced free tickets to Infiltrate for people who can improve the recently-opensourced BinNavi project:

INFILTRATE Contests: BINNAVI
Every year, from HackCup to various coding challenges, we like to think of unique ways you can join us at THE BEST SECURITY CONFERENCE here in Miami next April 7th and 8th. We are starting this year with two new contests now that BinNavi is Open Sourced: 1) If you and your friends add Capstone (or another disassembler/analyzer) to BinNavi, to remove the IDA requirement, then we will send you three free tickets to INFILTRATE 2016! 2) If you and your friends integrate a decompiler with BinNavi, then we will also send you three free tickets to INFILTRATE 2016! If you do both, you get six free tickets to INFILTRATE.

Details:
https://lists.immunityinc.com/pipermail/dailydave/2015-August/000987.html

Intel/UA/Turner 2016 TV: America’s Greatest Makers

As mentioned by Brian Richardson, Intel is teaming with United Artists Media Group to do a Maker-centric TV show. The ‘casting call’ is open.

Intel, United Artists Media Group, and Turner Broadcasting System are bringing a national makers’ challenge to television in 2016. “America’s Greatest Makers (working title) is coming to television in 2016. Are you ready to build the next truly amazing device? Bring your big ideas to life with Intel, in collaboration with United Artists Media Group, and Turner Broadcasting System. Competitors will vie for $1 million in prizes and the opportunity to bring their creations to market.”

Full announcement:
https://www-ssl.intel.com/content/www/us/en/wearables/americas-greatest-makers.html

I hope some Open Hardware and Free Hardware people turn out for the casting call. I hope some employees from Bunnie Studios, Purism, Inverse Path, and FSF, and some students at USB (RISC-V) and Wisconsin (MIAOW GPU) consider trying out. It appears participants must be US citizens 15 years or older, with max of 4 people per team.

Since it’s just a working title, I think they should rename it to be “Greatest American Makers”. I’m running late today, so please Insert your own “Greatest American Hero” TV joke here. 🙂

JTAGulator

Parallax announces JTAGulator:

https://www.parallax.com/product/32115?utm_content=bufferca961&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

Designed by Grand Idea Studio, JTAGulator is an open source hardware tool that assists in identifying OCD connections from test points, vias, or component pads on a target device.

The product is currently on sale for the next few days, 15% off until 2015-08-31 (US$136 instead of US$160).

USAF top10 embedded security recommendations

Mark Pomerleau of Defense Systems wrote an article which points out a new US Air Force study on embedded systems security.

http://defensesystems.com/articles/2015/08/27/air-force-embedded-systems-cyber-threat.aspx

“Cyber Vulnerabilities of Embedded Systems on Air and Space Systems”

Click to access AF%20SAB%20embedded%20systems%20cyber.pdf

The study recommends 10 things, and firmware security is on top of that list:

0) Ensure software integrity by employing digital signatures/code signing, and require future systems to cryptographically verify all software/firmware as it is loaded onto embedded devices.
1) Mandate the inclusion of software assurance tools/processes and independent verification and validation using appropriate standards as part of future contracts for all USAF systems. Use best commercial code tools and languages.
2) Employ hardware/software isolation and randomization to reduce embedded cyber risk and improve software agility even for highly-integrated systems.
3) Improve and build USAF cyber skills and capabilities for embedded systems.
4) Adapt Air Force Life Cycle Management Center cyber-resiliency requirements process to embedded systems.
5) Protect design/development information. Implement security procedures sufficiently early that protection against exfiltration and exploitation is consistent with the eventual criticality of the fielded system.
6) Develop situational awareness hardware and analysis tools to establish baseline embedded operational patterns and inform best mitigation strategies.
7) Develop and deploy continuously verifiable software techniques (such as dynamic attestation).
8) Develop and deploy formal-method software assurance tools and processes specific to USAF embedded systems.
9) Work with defense microelectronics agencies to deploy trusted methods compatible with off-shore manufacturing.

If you updated this list to removed the USAF references, most of this advice would directly apply to commercial sector’s embedded OEMs and IoT Makers. However, existing security best practice guidelines and certification programs do NOT have anything on firmware, and they really need to improve their offerings.

 

new EFI-based operating systems

EFI started as a boot loader solution for Intel Itanium systems. It has grown into UEFI, a boot loader solution for multiple architectures.

However, in my opinion, UEFI is an operating system. It has driver, service, and app models. If you don’t load another OS (eg, Windows, Linux) , and stay in UEFI, the UEFI Shell is pretty much like early MS-DOS: a shell, a  bunch of command line tools, and a handful of full-screen tools (edit, hexedit). UEFI is called “the new DOS” for a reason… MS-DOS didn’t have Python either. The main thing missing is an EFI equivalent to DEBUG.COM. 🙂

Now there are a handful of new UEFI-centric OSes being created. It appears they’re mostly hobbyist, educational projects. There may be others, these are the only ones I know of so far:

https://github.com/kmmoore/mosquitos
https://github.com/whisper-bye/LuminOS
https://github.com/nerdshark/simplix
https://github.com/segfo/myOSwithUEFI
https://github.com/skylerseverns/elementary-os-freya-uefi

I look forward to future academic research in this area. I am wondering if there are any existing hardware vendors who’re using UEFI as the only software stack, not using other embedded OSes? Someone needs to do some performance testing to see how it compares to eLinux/Android/NanoBSD/etc.

MIAOW and Raven3 at HotChips

HotChips ended this week. As mentioned in the last post on this event:

RISC-V Raven processor talk at HotChips

not only is the Open Source ISA RISC-V there, but so was an Open Hardware GPU, MIAOW (Many-core Integrated Accelerator of Wisconsin):

http://www.miaowgpu.org/

https://github.com/VerticalResearchGroup/miaow

Rick Merritt of EE Times has written a new articles on both the RISC-V ISA and MIAOW GPU:

http://www.eetimes.com/document.asp?doc_id=1327543

Preparing for Android firmware updates

Kris Carlon of AndroidPIT has written an article for end-users to help them prepare for a system update for their Android phones. Not bad advice to give to your non-technical friends:

https://www.androidpit.com/what-to-do-before-an-android-update

On UEFI-based systems, like Intel-based Android-IA systems, I’d add:

  • save your ROM with before the update, and again after the update, booting LUV-live and using CHIPSEC.

For ARM-based systems, I wish that ARM had both AArch32 and AArch64 ports of CHIPSEC. Linaro may be porting CHIPSEC to AArch64 as part of LUV. But Linaro seems more focused on AArch64 these days, so AArch32 systems may not have security tools. For x86, there’re extensive bibliographies by LegbaCore and other security researchers on x86 BIOS/UEFI vulnerabilities, but I’ve hard a hard time finding a similar list of ARM vulnerabilities. I presume that’s because most are hidden behind iOS/Android-centric vulnerability, and other ARM-based embedded devices, with the various ARM vendor variations. If there was security data for ARM users to watch for, then the community could help ARM/Linaro with the CHIPSEC ports.

OpenSource.com on Open Hardware

There’s an article on Opensource.COM about Open Hardware:
http://opensource.com/resources/what-open-hardware

Opensource.ORG is the OSI, the group that maintains Open Source licenses. I’m unclear what the opensource.COM site is, except that Red Hat owns it, and it may be related to OSI. Regardless, the document is worth reading. OSI signed a MOU with one of the Open Hardware license orgs, OSHWA:
http://opensource.org/node/640

The Wikipedia page on Open Hardware also has pointers to licenses:
https://en.wikipedia.org/wiki/Open-source_hardware#Licenses

Intel IDF post-conference materials

Intel Developer Forum ended the other week:

Firmware at Intel Developer Forum

The other day I posted a pointer to a Redfish/UEFI HTTP Boot talk at IDF, and commented that I wish I could find the video. A kind reader showed me how to navigate the cryptic IDF archive site:

http://myeventagenda.com/sessions/0B9F4191-1C29-408A-8B61-65D7520025A8/7/5

The search function on that page works well, eg filtering on firmware. There are PDF and A/V links to many of them!  IDF had 200 talks, many of them interesting to firmware security. For example, here’s the talk on Redfish from yesterday:

http://myeventagenda.com/sessions/0B9F4191-1C29-408A-8B61-65D7520025A8/7/5

VirtualBox 5.02 released

A few days ago Oracle released a new version of VirtualBox. It is a maintenance release, no huge new features I noticed, but lots of bugfixes, many related to hardware security issues, though no CVEs that I noticed.

https://blogs.oracle.com/virtualization/entry/oracle_vm_virtualbox_5_08

https://www.virtualbox.org/wiki/Changelog

 

GRSecurity quits

https://twitter.com/grsecurity/status/626915991184932865

and:

https://twitter.com/grsecurity/status/636659374551777281

Today’s announcement:

https://grsecurity.net/announce.php

Excerpt:

“This announcement is our public statement that we’ve had enough. Companies in the embedded industry not playing by the same rules as every other company using our software violates users’ rights, misleads users and developers, and harms our ability to continue our work. Though I’ve only gone into depth in this announcement on the latest trademark violation against us, our experience with two GPL violations over the previous year have caused an incredible amount of frustration. These concerns are echoed by the complaints of many others about the treatment of the GPL by embedded Linux industry in particular over many years.”

DejaVu from 2004:

http://developers.slashdot.org/story/04/05/31/1949241/end-of-development-for-grsecurity-announced
“Beginning today, May 31, 2004, development of grsecurity will cease. On June 7, the website, forums, mailing list, and CVS will be shut down. Due to a sponsor unexpectedly dropping sponsorship of grsecurity while continually promising payment, I began the summer in debt and had to borrow money from family to pay for food. If none of the companies that depend on grsecurity, some of them being very large, are able to sponsor the project, grsecurity will cease to exist. I am not looking for paypal donations at this point, unless those that donate do so with the recognition that despite their donation, grsecurity may still never be returning.”

Things are not looking good for embedded Linux security today. I don’t know the backstories. I wonder what happens next?