Tag: ARM Ltd

ARM adds Shared Virtual Addressing (SVA) for IOMMU to Linux kernel

~ hucktech ~ Leave a comment

Jean-Philippe Brucker of ARM sent a 37-part patch, adding SVA support to Linux kernel, excerpts of announcement below:

Shared Virtual Addressing (SVA) is the ability to share process address spaces with devices. It is called “SVM” (Shared Virtual Memory) by OpenCL and some IOMMU architectures, but since that abbreviation is already used for AMD virtualisation in Linux (Secure Virtual Machine), we prefer the less ambiguous “SVA”. Sharing process address spaces with devices allows to rely on core kernel memory management for DMA, removing some complexity from application and device drivers. After binding to a device, applications can instruct it to perform DMA on buffers obtained with malloc.

The device, buses and the IOMMU must support the following features:
* Multiple address spaces per device, for example using the PCI PASID (Process Address Space ID) extension. The IOMMU driver allocates a PASID and the device uses it in DMA transactions.
* I/O Page Faults (IOPF), for example PCI PRI (Page Request Interface) or Arm SMMU stall. The core mm handles translation faults from the IOMMU.
* MMU and IOMMU implement compatible page table formats.

This series requires to support all three features. I tried to facilitate using only a subset of them but enabling it requires more work. Upcoming patches will enable private PASID management, which allows device driver to use an API similar to classical DMA, map()/unmap() on PASIDs. In the future device drivers should also be able to use SVA without IOPF by pinning all pages, or without PASID by sharing the single device address space with a process. Although we don’t have any performance measurement at the moment, SVA will likely be slower than classical DMA since it relies on page faults, whereas classical DMA pins all pages in memory. SVA mostly aims at simplifying DMA management, but also improves security by isolating address spaces in devices. Intel and AMD IOMMU drivers already offer slightly differing public functions that bind process address spaces to devices. Because they don’t go through an architecture-agnostic API, only integrated devices could use them so far. […]

Full patch:
https://lists.linuxfoundation.org/pipermail/iommu/2018-February/025992.html
More info on IOMMUs:
http://pages.cs.wisc.edu/~basu/isca_iommu_tutorial/index.htm
https://github.com/chipsec/chipsec/blob/master/chipsec/hal/iommu.py
https://www.spinics.net/lists/arm-kernel/msg609771.html
https://www.spinics.net/lists/kernel/msg2651481.html
https://www.spinics.net/lists/kvm/msg148819.html
https://developer.arm.com/products/architecture/a-profile/docs/100940/latest/separation-of-kernel-and-application-virtual-address-spaces
https://software.intel.com/en-us/articles/opencl-20-shared-virtual-memory-overview
https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/sharedVirtualMemory.html
https://lwn.net/Articles/726606/

Click to access 48882_IOMMU.pdf

https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware
https://software.intel.com/en-us/blogs/2009/03/02/intels-virtualization-for-directed-io-aka-iommu-part-1

 

Boot Shim: Bootstraps UEFI applications on hacked Lumia phones

~ hucktech ~ Leave a comment

Boot Shim is a small ARM32 Windows Boot Manager Application that intended to chain-load the normal UEFI environment for UEFI application development on hacked Lumias. As Lumia verifies bootarm.efi or whatever on initialization even when Secure Boot is turned off, this application can provide additional image load capabilities, but you have to develop it from the framework provided.[…]

https://github.com/imbushuo/boot-shim

David Brown at Linaro Connect: Digital signatures and the beginning of the world (on ARM bootloaders)

~ hucktech ~ Leave a comment

From Linaro Connect 2017 in San Francisco:

Digital signatures and the beginning of the world – SFO17-306
David Brown
The bootloader is where it all begins. This session sums up our experiences with various signature types, data formats, implementations and how to choose.

http://connect.linaro.org/resource/sfo17/sfo17-306/

 

Reversing/exploiting Samsung’s TrustZone, part 1

~ hucktech ~ Leave a comment

Unbox Your Phone — Part I.
This is the first part of a blog series about reverse engineering and exploiting Samsung’s TrustZone. Following parts in the series so far: 2, 3. This first post covers the basics of the architecture. All of this is public info, nothing new, all of it has been covered in bits and pieces in various publications before. Some of it comes from Trustonic/Samsung materials, some of it from open source software, and some of it from the few great instances of prior research. It’s here as an intro, for completeness. Later in the series, I summarize the reverse engineering results and explain the vulnerabilities that I have found.[…]

View at Medium.com

View at Medium.com

 

View at Medium.com

 

ARM (Linaro) on Meltdown and Spectre

~ hucktech ~ 1 Comment

Spoiler alert:

[…]This is the first part in a series of blog posts about Meltdown and Spectre. The intention here was to penetrate the whitepapers and give an easy to grasp overview of the attacks. In the upcoming blog post we will talk more about individual components, like OP-TEE, Linux kernel and other firmware.

https://www.linaro.org/blog/meltdown-spectre/

NCC Group releases Cachegrab, tool for trace-driven cache attacks against ARMv8 TrustZone

~ hucktech ~ Leave a comment

 

34C3 Tool Release: Cachegrab

Today, NCC Group is releasing Cachegrab, a tool designed to help perform and visualize trace-driven cache attacks against software in the secure world of TrustZone-enabled ARMv8 cores. These cache attacks, as well as other microarchitectural attacks on secure computing environments, were presented at the 34th Chaos Communication Congress. There are two key properties of many TrustZone implementations that make the attacks within Cachegrab feasible. First, the secure world and non-secure world often share the caches within a processor. This means that when software executes in the secure world, it affects the presence or absence of non-secure world entries within the shared cache. Second, privileged users in the non-secure world are able to use privileged instructions to interleave attacker and victim processes, as well as determine what non-secure data has been evicted from the cache.[…]

https://github.com/nccgroup/cachegrab

https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2017/december/34C3-Tool-Release-Cachegrab/

https://events.ccc.de/congress/2017/Fahrplan/events/8950.html

 

 

ExploitLab’s DVAR – Damn Vulnerable ARM Router

~ hucktech ~ Leave a comment

 

 

http://blog.exploitlab.net/2018/01/dvar-damn-vulnerable-arm-router.html

ARM assembly resources from Azeria Labs

~ hucktech ~ Leave a comment

Writing ARM Assembly (Part 1)

ARM Lab (VM)

Part 3: Stack Overflow Challenges

Debugging with GDB Introduction

Nexmon_Debugger: for ARM microcontroller in the BCM4339 Wi-Fi chip

~ hucktech ~ Leave a comment

Nexmon Debugger

To analyze the FullMAC firmware running on the ARM microcontroller in the BCM4339 Wi-Fi chip, we created a debugger in software that directly accesses the hardware registers of the ARM Debugging core. As we do not have access to the JTAG port, we generate exceptions whenever a breakpoint or watchpoint is triggered. We handle those exceptions in our firmware patch and can then continue with the execution of the firmware code.[…]

https://github.com/seemoo-lab/nexmon_debugger

ARM assembly syntax (and REtools)

~ hucktech ~ Leave a comment

Bidirectional ARM Assembly Syntax Specifications

One of the tantalising pieces of information contained in ARM’s machine readable specifications is a specification of the assembly syntax. A few years ago (on an earlier) version of the specification, Wojciech Meyer and I decided to try to transform this specification into assemblers and disassemblers. At the time, this was not very useful to ARM because we already had assemblers and disassemblers so, although technically successful, the project died and the code has been slowly bitrotting ever since. In a few days time, I will be giving a talk at the 34th Chaos Communication Congress in Leipzig about practical things you can do with ARM’s specification and I thought it would be a good idea to suggest that someone creates a similar tool. But maybe it would be a good idea if I showed you what Wojciech and I did to get you started? Let’s start by digging into the HTML rendering of the ARM spec with the ADD instruction. The assembly syntax is in four parts. The first two parts show you the opcode diagram and the overall assembly syntax and is almost directly usable as a specification.[…]

https://alastairreid.github.io/bidirectional-assemblers/

https://events.ccc.de/congress/2017/Fahrplan/events/8915.html

See the above tweet for a thread about a related tool:

retools: a reverse engineering toolkit for normies

Collection of tools (disassembler, emulator, binary parser) aimed at reverse enginering tasks, more specifically, bug finding related. Currently we target ARMv7 and Mach-O though in the future more architectures and formats are planned. retools is somewhat unique in that most of the semantics for relevant instructions are parsed out of the specification PDFs as opposed to being generated by hand. Currently the disassembler, emulator, and binary parsers are partially done, with a symbolic execution engine and instrumentation/hooking framework to come as I get more time.

https://github.com/agustingianni/retools

 

ARM adds ACPIView tool to UEFI Shell: dump ACPI tables

~ hucktech ~ Leave a comment

For UEFI Shell uers, there is another ACPI diagnostic tool, in addition to CHIPSEC and acpidump. Excerpts of edk2-devel mailing list post and tool manpage below, see full list posting for source code and more info.

