mbed: Firmware updates for IoT and IETF SUIT Hackathon

See below blog for a few links to new projects.

Improving firmware updates for Internet of Things devices – the IETF SUIT Hackathon in Berlin/Germany
Last updated about 13 hours ago, by Hannes Tschofenig. Arm Research, hackathon

IoT devices commonly require security patches and updates to protect against known vulnerabilities. In this blog post Hannes Tschofenig highlights a recently-launched standardization effort in the Internet Engineering Task Force (IETF): the “Software Updates group for Internet of Things (SUIT)” working group. The report shares experiences from a Hackathon in Berlin, where several working group members met to work on code for firmware updates.

Working Group Formation and IETF London Hackathon

The Internet Engineering Task Force (IETF) met in London from March 17th – 23rd for the first face-to-face meeting of the IETF Software Updates group for Internet of Things (SUIT). The SUIT working group is chartered to develop firmware update solutions that can be implemented into Internet of Things (IoT) devices, especially microcontrollers with limited RAM and flash memory, such as 10 KiB RAM and 100 KiB flash. The focus of the group is simple: since many IoT devices require software updates to fix security vulnerabilities, the group will develop and standardize a secure approach to these updates. For IoT devices, this software update often comes in the form of a monolithic block, where the entire codebase running on the device, i.e. the firmware, is replaced in one shot.[…]





QuarksLab: intro to TEE: ARM’s TrustZone

[…]This starts a series of two blogposts discussing hardware technologies that can be used to support TEE implementations:
* TrustZone from ARM
* SGX from Intel
As suggested by the title, this blogpost tells you more about TrustZone.[…]



Smartphone Performance and Security Enhancements Through Wi-Fi Firmware Modifications

Teaching Your Wireless Card New Tricks: Smartphone Performance and Security Enhancements Through Wi-Fi Firmware Modifications
Schulz, Matthias
Ph.D. Thesis

Smartphones come with a variety of sensors and communication interfaces, which make them perfect candidates for mobile communication testbeds. Nevertheless, proprietary firmwares hinder us from accessing the full capabilities of the underlying hardware platform which impedes innovation. Focusing on FullMAC Wi-Fi chips, we present Nexmon, a C-based firmware modification framework. It gives access to raw Wi-Fi frames and advanced capabilities that we found by reverse engineering chips and their firmware. As firmware modifications pose security risks, we discuss how to secure firmware handling without impeding experimentation on Wi-Fi chips. To present and evaluate our findings in the field, we developed the following applications. We start by presenting a ping-offloading application that handles ping requests in the firmware instead of the operating system. It significantly reduces energy consumption and processing delays. Then, we present a software-defined wireless networking application that enhances scalable video streaming by setting flow-based requirements on physical-layer parameters. As security application, we present a reactive Wi-Fi jammer that analyses incoming frames during reception and transmits arbitrary jamming waveforms by operating Wi-Fi chips as software-defined radios (SDRs). We further introduce an acknowledging jammer to ensure the flow of non-targeted frames and an adaptive power-control jammer to adjust transmission powers based on measured jamming successes. Additionally, we discovered how to extract channel state information (CSI) on a per-frame basis. Using both SDR and CSI-extraction capabilities, we present a physical-layer covert channel. It hides covert symbols in phase changes of selected OFDM subcarriers. Those manipulations can be extracted from CSI measurements at a receiver. To ease the analysis of firmware binaries, we created a debugging application that supports single stepping and runs as firmware patch on the Wi-Fi chip. We published the source code of our framework and our applications to ensure reproducibility of our results and to enable other researchers to extend our work. Our framework and the applications emphasize the need for freely modifiable firmware and detailed hardware documentation to create novel and exciting applications on commercial off-the-shelf devices.




Pyra (Debian-based gaming console) needs kernel ARM/OMAP experts

Pyra needs help by kernel and low-level ARM/OMAP experts

W. Martin Borgert posted a message to the Debian kernel/ARM lists, about soliciting kernel dev help for a Debian-based gaming console, successor to OpenPandora.

Borgert quote:

I just read this post by Pyra project leader Michael Mrozek a.k.a. “Evil Dragon”. (Pyra is planned to be a Debian based gaming console, successor of OpenPandora.) They need help by kernel devs and folks who know OMAP etc. Maybe somebody here can help them? There even might be some money in it. No doubt about fame and fun, though!

Evil Dragon quote:

[…]This brings up another important point: Kernel developers! There’s still quite a few things which should be done before the release. We don’t have proper powersaving, the TILER implementation needs to be tidied up, 3D is not yet implemented, Audio needs a better setup, etc. It seems there are less and less kernel developers having the time to work on such things in their spare time. That’s why I decided to hire freelancers to help out as well![…]I know we’ve got quite a lot of OpenSource fans around here. Maybe some know some good kernel developers, who are able to include and improve hardware support and fix various issues. We can provide a test unit as well as the needed datasheets – but it needs someone who is capable of debugging and fixing low-level things.[…]



Azeria Labs releases new ARM cheat sheet poster


ARM64JSON: AArch64 instructions encoded in JSON


The repository contains ARM64 (AArch64) instruction encoding in a machine-readable JSON:

* ISA_v83A_A64_xml_00bet6_instructions.json contains encoding of every instruction, including ARM64v2/v3 extensions.

* ISA_v83A_A64_xml_00bet6_group_class.json contains hierarchical encoding ARM64 top level -> Instruction group (e.g. “Data Processing — Immediate”) -> Instruction class (e.g. “Add/subtract (immediate)”). No instruction encodings in this file.

The simple and easyly-organised JSON data was extracted from a machine-readable ARM64 specs. A64 ISA XML for Armv8.3 ver. 00bet6.1 released by ARM.






Linaro Connect Vancouver BC: CfP open


Call for Proposals: opened 8 May 2018
Deadline to submit proposals: ends 23 July 2018



PS: Resources from last Linaro Connect:


GLitch: a remote Rowhammer exploit on ARM Android devices

What is GLitch?

GLitch is one part of our series of Rowhammer attacks. We started by breaking the EDGE browser and the cloud. Then we moved towards Android devices showing how to root them with bit flips. This time we wanted to show that also mobile phones can be attacked remotely via the browser.
Meet GLitch: the first instance of a remote Rowhammer exploit on ARM Android devices. This makes it possible for an attacker who controls a malicious website to get remote code execution on a smartphone without relying on any software bug.
You want to know what makes this attack even cooler? It is carried out by the GPU. This is the first GPU-accelerated Rowhammer attack.[…]



Arm announces security features in Cortex-M35P

On Wednesday, 2nd May we announced a range of IP to protect silicon from physical attacks, extending our portfolio of Arm security IP to bring physical security within reach of any IoT product. Our new IP, all marked with a “P” tag for physical security, includes: the Cortex-M35P processor, as well as a new suite of security IP with added side-channel attack protection (CryptoIsland-300P and CryptoCell-312P). This post describes how the benefits and features of the Cortex-M35P bring anti-tampering protection to the widely-supported, user-friendly Cortex-M processor to guard against physical attacks, providing access to new markets for your product.[…]



ARM: documents CSDB (Consumption of Speculative Data Barrier) instruction

Hmm, I can’t find the updated docs that Igor mentions above.




ARM to add PSA to Trusted Firmware-M (and new threat model docs available)

ARM has new threat model docs available for their PSA, and have announced that they’ll be releasing ARM Trusted Firmware with PSA support at the end of the month, you can give them your email address to be notified when it is released.

[…]we announced a major program to improve IoT security, called Platform Security Architecture (PSA). PSA is a common framework aiming to provide a holistic approach to IoT security.[…]Now available! Open Source Trusted Firmware-M. Arm wants to make security simpler and more cost effective, by making high quality reference code and documents accessible – as security becomes more complex, all developers need access to these resources. We have released the first open source reference implementation firmware that conforms to the PSA specification, Trusted Firmware-M, at the end of March 2018.[…] Download now: Threat Models and Security Analyses documentation: The TMSA is a starting point for assessing the security risk facing a selection of connected devices. From this research, the right level of security can be determined, and then functional requirements established to mitigate the threats.



ARM Dynamic Tables Framework

ARM has submitted a patch to UEFI’s Tianocore which adds a “Dynamic Tables” framework that abstracts ACPI amongst other things…  Readme excerpt of patch below:

This patch introduces a branch for implementing Dynamic Tables Framework.

To reduce the amount of effort required in porting firmware to new platforms, we propose this “Dynamic Tables” framework. The aim is to provide an example implementation capable of generating the firmware tables from an external source. This is potentially a management node, either local or remote, or, where suitable, a file that might be generated from the system construction. This initial “proof of concept” release does not fully implement that – the configuration is held in local UEFI modules.

