On OpenPOWER POWER9 systems, we typically talk to the flash chips that hold firmware for the host (i.e. the POWER9) processor through a daemon running on the BMC (aka service processor) rather than directly. We have host firmware map “windows” on the LPC bus to parts of the flash chip. This flash chip can in fact be a virtual one, constructed dynamically from files on the BMC. Since we’re mapping windows into this flash address space, we have some knowledge as to what IO the host is doing to/from the pnor. We can use this to output data in the blktrace format and feed into existing tools used to analyze IO patterns. So, with a bit of learning of the data format and learning how to drive the various tools, I was ready to patch the BMC daemon (mboxbridge) to get some data out.[…]
[…]Will this work on a non-IBM server?
No, this uses IBM-specific UEFI hooks to reset the passwords.
[…]This article details out on the usage of a Non-Volatile Memory Enterprise (NVMe) adapter on POWER9 systems. This article also provides use cases to explains how an NVMe adapter can be effectively used and also lists the benefits.[…]
Nice, another online source to this classic document. There are a few other sources online, if you search. If you’ve never read this book, it is a great read, with the source to the PC BIOS listed, a great way to learn assembly language.
[…]IBM is providing their OpenBMC code base to The Linux Foundation, and this project will be supported by several organizations, including Facebook, Google, Intel, and Microsoft. The community is looking to expand and invites contributors from across the industry to come together in defining and creating the OpenBMC stack.[…]The Linux Foundation is pleased to welcome OpenBMC to our family of open source projects and to work with the community to support its growth.[…]
Stewart Smith of IBM has a new blog post that gives an introduction to OpenPOWER firmware dev.
A (simplified) view of OpenPOWER Firmware Development
I’ve been working on trying to better document the whole flow of code that goes into a build of firmware for an OpenPOWER machine. This is partially to help those not familiar with it get a better grasp of the sheer scale of what goes into that 32/64MB of flash. I also wanted to convey the components that we heavily re-used from other Open Source projects, what parts are still “IBM internal” (as they relate to the open source workflow) and which bits are primarily contributed to by IBMers (at least at this point in time).[…]
Stewart Smith of IBM has a new blog post about adding ZMODEM support to OpenPOWER firmware.
From checkin: This enables the use of rz/sz to send/receive files using ZMODEM. This enables error detection and correction when using the console to transfer files to/from the host.
ZMODEM saves the day! Or, why my firmware for a machine with a CPU from 2017 contains a serial file transfer protocol from the 1980s
Recently, I added the package lrzsz to op-build in this commit. This package provides the rz and sz commands – for receive zmodem and send zmodem respectively. For those who don’t know, op-build builds a firmware image for OpenPOWER machines, and adding this package adds the commands to the petitboot shell (the busybox environment you get when you “exit to shell” from the boot menu).[…]
What’s next, a UEFI runtime service for Kermit, using CKermit? UEFI NNTP Boot, using signed images on alt.binaries.firmware.*? 🙂
OpenPOWER secure and trusted boot, Part 2
Protecting system firmware with OpenPOWER secure boot
Making your system safe against boot code cyberattacks
Dave Heller and Nageswara Sastry
Published on June 05, 2017
This content is part 2 of 2 in the series: OpenPOWER secure and trusted boot. IBM® OpenPOWER servers offer two essential security features, trusted boot and secure boot, to help ensure the integrity of your server and safeguard against a boot code cyberattack. Trusted boot works by creating secure recordings, or measurements, of executable code as the system boots. Using a process known as remote attestation, you can retrieve these measurements securely and use them to verify the integrity of your firmware or target operating system (OS). Secure boot helps ensure the integrity of your OS and firmware as well. But rather than taking measurements for later examination, secure boot performs the validation in place, during boot, and will halt the boot process if the validation fails. These two features are complementary and work together to provide comprehensive protection of platform boot code. This article explores the secure boot method, with particular focus on protection of system firmware.[…]
Part 1 is from Feburary:
[…]Under the Hood of Power Firmware Maintenance
The Service Processor of the server is running an embedded operating system with complex power firmware applications running on it; one of which is an application responsible for handling code updates. […]
Thiago Jung Bauermann of IBM has submitted a 6-part patch to the Linux-IMA-devel/Linux-Kernel lists, with some improvements to Linux IMA for OpenPOWER secure/trusted boot. Including comments from parts 1 and 6 of the patch, see the full patch for full details.
Appended signatures support for IMA appraisal
On the OpenPOWER platform, secure boot and trusted boot are being implemented using IMA for taking measurements and verifying signatures. Since the kernel image on Power servers is an ELF binary, kernels are signed using the scripts/sign-file tool and thus use the same signature format as signed kernel modules. This patch series adds support in IMA for verifying those signatures. It adds flexibility to OpenPOWER secure boot, because it can boot kernels with the signature appended to them as well as kernels where the signature is stored in the IMA extended attribute. The first four patches are cleanups and improvements that can be taken independently from the others (and from each other as well). The last two are the ones actually focused on this feature. […] This patch introduces the appended_imasig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA signature appended to it. Here is how it can be used in a rule:
appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig
appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig|imasig
In the second form, IMA will accept either an appended signature or a signature stored in the extended attribute. In that case, it will first check whether there is an appended signature, and if not it will read it from the extended attribute. The format of the appended signature is the same used for signed kernel modules. This means that the file can be signed with the scripts/sign-file tool, with a command line such as this:
$ sign-file sha256 privkey_ima.pem x509_ima.der vmlinux
This code only works for files that are hashed from a memory buffer, not for files that are read from disk at the time of hash calculation. In other words, only hooks that use kernel_read_file can support appended signatures. The change in CONFIG_INTEGRITY_SIGNATURE to select CONFIG_KEYS instead of depending on it is to avoid a dependency recursion in CONFIG_IMA_APPRAISE_APPENDED_SIG, because CONFIG_MODULE_SIG_FORMAT selects CONFIG_KEYS and Kconfig complains that CONFIG_INTEGRITY_SIGNATURE depends on it.
IBM’s SecurityIntelligence has a story on attacking Android’s Custom Boot Modes.
Android Vulnerabilities: Attacking Nexus 6 and 6P Custom Boot Modes
By Roee Hay
Co-authored by Michael Goberman.
In recent months, the X-Force Application Security Research Team has discovered several previously undisclosed Android vulnerabilities. The November 2016 and January 2017 Android Security Bulletins included patches to one high-severity vulnerability, CVE-2016-8467, in Nexus 6 and 6P. Our new paper, “Attacking Nexus 6 & 6P Custom Bootmodes,” discusses this vulnerability as well as CVE-2016-6678.[…]
Talos has a new post on their use of FPGAs on their OpenPower-based workstation.
Deb McLemore of IBM has submitted multiple updates to FWTS, the FirmWare Test Suite, adding a lot more support for OpenPOWER OPAL firmware.
opal: pci_info: Add OPAL PCI Info validation
opal: mem_info: Add OPAL MEM Info validation
opal: cpu_info: Add OPAL CPU Info validation
devicetree: dt_sysinfo: Add OPAL firmware version checks
olog: olog.json: Update OPAL skiboot errors to check on olog scan
There is a lot of useful diagnostic information in this code, example:
“You are running in manufacturing mode. This mode should only be enabled in a factory during manufacturing.”
Stewart Smith of IBM has a new blog post on how to compile your own firmware for the OpenPOWER-based IBM S822LC:
[…] IBM (my employer) recently announced the new S822LC for HPC POWER8+NVLINK NVIDIA P100 GPUs server. The “For HPC” suffix on the model number is significant, as the S822LC is a different machine. What makes the “for HPC” variant different is that the POWER8 CPU has (in addition to PCIe), logic for NVLink to connect the CPU to NVIDIA GPUs.[…]
New potential product on CrowdSupply with a NICE set of features (…and I wonder how secure it will be):
* Blob-free operation
* Fully libre (open-source) IBM OPAL primary firmware w/ PetitBoot interface
* Fully libre (open-source) OpenBMC secondary (IPMI / OoBM) firmware
* NO signing keys preventing firmware modification
Stefan Berger of IBM submitted a 6-part patch to the SeaBIOS project, updating it’s TPM support, his patch comment follows:
This series of patches extends the TPM2 code to extend the BIOS related PCRs 0-7 in all available banks. This prevents that these PCRs remain untouched and filled with bogus values by applications. For example, the SHA1 hash is extended into the SHA256 bank. The value that is extended into this bank is essentially a SHA1 with zero bytes used for filling it to the size of a sha256 hash. This is done for all PCR banks of the TPM2 where these PCRs are available. In v2 of this series I also extended the log functions for logging the additional hashes. So there are more patches now.
For more information, see the full patch sent to the SeaBIOS list:
Stewart Smith of IBM has an interesting new blog post about using afl to fuzz OpenPOWER’s firmware:
Deb McLemore of IBM has submitted a BMC Info, new IPMI tool to FirmWare Test Suite (FWTS).
Introduce IPMI BMC Info
This feature adds the foundation to perform an IPMI BMC Info check that will determine if a Host is capable of IPMI messaging and if so will perform a basic IPMI message exchange to determine the version of IPMI running on the hardware. In the future the IPMI infrastructure can be used to further interrogate the FRU Inventory and other Sensors to help correlate data and surface any discrepancies on inventory or hardware characteristics.
For more information, see the patch sent to the fwts-devel mailing list: