SeaBIOS TPM support improved

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:
https://www.coreboot.org/mailman/listinfo/seabios

Guidance on using ACPI _DSD with Linux

Al Stone of Red Hat submitted a 4-part patch to the Linux-ACPI list. Excerpt from comments from the first patch:

How to Use the ACPI _DSD Device Properties UUIDs

In the three documents that follow, we lay out a process for defining the use cases of device properties returned by the ACPI _DSD (Device Specific Data) object in Data Structures associated with the Device Properties UUID [0] and the Hierarchical Properties Extension UUID. The term “_DSD device properties” below refers to the data formats associated with those two UUIDs only.  All other UUIDs used with _DSD are outside the scope of what is described here. The goal of these documents is to: (1) make clear to OS vendors which of the use cases of _DSD device properties need to be supported; (2) be clear on what those use cases should mean to the OS; and, (3) have all OSs use the same definitions for those use cases. The first document describes basic context and essential terminology for the process of submitting a use case for the _DSD device properties to a central location so that it can be reviewed and tracked. The next document describes a database for storing the use cases of _DSD device properties that have been reviewed and agreed upon.  The idea is to make this database publicly available so that OS developers and firmware creators can easily see what is already defined, what is in use, and what is not defined. The final document provides a formal language for describing the use cases of _DSD device properties.  The goal is to make it relatively easy to define new use cases of the _DSD device properties, by stating clearly what those definitions must look like.  This also makes building automated tools easier, allowing us to keep the process simpler, permit validation of the content, assist with documentation, and perform basic record keeping. […]

See full post and the github project:

https://github.com/ahs3/dsd/tree/master/documentation
https://marc.info/?l=linux-acpi&m=146955102920815&w=2
https://marc.info/?l=linux-acpi&m=146955096920780&w=2
https://marc.info/?l=linux-acpi&m=146955089620763&w=2
https://marc.info/?l=linux-acpi&m=146955077420741&w=2
https://marc.info/?l=linux-acpi&m=146955067620727&w=2

Also, there’s a Python-based _DSD command line tool in the same DSD github project!

https://github.com/ahs3/dsd

U-Boot v2016.09-rc1 released

Tom Rini of Konsulko announced the v2016.09-rc1 release of U-Boot, his announcement to the U-Boot list is excerpted below:

It’s release day and v2016.09-rc1 is out and the merge window is closed. I’ve updated git and the tarballs are also up now.  I’ve made an attempt at keeping track of what updated as things went along this time:
– DM / MMC block device clean up, patman improvements
– DM now supports of-platdata for cases where we are very much size constrained.
– Various SPI fixes / improvements
– Arch / SoC / Platform updates: x86, rockchip, sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
– First round of updates to the PSCI code to make it easier to use.
– mkimage cleanups
– More test.py updates, vboot now a testcase
– Secure boot on MPC85xx.

And of course, other things as well.  Please feel free to chime in if there’s something important I forgot to call out. If you notice any problems with the release, please speak out and thanks all!

binman: new U-Boot firmware image creation tool

Simon Glass of Chromium submitted “binman”, a new firmware image creation tool, to the U-Boot project. Below is the intro from Simon’s patch 0/30:

binman: A tool for creating firmware images

This series introduces binman, a tool designed to create firmware images. It provides a way to bring together various binaries and place them in an image, at particular positions and with configurable alignment.

Packaging of firmware is quite a different task from building the various parts. In many cases the various binaries which go into the image come from separate build systems. For example, ARM Trusted Firmware is used on ARMv8 devices but is not built in the U-Boot tree. If a Linux kernel is included in the firmware image, it is built elsewhere.

It is of course possible to add more and more build rules to the U-Boot build system to cover these cases. It can shell out to other Makefiles and build scripts. But it seems better to create a clear divide between building software and packaging it.

U-Boot supports a very large number of boards. Many of these have their own specific rules for how an image should be put together so that it boots correctly. At present these rules are described by manual instructions, different for each board. By turning these instructions into a standard format, we can support making valid images for any board without manual effort, lots of READMEs, etc.

Images consist of a number of entries which are combined to make up the final image. The image is described in the device tree for the board, meaning that it can be accessed at run-time if desired.

Binman is an extensible tool. A set of standard entries is provides, but new entries can be created fairly easily. Entries can be as simple as providing the name of a file to include. They can also handle more complex requirements, such as adjusting the input file or reading header information from one entry to control the position of another.

U-Boot’s mkimage builds FIT images and various other binaries. Binman augments this by allowing these binaries to be packed together. While FIT should be used where possible, it cannot be used everywhere. For example, many devices require executable code at a particular offset in the image. X86 machines require lots of binary blobs at particular places, and a microcode collection easily accessible at boot.

So far binman has enough functionality to be useful, but apart from a few RFC patches, no attempt is made to switch boards over to use it. There should be enough material to permit review and comments.

The series is available at u-boot-dm/binman-working

Future work and missing features are documented in the README.

For more info, see the patch on the U-Boot list:
http://lists.denx.de/mailman/listinfo/u-boot

Project IceStorm

The Quickening

 

“Project IceStorm aims at reverse engineering and documenting the bitstream format of Lattice iCE40 FPGAs and providing simple tools for analyzing and creating bitstream files. The IceStorm flow (Yosys, Arachne-pnr, and IceStorm) is a fully open source Verilog-to-Bitstream flow for iCE40 FPGAs. “

 

