ARM Technical Learning Resources

Tom Stevens of ARM posted a blog with a new list of links for developers new to ARM. About 40 links, mostly on ARM assembly and C, Cortex-M, NEON, ARMv8/AArch64. Here’s a list of the initial 10 or so links’s titles:

Getting Started with ARM Microcontroller and Assembly Programming
How to Load Constants in Assembly for ARM Architecture
Branch and Call Sequences Explained
Building Customized Debug and Trace Solutions for Multicore SoCs
Caches and Self-Modifying Code
Code Size: A Comprehensive Comparison of MicroMIPS32 and Thumb Code Size Using Many Megabytes of Customer Code
How to Call a Function from ARM Assembler
Designing in ARM: Part One- Switching Microcontrollers
Getting Started with ARM Assembly and C Programming
Detecting Overflow from MUL

Full article:
https://community.arm.com/groups/processors/blog/2015/03/03/important-arm-technical-learning-resources

If this were done outside ARM.com, it’d probably github-hosted and called ‘awesome-arm-development.md’. (BTW, I’m slowly working on an ‘awesome firmware’ link collection, if someone doesn’t do one first…)

ARM Security Extensions

There’s a new blog post on the ARM blog, talking about Security Extensions and Privilege Levels in ARMv8-M Cortex systems:

Security Extensions and Privilege Levels
[…]
ARMv8-M introduces Security Extensions that provide hardware features for more secure devices. The Security Extensions allow the protection of trusted and system resources from untrusted handlers and applications. They can be executed without the additional software sandboxing overheads of reprogramming the MPU.  The Security Extensions collaborates with the associated software model to provide a mechanism to restrict access to system resources and processes through well-defined interfaces similar to system calls, thereby ensuring a higher level of protection and also offering an implicit privilege-stack. […]

https://community.arm.com/groups/processors/blog/2016/03/21/security-extensions-and-privilege-levels?et=blogs.comment.created#comment-19571

Updating Android devices

Sam Varghese has a story on ITWire about how Android-based devices are hard to update, including some conversation about firmware:

[…] x86 processors have a long history of standardisation. An x86 processor is mostly made of the CPU and an interface to the BIOS/UEFI firmware on the motherboard. From there the operating system can gather the information about the hardware components present in the system. In comparison, ARM processors, especially in the Android/embedded market are System-on-Chips (SoCs). This means, apart from the CPU the SoC provides most to all peripheral components on one die (e.g. network chip, USB chip, display chip, etc). Apart from that, although ARM has standard components for the core system (e.g. interrupt controller, timers etc), most ARM SoCs implement their custom components here, which needs their own drivers in the kernel. The reason is because many companies which produce ARM-based processors have a long history in the mobile phone market in the pre-smartphone era. They have core components which were developed years ago and they want to re-utilise them, as they have a deep knowledge on how they work and their custom software drivers. Third, especially in the embedded world, the ARM processors don’t use the Unified Extensible Firmware Interface (UEFI) to communicate with the firmware. To tell the Linux kernel which components are present, the bootloader passes a device tree blob to the kernel. So there is no dynamic way to tell the kernel which components are present. This is changing a lot and the Linux community are putting a big effort in standardising the firmware interface (EFI, PSCI, ACPI). […]

http://www.itwire.com/business-it-news/open-source/71698-why-updating-android-without-vendor-help-is-a-nightmare.html

LDRAlite added to ARM updated DS-5

ARM DS-5 Development Studio Extends Support for Functional Safety with LDRA’s MISRA Compliance Tools

Cambridge, UK, Feb. 23, 2016 – ARM today announced the integration of industry-leading MISRA (Motor Industry Software Reliability Association) conformance tools into the ARM® DS-5 Development Studio tool suite. The addition of a MISRA-checking capability to its TÜV-certified ARM Compiler and safety qualification kit makes DS-5 the ideal software development platform for ARM-based products in use in safety-critical markets such as automotive, healthcare and industrial automation. LDRAlite™ for ARM DS-5 software is supplied by LDRA, a member of the MISRA Standards Committee. The company has been providing industry safety expertise for markets including avionics, automotive, medical, industrial, and rail for more than 40 years. The LDRAlite tool will be a key enabler for developers creating functional safety applications with the DS-5 Development Studio as it enables compliance with functional safety standards including ISO 26262 and IEC 61508. These standards, used widely in safety-critical applications in the automotive and industrial markets, recommend the use of the MISRA programming guidelines for C/C++ to improve software product quality, consistency, clarity, and maintainability. To achieve MISRA compliance in these safety-critical markets cost-effectively, the LDRAlite MISRA checker automates the process of analyzing code to ensure adherence to the guidelines in the standard, saving time, energy and money compared with traditional manual inspection methods. LDRAlite strengthens the ARM-based functional safety qualification kit by augmenting the DS-5 TUV certified compiler and simplifying the end-product certification process. LDRAlite will be included with DS-5 starting from version 5.24 as a 30-day evaluation and can be converted to a full license through LDRA.

