OpenPOWER firmware update from Stewart

Stewart Smith has a new blog post about OpenPOWER, focusing on firmware development community changes, including comments on OpenBMC and other projects. As well, apparently now non-IBM developers can now contribute to OpenPOWER firmware, as someone from has recently done, which sounds like an improvement.

IBM research on USB eavesdropping attacks

IBM Research has new research on USB attacks and an “UScramBle” implementation for Linux:

USB Eavesdropping Attacks

Attacks that leverage USB as an attack vector are gaining popularity. While attention has so far focused on attacks that either exploit the host’s USB stack or its unrestricted device privileges, it is not necessary to compromise the host to mount an attack over USB. This paper describes and implements a USB sniffing attack. In this attack a USB device passively eavesdrops on all communications from the host to other devices, without being situated on the physical path between the host and the victim device. To prevent this attack, we present UScramBle, a lightweight encryption solution which can be transparently used, with no setup or intervention from the user. Our prototype implementation of UScramBle for the Linux kernel […]

Thinkpad password bypass hardware

Some friends of mine are gathering up some old IBM Thinkpads from a recycling center, to refurbish them with Libreboot. It reminds me how much fixing end-user problems are like attacking a system. One of the Thinkpads had multiple passwords that had to be bypassed, so it could be used.

There’s a password bypass solution for Thinkpads that involves custom hardware:

“Joe in Australia offers the only Affordable Fully Assembled, Programmed and Tested unlimited use USB based ThinkPad Supervisor Password [SVP] Recovery or Clear Tools in the world.  Joe’s KeyMaker X1 [KMX1] and X2 [KMX2] can Recover or Clear Supervisor Password from all current IBM and Lenovo ThinkPad models with the exception of the SL300 SL400 SL500 G550 T*40 X*40 X1 Carbon (Gen 2) it can do this even if TPM/TCPA/PC8394T/8356908 security has been enabled. SL300 SL400 SL500 G550 T*40 X*40 X1 Carbon (Gen 2) do NOT store Supervisor Password [SVP] in an EEPROM, that is the reason the SVP cannot be recovered in those models from an EEPROM by KMX1 or KMX2.”

Stewart Smith on OpenPOWER firmware

Stewart Smith of IBM posted a new blog entry, announcing availability of the video of his recent OpenPOWER firmware talk at LinuxConf.AU:

In mid 2014, IBM released the first POWER8 based systems with the new Free and Open Source OPAL firmware. Since then, several members of the OpenPower foundation have produced (or are currently producing) machines based on the POWER8 processor with the OPAL firmware. This talk will cover the POWER8 chip with an open source firmware stack and how it all fits together. We will walk through all of the firmware components and what they do, including the boot sequence from power being applied up to booting an operating system. We’ll delve into:
– the time before you have RAM
– the time before you have thermal management
– the time before you have PCI
– runtime processor diagnostics and repair
– the bootloader (and extending it)
– building and flashing your own firmware
– using a simulator instead
– the firmware interface that Linux talks to
– device tree and OPAL calls
– fun in firmware QA and testing

Linux ACPI to IBM and Lenovo: help!

If you know someone at IBM or Lenovo, the Linux-ACPI community needs more involvement from you, please help.


——– Forwarded Message ——–
Subject:     ibm-acpi developers not responding despite serious bugs and debuggers
Date:     Sat, 30 Jan 2016 13:22:27 +0000
From:     jono <>
To:     Rafael J. Wysocki <>
CC:     ACPI Devel Maling List <>,

Dear Rafael,
Sorry to trouble you, but a number of us are having lots of grief
getting a response from ibm/lenovo regarding acpi bugs in newer models
like the Helix 2. The bugs make these machines difficult to use, and
there are various reports of this on the internet, along with people
willing to debug patches. But it’s impossible to contact anyone on the
ibm-acpi team to help with this. Do you know who we can contact to
help sort these bugs out? Myself and others are polite, fairly tech
savy, and willing to help, so I’m a bit puzzled by the silence from
this team.

The example is the Helix 2, see:

and various repetitions of this…

For more information, see the Linux-ACPI mailing list archives on

new Linux-IMA patchset closes multiple measurement/appraisal gaps

Mimi Zohar and Dmitry Kasatkin have created a new patchset for Linux IMA which:

“closes a number of measurement/appraisal gaps by defining a generic function named ima_read_and_process_file() for measuring and appraising files read by the kernel (eg. kexec image and initramfs, firmware, IMA policy). To differentiate between callers of ima_read_and_process_file() in the IMA policy, a new enumeration is defined named ima_read_hooks, which initially includes KEXEC_CHECK, INITRAMFS_CHECK, FIRMWARE_CHECK, and POLICY_CHECK.