Project IceStorm


http://www.latticesemi.com/Products/FPGAandCPLD/iCE40.aspx

Microsoft on TPM Lockout

Rafal Sosnowski of Microsoft has a new blog post on TPM:

Hello everyone. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today, I am going to talk about TPM Lockout state. TPM (Trusted Platform Module) is a small chip on the motherboard (discrete TPM) or part of the CPU implementation (firmware TPM) which can be used to securely store small amount of information (certificates, private keys, virtual smartcards, Bitlocker keys etc.). That data is completely isolated from HDD and partially from OS thus giving it maximum protection. To get access to that information from OS level user has to present some kind of authorization value. For example, Bitlocker PIN to get access to the Bitlocker Keys, Virtual smart-card PIN to get access to the certificates and private keys etc. However, TPM has special anti-hammering logic which prevents malicious user from guessing that authorization data indefinitely. Number of possible PIN failures varies across TPM specification: […]

Full post:
https://blogs.technet.microsoft.com/dubaisec/2016/07/10/tpm-lockout/

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

new EDK2-Bugs mailing list and Tianocore bugzilla server

On the EDK2-Devel list, Mike Kenney of Intel announced the creation of the Tianocore Bugzilla Server, and the new EDK2-bugs mailing list, which tracks changes to the bug database. The Tianocore project is going to migrate from the Github bug database to their own Bugzilla-based one. The announcement mentions a special case for UEFI security issues:

There is one special Product type on the Bugzilla server called “Tianocore Security Issues”.  If you believe you have discovered a security issue, then you must enter the issue using the “Tianocore Security Issues” Product.  The issue will be evaluated to determine if it really is a security issue or not. NOTE: Never any security issue details in email.

For full details, see Mike’s post:
http://article.gmane.org/gmane.comp.bios.edk2.devel/14844

More info:
https://tianocore.acgmultimedia.com
https://lists.01.org/mailman/listinfo/edk2-bugs

Hmm, No posts yet to the new list, at least nothing has been archived, yet there are 39 bugs in the database, I would have expected at least 39 posts in the archives…. The Tianocore Security Advisory list never seemed to work. The Intel Security Advisories list never seemed to work. Let’s hope the EDK2-bugs list works…
https://tianocore.acgmultimedia.com/buglist.cgi?bug_status=__open__&no_redirect=1&order=Importance&query_format=specific
https://lists.01.org/pipermail/edk2-bugs/

Open Trust Protocol (OTrP) created

There’s a new IoT security-centric informational IETF Internet Draft out, called OTrP, Open Trust Protocol. Their spec is released as an informational IETF Internet Draft, the companies of the 5 authors are from: Symantec, Interce, Solacia, and ARM. One of the news sites mentions the full list of companies backing this protocol are: Intercede, Solacia, Symantec, Beanpod, Sequitur Labs, Sprint, Thundersoft, Trustkernel, Verimatrix and ARM. I can’t find any web site for this group.

“This document specifies the Open Trust Protocol (OTrP), a protocol to install, update, and delete applications and to manage security configuration in a Trusted Execution Environment (TEE).TEEs are used in environments where security services should be isolated from a regular operating system (often called rich OS). This form of compartmentlization grants a smaller codebase access to security sensitive services and restricts communication from the rich OS to those security services via mediated access. […]”

https://www.ietf.org/id/draft-pei-opentrustprotocol-01.txt
https://tools.ietf.org/html/draft-pei-opentrustprotocol-01
https://www.arm.com/about/newsroom/connected-devices-need-e-commerce-standard-security-say-cyber-security-experts.php

PS: A bit off-topic, but IETF- and IoT- related, found when looking for above URLs:
https://www.internetsociety.org/publications/ietf-journal-april-2016/internet-things-standards-and-guidance-ietf

Choronzon fuzzer released

“I am happy to announce today the public release of our evolutionary knowledge-based fuzzer, Choronzon. An overview of the architecture of Choronzon was initially presented at the ZeroNights 2015 conference. A recording of the presentation and the slide deck are also available. You can now find the full source code of Choronzon on the official CENSUS GitHub page. We welcome any feedback you may have and pull requests!”

https://census-labs.com/news/2016/07/20/choronzon-public-release/

Click to access choronzon-zeronights-2015.pdf

https://github.com/CENSUS/choronzon

 

CP/M for UEFI

“CP/Mega88 – CP/M for UEFI: CP/Mega88 is an i8080 emulator running on ATmega88, and on which CP/M can run. Also, it can be built as a UEFI application that can run on x86_64 platforms without any operating system. You can try running CP/M on POSIX environment, or EFI firmware.”

http://qiita.com/toyoshim/items/7961fc3d776133348660

ASN.1 bug in Objective Systems compiler

Impact: https://www.obj-sys.com/customers/

See the below Github-based security advisory for more details.

https://twitter.com/4Dgifts/status/755179455258226690

Title: Heap memory corruption in ASN.1 parsing code generated by Objective Systems Inc. ASN1C compiler for C/C++
Advisory ID: CVE-2016-5080
Advisory URL: http://www.fundacionsadosky.org.ar/publicaciones-2
Date of last update: 2016-07-19
Vendors contacted: Objective Systems Inc.

https://github.com/programa-stic/security-advisories/tree/master/ObjSys/CVE-2016-5080
xxxx

xxx