http://www.arm.com/about/newsroom/arm-ds-5-development-studio-extends-support-for-functional-safety-with-ldras-misra-compliance-tools.php
http://www.ldra.com/en/company/technology-partners/toolintegration/27
http://www.ldra.com/en/company/event/event?ident=258

efitools now available for ARM

James Bottomley has a few new blog posts, two on efitools availability for ARM, and another on a container model for UEFI.

http://blog.hansenpartnership.com/efitools-for-arm-released/
http://blog.hansenpartnership.com/efitools-arm-32-bit-build-fixed/

Constructing Architecture Emulation Containers

[…] the problem: how to build and test efitools for arm and aarch64 while not possessing any physical hardware.  The solution is to build an architecture emulation container using qemu and mount namespaces such that when its entered you find yourself in your home directory but with the rest of Linux running natively (well emulated natively via qemu) as a new architecture.  […] However, there’s a problem here: the installed binary emulator usually runs as /usr/bin/qemu-${arch}, so if you’re running a full operating system container, you can’t install any package that would overwrite that.  Unfortunately for me, the openSUSE Build Service package osc requires qemu-linux-user and would cause the overwrite of the emulator and the failure of the container.  The solution to this was to bind mount the required emulator into the / directory, where it wouldn’t be overwritten and to adjust the binfmt_misc paths accordingly. […]

http://blog.hansenpartnership.com/constructing-architecture-emulation-containers/
http://blog.hansenpartnership.com/constructing-architecture-emulation-containers/build-container/

ARM at EmbeddedWorld

ARM has a new article out, covering their latest technology they’re showcasing at Embedded World in Germany shortly. There are “26 sessions and 15 classes” on ARM technologies at Embedded World. Even if you aren’t attending this event, the article is a good roadmap to upcoming products by ARM and ARM’s partners.

https://community.arm.com/groups/embedded/blog/2016/02/09/arm-at-embedded-world-2016-a-guide

Motorola bootlocker unlocking

Unlocking the Motorola Bootloader

In this blog post, we’ll explore the Motorola bootloader on recent Qualcomm Snapdragon devices. Our goal will be to unlock the bootloader of a Moto X (2nd Gen), by using the TrustZone kernel code execution vulnerability from the previous blog posts. Note that although we will show the complete unlocking process for this specific device, it should be general enough to work at-least for most modern Motorola devices. […]

Full post:
http://bits-please.blogspot.com/2016/02/unlocking-motorola-bootloader.html

reversing ARM1 conditionals

Conditional instructions in the ARM1 processor, reverse engineered
By carefully examining the layout of the ARM1 processor, it can be reverse engineered. This article describes the interesting circuit used for conditional instructions: this circuit is marked in red on the die photo below. Unlike most processors, the ARM executes every instruction conditionally. Each instruction specifies a condition and is only executed if the condition is satisfied. For every instruction, the condition circuit reads the condition from the instruction register (blue), evaluates the condition flags (purple), and informs the control logic (yellow) if the instruction should be executed or skipped. […]

Full post:
http://www.righto.com/2016/01/conditional-instructions-in-arm1.html

Zero perms to TrustZone: Android mediaserver CVEs discussion

https://pbs.twimg.com/media/CZgC2lkUEAA16RP.png:large

Android privilege escalation to mediaserver from zero permissions (CVE-2014-7920 + CVE-2014-7921)

In this blog post we’ll go over two vulnerabilities I discovered which, when combined, enable arbitrary code execution within the “mediaserver” process from any context, requiring no permissions whatsoever. How bad is it? The first vulnerability (CVE-2014-7921) was present in all Android version from 4.0.3 onwards. The second vulnerability (CVE-2014-7920) was present in all Android versions from 2.2 (!). Also, these vulnerabilities are not vendor specific and were present in all Android devices. Since the first vulnerability is only needed to bypass ASLR, and ASLR is only present (in a meaningful form) from Android 4.1 onwards, this means that these vulnerabilities allow code execution within “mediaserver” on any Android device starting from version 2.2. Although I reported both vulnerabilities in mid October 2014, they were unfortunately only fixed much later (see “Timeline” for full description, below) – in Android version 5.1!  This means that there are many devices out there which are still vulnerable to these issues, so please take care. You can find the actual patches here. The patches were pushed to AOSP five months after the vulnerabilities were reported. That said, the Android security team was very pleasant to work with, and with other vulnerabilities I reported later on, were much more responsive and managed to solve the issues within a shorter time-frame.
[…]