separate ‘security.ima’ reading functionality from collect
load policy using path
update appraise flags after policy update completes
measure and appraise kexec image and initramfs
measure and appraise firmware (improvement)
measure and appraise the IMA policy itself
require signed IMA policy

 Documentation/ABI/testing/ima_policy      |  2 +-
 drivers/base/firmware_class.c             | 15 +++++–
 include/linux/ima.h                       | 12 +++++
 kernel/kexec_file.c                       | 28 +++++++—–
 security/integrity/digsig.c               |  2 +-
 security/integrity/iint.c                 | 24 +++++++—
 security/integrity/ima/ima.h              | 24 +++++—–
 security/integrity/ima/ima_api.c          | 51 +++++++++++++++——
 security/integrity/ima/ima_appraise.c     | 40 +++++++++++——
 security/integrity/ima/ima_crypto.c       | 56 ++++++++++++++++——–
 security/integrity/ima/ima_fs.c           | 45 ++++++++++++++++++-
 security/integrity/ima/ima_init.c         |  2 +-
 security/integrity/ima/ima_main.c         | 55 ++++++++++++++++++—–
 security/integrity/ima/ima_policy.c       | 73 ++++++++++++++++++++++++——-
 security/integrity/ima/ima_template.c     |  2 –
 security/integrity/ima/ima_template_lib.c |  3 +-
 security/integrity/integrity.h            | 14 +++—
 17 files changed, 329 insertions(+), 119 deletions(-)

More information:

OpenPOWER port comments, and EFI creation story

A few weeks ago, I noticed a new Github project where someone at IBM had ported UEFI to OpenPOWER. Later that day, someone *ELSE* at IBM had *ALSO* ported UEFI to OpenPOWER — two ports! And they found out about each other because of my blog, too funny! Anyway, they’re actively conversing on the Comments thread on the blog:

In addition to OpenPOWER issues, the Comments section has MULTIPLE people posting comments, which is a first for this blog! There’s some good background on history of EFI, including a pointer to 2005-era message that includes the ‘creation saga’ of EFI! In the past, Apple used OpenFirmware on PowerPC-based Macs, and PC vendors used BIOS on x86-based PCs. When Windows NT started support for non-x86 systems, ARC was used for the RISC vendors. Then Intel Itanium needed a solution. They nearly used ARC or OpenFirmware, before going down the route for EFI for Itanium, which later grew into UEFI and is now on Apple and PC systems as well. Here’s an excerpt with Andrew Fish talking about how EFI was created:

“At that time, two firmware solutions were put on the table as
replacements for BIOS architectures for the Itanium: Alpha Reference
Console (ARC) and Open Firmware. It turned out that nobody really
owned the inellectual property to ARC, and in any case, it did not
have enough extensible properties to make it practical for a
horizontal industry. At this point, Open Firmware became the
frontrunner as Apple and Sun both used it. However, Open Firmware was
not without its own technical challenges. The PC had started down a
path of using the Advanced Configuration and Power Interface (ACPI) as
its runtime namespace to describe the platform to the operating
system. As I liked to say at the time, the only thing worse than one
namespace is keeping two namespaces in sync. The other problem was the
lack of third party support for Open Firmware. We invited the
FirmWorks guys to come visit us at Dupont (WA), and we had a great
talk. Given we had just gone through an exercise of inventing a
firmware base from scratch, I think we were uniquely qualified to
appreciate what Open Firmware had been able to achieve. Unfortunately,
it became clear that the infrastructure to support a transition to
Open Firmware did not exist. Given the namespace issue with Open
Firmware and the lack of industry enabling infrastructure, we decided
to go on and make EFI a reality.”

Full post:

I thought ARC stood for “Advanced RISC Consortium”, but I can’t argue with Andrew, maybe it originally stood for “Alpha Reference Console”.  (During these years, I was doing “ring0′ work, not firmware, and my favorite box at the time was a DEC Alpha AXP with ARC-based firmware.) ARC is very similar to early EFI: a single firmware image with a FAT partition where additional firmware images are stored, using ‘variables’ to specify the boot loader to invoke. ARC died off, like all the RISC-based Windows NT platforms, a shame, IMO. The ARC spec is still archived by the NetBSD project, who still supports ARC:

I wonder how life would be today if Intel would have chosen ARC or OpenFirmware?

China defines ‘golden image’ as source, apparently

A few weeks ago, when I thought the ‘golden image’ in NIST SP800-147’s Provisioning phase required source access to the firmware, the below story would be an example of the only way vendors would get access to the source code to their closed-source firmware:

However, as clarified in email ‘interview'[1] with Andrew of NIST, the ‘golden image’ can also be a closed-source blob, in which case we’re supposed to *TRUST* the vendor. Now that “cyberwar” is a mainstream topic, governments will likely not trust closed-source blobs from foreign countries much anymore, at the firmware, operating system, or application level. But consumers don’t have the pressure that governments do, so we get to continue to *TRUST* the vendor, and the PKI backing the firmware, most of the keys of which we cannot verify, no acts of good faith from vendors to non-government players. 😦





Second port of Tianocore to OpenPOWER

Check out the Comments section of the recent post on Tianocore being ported to OpenPOWER:

So there are TWO ports of Tianocore to OpenPOWER, and a few days ago I knew about neither of them.

I wonder if OpenPOWER will officially adopt UEFI as a firmware option for their platform. I’ve heard indirect bragging from IBM that their systems can be 100% fully open source firmware, no blobs.

OpenPOWER architecture platform reference doc available