ShellPkg: Add acpiview tool to dump ACPI tables
This program is provided to allow examination of ACPI table contents from the UEFI Shell. This can help with investigations, especially at that stage where the tables are not enabling an OS to boot. The program is not exhaustive, and only encapsulates detailed knowledge of a limited number of table types. Default behaviour is to display the content of all tables installed. ‘Known’ table types will be parsed and displayed with descriptions and field values. Where appropriate a degree of consistency checking is done and errors may be reported in the output. Other table types will be displayed as an array of Hexadecimal bytes. To facilitate debugging, the -t and -b options can be used to generate a binary file image of a table that can be copied elsewhere for investigation using tools such as those provided by acpica.org. This is especially relevant for AML type tables like DSDT and SSDT. The inspiration for this is the existing smbiosview Debug1 Shell command. Many tables are not explicitly handled, in part because no examples are available for our testing. The program is designed to be extended to new tables with minimal effort, and contributions are invited.

acpiview
Display ACPI Table information.

ACPIVIEW [[-?] | [[-l] | [-s AcpiTable [-d]]] [-c] [-v] [-h Highlight]]
-l – Display list of installed ACPI Tables.
-s – Display only the specified AcpiTable type.
AcpiTable : The required ACPI Table type.
-d – Generate a binary file dump of the specified AcpiTable.
-c – Consistency checking (enabled by default).
-v – Display verbose data (enabled by default).
-h – Enable/Disable Colour Highlighting.
Highlight : TRUE/ON enables highlighting;
FALSE/OFF (default) disables highlighting.
-? – Show help.

Formatted display and checking is provided for these signature types:
APIC – Multiple APIC Description Table (MADT)
BGRT – Boot Graphics Resource Table
DBG2 – Debug Port Table 2
FACP – Fixed ACPI Description Table (FADT)
GTDT – Generic Timer Description Table
IORT – IO Remapping Table
MCFG – Memory Mapped Config Space Base Address Description Table
RSDP – Root System Description Pointer
SLIT – System Locality Information Table
SPCR – Serial Port Console Redirection Table
SRAT – System Resource Affinity Table
XSDT – Extended System Description Table

EXAMPLES:

To display a list of the installed table types:
fs0:\> acpiview -l

To parse and display a specific table type:
fs0:\> acpiview -s GTDT

To save a binary dump of the contents of a table to a file in the current working directory:
fs0:\> acpiview -s DSDT -d

To display contents of all ACPI tables:
fs0:\> acpiview

Linaro releases Enterprise Reference Platform 17.12

~ hucktech ~ Leave a comment

ERP 17.12 has been released!

The goal of the Linaro Enterprise Reference Platform is to provide a fully tested, end to end, documented, open source implementation for ARM based Enterprise servers. The Reference Platform includes kernel, a community supported userspace and additional relevant open source projects, and is validated against existing firmware releases. The Linaro Enterprise Reference Platform is built and tested on Linaro Enterprise Group members hardware and the Linaro Developer Cloud. It is intended to be a reference example for use as a foundation for members and partners for their products based on open source technologies. The members and partners to include distribution, hyperscaler or OEM/ODM vendors, can leverage the reference for ARM in the datacenter.
[…]
– Focused on ACPI and UEFI use-cases.
[…]

http://releases.linaro.org/reference-platform/enterprise/17.12/
https://platforms.linaro.org/documentation/Reference-Platform/Platforms/Enterprise/ReleaseNotes-17.12.md/

More info: linaro-announce@lists.linaro.org list archives:
https://lists.linaro.org/mailman/listinfo/linaro-announce

Pete Batard adds ARM support for VS2017 to Tianocore

~ hucktech ~ Leave a comment

Pete Batard  is adding Visual Studio for ARM support to the Tianocore UEFI dev toolchain:

This is a v2 of the previous patch, that takes into account the alignment of suppressed level 4 warnings between IA32, X64 and ARM, and that also removes compiler options that weren’t actually needed. The following series adds ARM compilation support for the VS2017 toolchain. With these patches, VS2017 toolchain users should be able to compile regular UEFI ARM applications using EDK2. Note that, unlike ARM64 support, ARM support does not require a specific update of Visual Studio 2017, as the ARM toolchain has been available from the very first release. We tested compiling and running the full UEFI Shell with this series, as well as a small set of applications and drivers, and found no issues. With an additional patch [1], it is also possible to use this proposal to compile a complete QEMU ARM firmware. As the patch shows, the changes that need to be applied to the EDK2 sources to achieve this are actually very minimal. However, the generated firmware does not currently boot, possibly because of the following warnings being generated by the MS compiler[…[]At this stage, since the goal of this series is to allow users to compile regular ARM UEFI applications using the VS2017 toolchain, I have non plans to spend more time on the QEMU firmware issues, especially as I suspect that reducing the firmware size back to 2 MB may not be achievable without Microsoft altering their compiler. I am however hopeful that ARM specialists can take this matter over eventually…

[1] https://github.com/pbatard/edk2/commit/c4ce41094a46f4f3dc7ccc64a90604813f037b13

More info:
http://pete.akeo.ie/2017/05/compiling-desktop-arm-applications-with.html
https://lists.01.org/mailman/listinfo/edk2-devel
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/18614308-add-arm-support-back
https://blogs.msdn.microsoft.com/vcblog/2017/10/23/arm-gcc-cross-compilation-in-visual-studio/
https://github.com/microsoft/vslinux/issues
https://github.com/Microsoft/VSLinux/issues/110

See-also:
http://shadetail.com/blog/using-visual-studio-code-for-arm-development-introduction/

Note that Pete is not from the Microsoft Visual Studio team, he’s just doing their work for them… I hope the VS team gives Pete a complementary subscription to their commercial product! [Strange, I don’t think I’ve ever seen Microsoft add suppport for their own tools to Tianocore, it is always an external vendor that does Microsoft’s work…]

 

Duo Labs releases: IDAPython, Coretex M Firmware and Amnesia modules

~ hucktech ~ 1 Comment

https://twitter.com/tmanning/status/932421897370812417

Examining Personal Protection Devices: Hardware and Firmware Research Methodology in Action
Todd Manning, Duo Labs
[…]This paper describes a methodology for retrieving device firmware, and for loading firmware into IDA Pro, a common disassembler. This paper focuses on the disassembly of this firmware, and the discussion of a novel approach to defeating readback protection discovered in one ARM Cortex M implementation. During the course of this research, I developed code for IDA Pro to assist in loading and grooming Cortex M firmware images. The IDAPython code is comprised of two modules. The first module annotates Cortex M vector tables, which gives IDA Pro hints about where code exists in the firmware image. The Cortex M module can automatically annotate firmware with a vector table located at the start of a firmware image, or can be tailored by the end user to work with relocated tables. The second module, called Amnesia, uses byte-level heuristics to detect ARM instructions in the firmware. Amnesia also contains heuristics that operate at the ARM instruction level to determine function boundaries based on common ARM function prologues and epilogues.[…]

Cortex M Firmware (cortex_m_firmware.py): This Cortex M Firmware module grooms an IDA Pro database containing firmware from an ARM Cortex M microcontroller. This module will annotate the firmware vector table, which contains a number of function pointers. This vector table annotation will cause IDA Pro to perform auto analysis against the functions these pointers point to. The Cortex M Firmware module also calls into the Amnesia module to automate discovery of additional code in the firmware image using the Amnesia heuristics.

Amnesia (amnesia.py): Amnesia is an IDAPython module designed to use byte level heuristics to find ARM thumb instructions in undefined bytes in an IDA Pro database. Currently, the heuristics in this module find code in a few different ways. Some instructions identify and define new code by looking for comon byte sequences that correspond to particular ARM opcodes. Other functions in this module define new functions based on sequences of defined instructions.

https://duo.com/blog/examining-personal-protection-devices-hardware-and-firmware-research-methodology-in-action

https://github.com/duo-labs/idapython

new ARM instructions for 8.4-A*

~ hucktech ~ Leave a comment

The Arm Architecture is continually evolving, and this blog gives a high-level overview of some of the changes made in Armv8.4-A*. We develop these changes by listening to the Arm Ecosystem and working with them to provide new functionality that benefits everyone. These are incremental changes to the architecture and do not introduce any significant new features. Previous incremental versions of the architecture have been introduced for v8.3-A, v8.2-A, and v8.1-A. The rest of this blog introduces some of the new functionality. It does not offer a complete feature list. However, over the next few months we will be describing this functionality in more detail.[…]

https://community.arm.com/processors/b/blog/posts/introducing-2017s-extensions-to-the-arm-architecture

ARM assembler quickref

~ hucktech ~ Leave a comment

ARM Assembly Basics Cheatsheet

This ARM assembly basics cheatsheet covers registers, instructions, branching, and conditional execution. You can use it as a guideline if you’re starting out with ARM assembly and need a little refresher of the basics.

Assembly Basics Cheatsheet

ARM IETF I-D changes from FUD to SUIT

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2017/07/18/arm-ietf-id-on-iot-firmware-update-architecture/
It looks like the Internet Draft has changed from “fud” to “suit”:
https://tools.ietf.org/html/draft-moran-suit-architecture-00
The “fud” list is gone, and there is a new “suit” mailing list:
https://www1.ietf.org/mailman/listinfo/suit

A Firmware Update Architecture for Internet of Things Devices
draft-moran-suit-architecture-00
October 30, 2017

Vulnerabilities with IoT devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. This document specifies requires and an architecture for a firmware update mechanism aimed for Internet of Things (IoT) devices. The architecture is agnostic to the transport of the firmware images and associated meta-data. This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices.

 

Fall UEFI Plugfest agenda

~ hucktech ~ Leave a comment

The Fall UEFI Plugfest is happening, a week of interop testing with UEFI vendors, along with some presentations. The presentation abstracts are below, see the full itenary for speaker bios.

http://www.uefi.org/events/upcoming

http://www.uefi.org/sites/default/files/resources/Agenda%20and%20Session%20Abstracts%20-%20Final_Oct%2024%202017.pdf

“Last Mile” Barriers to Removing Legacy BIOS (Intel)
While UEFI has become a dominant standard since its introduction in 2005, many use cases still rely on compatibility with PC/AT Legacy BIOS. These legacy corner cases are a barrier to completing the transition to modern firmware standards. Intel has identified maintaining compatibility as an issue for platform security and validation costs, and plans to eliminate legacy BIOS elements in our 2020 data center platforms. This session discusses “last mile” gaps for 16-bit compatibility and identifies UEFI capabilities that the industry can promote as alternatives, including HTTPS Boot, OS Recovery, and Signed Capsule Update.

UEFI Firmware – Security Concerns and Best Practices (Phoenix)
(no Abstract)

Strategies for Stronger Software SMI Security in UEFI Firmware (Insyde)
Avoid design errors and software coding pitfalls when implementing SMI handlers. Device manufacturers customize UEFI firmware using new runtime interfaces that are implemented using software SMIs. Heavy customization, tight deadlines and poor code implementation can accidentally allow malware to abuse the power of SMM. This session focuses on four common software SMI vulnerabilities and how to change your UEFI firmware and applications to avoid them.

Advances of UEFI Technologies in ARM Systems (ARM)
This session will discuss the ARM-related interfaces defined in the latest UEFI and ACPI specifications, the requirements of the UEFI and ACPI interfaces for the SBBR Specification, and the use of UEFI SCT and FWTS in the SBBR compliance test. Also, discussed will be the required UEFI interfaces for the embedded space when the separation of the device and OS development is desired.

Introduction to the Self-Certification Test (SCT) in UEFI World (Canonical and Intel)
The UEFI Test Working Group (UTWG) endorses two test suites: Firmware Test Suite (FWTS) and the UEFI Self-Certification Test (SCT). FWTS is focused on validating Linux compatibility, and is endorsed by UTWG for ACPI validation. The UEFI SCT is designed to validate firmware and driver behavior per the UEFI Specification. This session demonstrates the operation of both tools, and discusses how they use open source models to improve test quality.

Firmware Test Suite Introduction: Uses, Development, Contribution and GPL (Canonical)
Firmware Test Suite (FWTS) is the recommended ACPI 6.1 Self-Certification Test (SCT). This command line tool is easy to use and provides explanatory and informative. Its open-source nature allows developers to add new tests easily, and many code examples such as ACPI, UEFI and SMBIOS are available for references. Code contribution are appreciated and technical discussion and code reviews on the mailing list are answered by an active community. As licensed by GPL, FWTS ensures it is available and suitable to everyone who wants to use it publicly and privately.

NFC and UEFI (AMI)
NFC is a technology that has permeated many aspects of everyday life. Using NFC, you can now pay with your phone or enter secure building areas. However, the UEFI specification lacks any implementation of NFC. AMI will cover a proposed solution for NFC implementation in UEFI, how to best fit NFC into the UEFI specification, and potential use cases.

Edk2 Platforms Overview (Linaro)
For a couple of years now, the Linaro OpenPlatformPkg repository has been used to collate a number of (at least partially) open source EDK2 platform ports. However, with a now properly defined process for the TianoCore edk2-platforms and edk2-non-osi repositories, these platforms are now moving over there and OpenPlatformPkg. This session will discuss the process, the current state of things and the practicalities of working with edk2-platforms.

UEFI Manageability and REST Services (HPE and Intel)
With the increase in platform firmware complexity and capabilities, there is an increased need to standard firmware manageability is increasing. The UEFI 2.7 Specification defines REST services to provide secure solutions for managing modern platforms. This session describes enterprise configuration scenarios, discusses implementation gaps in the UEFI specification, and proposes enhancements related to vendor-specific REST services.