Full post:
http://bits-please.blogspot.com/2016/01/android-privilege-escalation-to.html

Sigh, it seem harder to track ARM firmware bugs, since they’re often hidden in the description of an app bug. And SCAP has no firmware OVAL definitions for CVEs to mention things like TrustZone. 😦

AArch64 Xen gets Dom0 ACPI support

Shannon Zhao of Huawei submitted a 17-part patch to the Linux-ARM-kernel, Linux-EFI, Linux-Kernel, and Xen-devel lists, which adds ACPI support for Xen Dom0 on AArch64 systems.

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from [1]. The corresponding Xen patches can be fetched from [2].

  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
  FDT: Add a helper to get specified name subnode
  Xen: EFI: Parse DT parameters for Xen specific UEFI

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] http://git.linaro.org/people/shannon.zhao/xen.git  ACPI_XEN_ARM_V3
http://vger.kernel.org/majordomo-info.html

AArch64 gets ACPI NUMA support

Hanjun Guo of Huawei submitted a 12-part patch to the Linux-ACPI, Linux-ARM-Kernel, and Linux-Kernel lists, which adds ACPU NUMA (Non-Uniform Memory Access) support for AArch64 systems.

Based on Ganapat’s v9 dt based NUMA patch set [1] for ARM64, this patch set introduce the ACPI based configuration to provide NUMA information. ACPI 5.1 already introduced NUMA support for ARM64, which can get the NUMA domain information from SRAT and SLIT table, so parse those two tables to get mappings from cpu/mem to numa node configration and system locality.

  acpi, numa: Use pr_fmt() instead of printk
  acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
  acpi, numa: remove duplicate NULL check
  acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
  arm64, acpi, numa: NUMA support based on SRAT and SLIT
  acpi, numa: Enable ACPI based NUMA on ARM64
  acpi, numa: move acpi_numa_slit_init() to common place
  arm64, numa: rework numa_add_memblk()
  x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
  acpi, numa: move bad_srat() and srat_disabled() to common place
  acpi, numa: remove unneeded acpi_numa=1
  acpi, numa: reuse acpi_numa_memory_affinity_init()

[1] http://lwn.net/Articles/672329/

http://vger.kernel.org/majordomo-info.html
http://wiki.xen.org/wiki/Xen_on_NUMA_Machines
https://wiki.linaro.org/LEG/Engineering/Kernel/NUMA

ARM-based AMD device launched

AMD has used to be x64-based company. But now they’ve also got ARM technology in some of their new products, so things are about to get interesting, how this will turn out.,. Joel Hruska reports in ExtremeTech on the Opteron-A1100:

http://www.extremetech.com/extreme/221282-amds-first-arm-based-processor-the-opteron-a1100-is-finally-here?sf19369490=1

AMD’s first ARM-based processor, the Opteron A1100, is finally here

Today AMD is formally launching its first ARM processor core, the Opteron A1100. AMD first announced its plans to enter the ARM market in 2013, with the chip expected to ship by mid-2014. The company apparently began early sampling around that time frame, but is only now launching the processor. The new Opteron A1100 is pretty much what AMD promised in its early previews of the device. It packs eight Cortex-A57 CPU cores, with each pair of cores sharing a 1MB L2 (512K effectively allocated to each chip). An 8MB L3 cache backs the entire CPU cluster, and the CPU supports both DDR3 and DDR4. ECC support is also provided.

Win10 for ARM?

It sounds like non-embedded Windows may end up being available for platforms outside Intel again. Long ago, Microsoft Windows NT supported MIPS, Alpha, PowerPC, Itanium, as well as x86/x64. Embedded Windows supported many other processors, including ARM. And Microsoft already has ARM-based Surface devices, and Windows 10 for ARM-based RPI2.

http://www.winbuzzer.com/2016/01/14/rumor-microsoft-to-offer-windows-10-desktop-edition-for-arm-architecture-xcxwbn/

https://msdn.microsoft.com/en-us/windows/hardware/dn940797%28v=vs.85%29.aspx
http://www.ubergizmo.com/2016/01/microsoft-might-be-developing-windows-10-for-arm-based-processors/
http://www.windowscentral.com/desktop-version-windows-10-arm-based-chips-might-be-development

 

 

TRUSTNONE: a TrustZone vulnerability

Fire Water has disclosed TRUSTNONE, a TrustZone vulnerability, related to signed comparison on unsigned user input leading to arbitrary read/write capabilities of secure memory/registers in an ARM TrustZone implementation.

“Discovered and documented by Sean Beaupre (beaups)”

“This vulnerability was successfully exploited to unlock the Motorola Droid Turbo’s bootloader.”

Click to access TRUSTNONE_1.0-11282015.pdf

TrustZone exploration series