Stewart Smith posted information about public availability of the OpenPOWER Foundation’s PAPR (Power Architecture Platform Reference) document:

PAPR is the Power Architecture Platform Reference document. It’s a short read at only 890 pages and defines the virtualised environment that guests run in on PowerKVM and PowerVM (i.e. what is referred to as ‘pseries’ platform in the Linux kernel). As part of the OpenPower Foundation, we’re looking at ensuring this is up to date, documents KVM specific things as well as splitting out the bits that are common to OPAL and PAPR into their own documents.

Blog URL:

Document URL:

The document appears to be dated March 2015. There are lots of ‘firmware’ references in it! I couldn’t find any other information about this document from the web site. However, there are two other OpenPOWER specs under public review, due mid-month:


ARM has a new embedded OS called mbed, for use with the IoT. Beta was announced today:

IBM is partnering with ARM on mbed:

See this link for the various Github URLs to the source:

More Info:

(FYI,, which is often used in the press release URLs, merely redirects to

I haven’t looked at the code or the license yet. I have no idea about what firmware and boot technologies it uses… 😦

Linux Security Summit 2015 proceedings available

As part of LinuxCon North America, the Linux Security Summit recently finished, and presentations are now available (I omitted the few talks which had no presentations from below list):

* Keynote: Giant Bags of Mostly Water – Securing your IT Infrastructure by Securing your Team, Konstantin Ryabitsev, Linux Foundation
* CC3: An Identity Attested Linux Security Supervisor Architecture, Greg Wettstein, IDfusion
* SELinux in Android Lollipop and Android M, Stephen Smalley, NSA
* Discussion: Rethinking Audit, Paul Moore, Red Hat
* Assembling Secure OS Images, Elena Reshetova, Intel
* Linux and Mobile Device Encryption, Paul Lawrence, Mike Halcrow, Google
* Discussion: Core Infrastructure Initiative, Emily Ratliff, Linux Foundation
* Security Framework for Constraining Application Privileges, Lukasz Wojciechowski, Samsung
* IMA/EVM: Real Applications for Embedded Networking Systems, Petko Manolov, Konsulko Group, Mark Baushke, Juniper Networks
* Ioctl Command Whitelisting in SELinux, Jeffrey Vander Stoep, Google
* IMA/EVM on Android Device, Dmitry Kasatkin, Huawei Technologies
* Subsystem Update: Smack, Casey Schaufler, Intel
* Subsystem Update: AppArmor, John Johansen, Canonical
* Subsystem Update: Integrity, Mimi Zohar, IBM
* Subsystem Update: SELinux, Paul Moore, Red Hat
* Subsystem Update: Capabilities, Serge Hallyn, Canonical
* Subsystem Update: Seccomp, Kees Cook, Google
* Discussion: LSM Stacking Next Steps, Casey Schaufler, Intel

Learning OpenPOWER firmware

A few days ago, I blogged about AMI joining OpenPOWER. Recently, there’s been some other activity in OpenPOWER.

IBM just announced SuperVessel, an OpenPOWER-based cloud for developers:

It appears the source code to the OpenPOWER firmware was released about a year ago. Luckily, some others have been blogging on OpenPOWER firmware already:

I’m just learning about the OpenPOWER community, it’s been years since I’ve written PowerPC assembly, and that was OS-level stuff, I am not aware of current OpenPOWER firmware technology. I probably won’t have a lot of time to post blog entries next week, but but I’ll have some more on OpenPOWER firmware in future blog posts.


AMI (American Megatrends, Inc.), one of the original PC BIOS vendors, just joined the OpenPOWER Foundation. AMI’s “MegaRAC SP-X for POWER8” product was launched in support of TYAN’s first non-IBM branded OpenPOWER commercial server, which they’re demoing at COMPUTEX TAIPEI this week. MegaRAC SP-X for POWER8 includes server firmware technology. Excerpts from their PR:

“AMI joins a growing roster of technology organizations working collaboratively to build advanced server, networking, storage and acceleration technology as well as industry-leading open source software aimed at delivering more choice, control and flexibility to developers of next-generation, hyperscale and cloud data centers. The group makes POWER hardware and software available to open development for the first time, as well as making POWER intellectual property licensable to others, greatly expanding the ecosystem of innovators on the platform. AMI has been working with IBM and other OpenPOWER Foundation members like Tyan to develop enterprise server and networking solutions for next-generation data centers that integrate IBM POWER CPUs and AMI MegaRAC(R) Remote Management Firmware / Software Solutions. “

“MegaRAC(R) SP-X for POWER8 is a powerful development framework for server management solutions composed of firmware and software components, based on industry standards like IPMI 2.0, SMASH, Serial over LAN (SOL) and key serviceability features like remote presence, CIM profiles and advanced automation. MegaRAC SP-X features a high level of modularity, with the ability to easily configure and build the firmware image by selecting features using an intuitive graphical development tool chain. These features are available in independently maintained packages, for superior manageability of the firmware stack.”

More Information:,%20Brings%20Expertise%20on%20Server%20and%20Data%20Center%20Management%20to%20COMPUTEX%20TAIPEI/