The dynamic tables framework is designed to generate standardised firmware tables that describe the hardware information at run-time. A goal of standardised firmware is to have a common firmware for a platform capable of booting both Windows and Linux operating systems.

Traditionally the firmware tables are handcrafted using ACPI Source Language (ASL), Table Definition Language (TDL) and C-code. This approach can be error prone and involves time consuming debugging. In addition, it may be desirable to configure platform hardware at runtime such as: configuring the number of cores available for use by the OS, or turning SoC features ON or OFF.

The dynamic tables framework simplifies this by providing a set of standard table generators, that are implemented as libraries. These generators query a platform specific component, the ‘Configuration Manager’, to collate the information required for generating the tables at run-time.

The framework also provides the ability to implement custom/OEM generators; thereby facilitating support for custom tables. The custom generators can also utilize the existing standard generators and override any functionality if needed.

The framework currently implements a set of standard ACPI table generators for ARM architecture, that can generate Server Base Boot Requirement (SBBR) compliant tables. Although, the set of standard generators implement the functionality required for ARM architecture; the framework is extensible, and support for other architectures can be added easily.

The framework currently supports the following table generators for ARM:
* DBG2 – Debug Port Table 2
* DSDT – Differentiated system description table. This is essentially a RAW table generator.
* FADT – Fixed ACPI Description Table
* GTDT – Generic Timer Description Table
* IORT – IO Remapping Table
* MADT – Multiple APIC Description Table
* MCFG – PCI Express memory mapped configuration space base address Description Table
* SPCR – Serial Port Console Redirection Table
* SSDT – Secondary System Description Table. This is essentially a RAW table generator.

[…]Please create a branch called ‘dynamictables’ in edk2-staging.[…]

More info: see the “[PATCH] Branch to implement Dynamic Tables Framework” thread on the edk2-devel list by Sami Mujawar. And look for above branch to be created.

Hmm, it appears the links to the archives on the URL provided in the mailing list posts is not valid:

V1 from Oct2017:


Emulating Exynos 4210 BootROM in QEMU

[…]This project allows to debug BootROM dynamically with GDB. It has been helpful for analyzing secure boot mechanism that loads and authenticates the next stage from flash memory.[…]

Nicely-written. Includes coverage of U-Boot and U-Boot Secure Boot.


Exynos 4 Dual 45nm

PS: I just learned about this blog. Catching up, there are some interesting older posts, eg:

Amlogic S905 SoC: bypassing the (not so) Secure Boot to dump the BootROM

IoT, Security and Automotive: Who’s Responsible For Security?

IoT, Security & Automotive: Who’s Responsible For Security?

Experts at the Table, part 2: Cheap components contaminating the supply chain, the need for platforms and certifications, and the futility of trying to future-proof devices.
February 28th, 2018 – By: Ed Sperling

Semiconductor Engineering sat down to discuss security issues and how to fix them with Mark Schaeffer, senior product marketing manager for secure solutions at Renesas Electronics; Haydn Povey, CTO of Secure Thingz; Marc Canel, vice president of security systems and technologies at Arm; Richard Hayton, CTO of Trustonic; Anders Holmberg, director of corporate development at IAR Systems. What follows are excerpts of that conversation.[…]



Xen Security Advisory XSA-254 updated to V12 (on Spectre/Meltdown)

The XSA on Spectre/Meltdown has been updated again, with more info on ARM firmware:

Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 12

Information leak via side effects of speculative execution


Corrections to ARM SP2 information:
* ARM 32-bit requires new firmware on some CPUs.
* Provide link to the ARM firmware page, accordingly.
* ARM 32-bit mitigations are complete for Cortex-A CPUs.
We do not have information for other ARM CPUs at this time.

Systems running all versions of Xen are affected. For SP1 and SP2, both Intel and AMD are vulnerable. Vulnerability of ARM processors to SP1 and SP2 varies by model and manufacturer. ARM has information on affected models on the following website. For SP3, only Intel processors are vulnerable. (The hypervisor cannot be attacked using SP3 on any ARM processors, even those that are listed as affected by SP3.) Furthermore, only 64-bit PV guests can exploit SP3 against Xen. PVH, HVM, and 32-bit PV guests cannot exploit SP3.


ARM’s Kigen OS for cellular IoT security




Kigen Graphic 2