“Bits, Please!” has a very nice blog post on understanding TrustZone implementation on Qualcomm Snapdragon SOC:

http://bits-please.blogspot.fr/2015/08/exploring-qualcomms-trustzone.html

Watch for the next blog:

In the next blog post, I’ll cover more details about Qualcomm’s TrustZone implementation, and the vulnerability I discovered and exploited within its kernel. “

ARMv8-M announced

Lots of sites have stories on the new ARMv8-M announced this week at TechCon 2015:

http://www.businesswire.com/news/home/20151110005179/en/ARMv8-M-Architecture-Simplifies-Security-Smart-Embedded-Devices

http://www.theregister.co.uk/2015/11/10/arm_trustzone_armv8m_mbed_os/
http://www.eweek.com/security/arm-brings-trustzone-security-technology-to-iot-devices.html
http://www.anandtech.com/show/9775/arm-announces-armv8m-instruction-set
http://hexus.net/tech/news/industry/87980-armv8-m-architecture-launched/

 

Kris Brosch on dumping ARM SoC firmware

From Binni Shah’s twitter feed, Kris Brosch has a new article on Include Security blog, on obtaining a copy of the firmware of a reverse-engineered ARM SoC device:

Sometimes you can get access to the firmware without touching the hardware, by downloading a firmware update file for example. More often, you need to interact with the chip where the firmware is stored. If the chip has a debug port that is accessible, it may allow you to read the firmware through that interface. However, most modern chips have security features that when enabled, prevent firmware from being read through the debugging interface. In these situations, you may have to resort to decapping the chip, or introducing glitches into the hardware logic by manipulating inputs such as power or clock sources and leveraging the resulting behavior to successfully bypass these security implementations. This blog post is a discussion of a new technique that we’ve created to dump the firmware stored on a particular Bluetooth system-on-chip (SoC), and how we bypassed that chip’s security features to do so by only using the debugging interface of the chip. We believe this technique is a vulnerability in the code protection features of this SoC and as such have notified the IC vendor prior to publication of this blog post. […]

Full article:
http://blog.includesecurity.com/2015/11/NordicSemi-ARM-SoC-Firmware-dumping-technique.html

Open Estuary: ecosystem for AArch64 systems

Quoting their documentation:

Estuary provides a total solution for general-purpose computer based on aarch64 architecture. Anyone can quickly bring up an ARM64 platform – both software and hardware with Estuary. The major goals for Estuary project are:
* A stable\available quick start solution based on ARM64 computer, so that anyone can easily get and bring up the complete development environment, so that you can just focus on your particular field quickly.
* A common basic platform, which should be sustainable and will be continuously improved, can attract\absorb and integrate all 3rd part achievement ceaselessly.
* Sufficient technological documentation, so that any user or partner can easily get useful help from it.
* Simple and effective communication forum for ARM64 ecosystem, so that users can interact and share each other to improve ARM64 ecosystem.
* A bug tracking system, so that anyone can raise, track and help to resolve the issues, this will help to mature the solution and enhance the ecosystem.
* Multiple ARM64-based hardware platforms, and related software to speed up the ARM64 ecosystem development.
* The most key goal of Estuary project is to support, enable and speed up the maturity of ARM64 ecosystem.

For hardware, they currently support two AArch64 SOC boards, D01, D02 boards. For OS, they support Linux or Windows. For, firmware they say they support “Multi-kinds of boot loader will be enabled for Estuary, include but not limited to UEFI\Grub, uboot.” But currently they appear to support UEFI and GRUB. Amongst the other tools included in Estuary is a LAVA system, Linaro’s Automated Validation system, which performs continuous integration on QEMU- and multiple ARM-based devices, letting you reinstall firmware, OS, run pre-OS tests, and gather results.

They include their UEFI changes in their project changelogs, eg their 2.0 release from last month included two entries on UEFI:
9. Pubished the latest UEFI source code for D02 and eanbled building UEFI from source code directly.
11. Upgraded UEFI to add PCIE scaning.
    a. Remove GE4 and keep only GE5 on UEFI, to avoid confusion with 2 NICs.
    b. Re-enable PCI Express link up for port 1 and 2 (According to PCI Express slots on the board).
    c. Fix PXE timeout issue.
    d. Re-enable showbrdnum and setbrdnum commands on EBL.
    e. Fix several other bugs.

They are still using Ubuntu 12.04.
More information:

http://open-estuary.com/uefi-and-grub
https://github.com/open-estuary/uefi
https://github.com/open-estuary/uefi.git
http://git.savannah.gnu.org/cgit/grub.git
http://open-estuary.com/estuary/
http://open-estuary.com/estuary-v2-0/
http://open-estuary.com/d02-2/
http://open-estuary.com/d01-2/