Alexandre Belloni submitted a patch to the Linux-kernel list with patch to run Position Independent Executables (PIEs) on ARM:
Embedding Position Independent Executables: This series introduces Position Independent Executables (PIEs) for the ARM architecture. The main goal is to avoid having to write low level code in assembly as this is currently the case for suspend/resume. Multiple platforms will benefit from this infrastructure: at91, rockchip, sunxi, am335x. I’ve still avoided using the ELF header itself to be more efficient. For example, for atmel, the PIE is 66772 bytes when embedded in an ELF versus 344 bytes standalone. This is working properly because the PIE is self standing and correctly padded. Changes in v2: – handle big endian – handle gcov and ftrace by disabling them before compilling the PIE – Get the alignment from the original ELF to ensure the PIE is properly aligned in SRAM. – stop using fncpy – rebased on v4.7-rc1
UEFI has a bytecode, the uEfi ByteCode (EBC). It has traditionally been a bytecode used to consolidate all 3 Intel platforms (x86, x64, Itanic), into a single bytecode, so there only needs to be a single driver on the flash, saving flash memory. Unfortunately, it only supported Intel platforms, not ARM, so it was not a universal bytecode for EFI, only a bytecode for Intel systems. Now, someone has ported AArch64 to ARM, so now EBC may now be more interesting!
Wilfred Nilsen of ARM wrote a new post on the ARM IoT blog, click on blog URL below for video:
IoT Security: Creating X.509 Chain of Trust Learn the entire process of setting up the chain of trust for your IoT solution. The video, which is available on YouTube, provides a practical example that you can follow and setup on your own computer for learning purposes. The comprehensive video tutorial guides you through the process of setting up secure and trusted communication. After completing the hands-on tutorials, you will be an expert in using SSL for secure communication and how to create and manage SSL certificates. The video shows how to create an Elliptic Curve Cryptography (ECC) certificate for the server, how to install the certificate in the server, and how to make the clients connecting to the server trust this certificate. The server in this video is installed on a private/personal computer on a private network for test purposes.
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. […]”
Jim Wallace has a new post on the ARM Embedded blog, on “Securing the embedded IoT world”.
Simply put, security for Embedded IoT devices is about protecting assets from malicious attack. Typically this protection is thought about in terms of keeping some assets, such as crypto keys, secret and controlling how software and data is modified. In order for the Internet of Things (IoT) to be successful it is important that devices and services are appropriately protected. As IoT products become successful they will become increasingly attractive for attackers and so appropriate security must be baked into every system and at every level. This will require a scalable “building block” approach where designers can use established security approaches that can scale from low cost microcontrollers through to high performance application processor based systems. However, understanding how to protect devices, data and services can be an overwhelming task for developers who are new to security and who must focus on other challenges such as battery life, form factor and user interfaces, just to name a few. […]
ARM Shellcode Generator: Shellcodes for ARM/Thumb mode. Ideas came from shell-storm and pwntools/pwnies. Thanks to share all of brilliant sources on the net. I’m interested in mobile platform and archtecture like Android on ARM, Router on MIPS and so on. This project named ARMSCGen focus on shellcode on ARM Architecture especially ARMv7 Thumb Mode.
[…] “The latest milestone in our HPC journey came this week at the International Supercomputing Conference (ISC) in Frankfurt. Fujitsu, a global leader in HPC, announced Japan’s next-generation flagship supercomputer at the RIKEN Advanced Institute for Computational Science, will be powered by SoCs based on the ARMv8-A architecture. The “Post-K” supercomputer is the successor to the “K-supercomputer” which is currently ranked No. 5 in the Top 500 supercomputing rankings. Today, the K-computer today is used to solve critical compute problems in fields ranging from earthquake/tsunami research to drug discovery. The K-computer has taken complex problems like a human heart simulation that previously took 2 years and delivered results in 1 day. The Post-K computer is being developed to address similar challenges.” […]
Daniel Ohara has posted a new article on the ARM blog, starting to show the debugging features of the commercial SOMNIUM DRT tools:
Debugging Embedded Systems: the Problems and Solutions This article is the first in a series on the new debug features in SOMNIUM DRT. We all know from experience(and this is confirmed by many studies) that debugging takes up a significant part of the time in software development. Software systems are complex and debugging is hard. This is especially true for embedded systems where there may be real-time constraints on when data is received or sent, the timing of interrupts, and so on. This means that traditional techniques, such as breakpoints or changing to code to print out state information, cannot be used because they will drastically change the timing and therefore the behavior of the program. Program flow is often controlled by asynchronous and external events, for example inputs from touch sensors and other peripherals. Therefore the real-time behavior of the program cannot be understood simply by looking at the control flow in the source code. SOMNIUM DRT includes features to support debugging embedded systems. One of these enables the live, non-intrusive display of interesting data. Another is the ability to trace program flow so you can step backwards and forwards through the execution history to see how you to to a particular state. SOMNIUM DRT is is a set of development tools for ARM Cortex-M based devices [such as the Kinetis and LPC devices from NXP and the STM32 devices from STMicroelectronics]. It is fully compatible with industry-standard tools such as the GNU toolchain and Eclipse IDE. DRT uses our patented techniques to produce highly optimized code by exploiting information about the embedded processor, the memory system and other peripherals to deliver improved performance, lower code size and reduced energy use. It also includes some great debugging tools such as trace, live expressions and fault diagnosis. […]
In this blog post we’ll continue our journey from zero permissions to code execution in the TrustZone kernel. Having previously elevated our privileges to QSEE, we are left with the task of exploiting the TrustZone kernel itself.
“Why?”, I hear you ask. Well… There are quite a few interesting things we can do solely from the context of the TrustZone kernel. To name a few: * We could hijack any QSEE application directly, thus exposing all of it’s internal secrets. For example, we could directly extract the stored real-life fingerprint or various secret encryption keys (more on this in the next blog post!). * We could disable the hardware protections provided by the SoC’s XPUs, allowing us to read and write directly to all of the DRAM. This includes the memory used by the peripherals on the board (such as the modem). * As we’ve previously seen, we could blow the QFuses responsible for various device features. In certain cases, this could allow us to unlock a locked bootloader (depending on how the lock is implemented).
So now that we’ve set the stage, let’s start by surveying the attack surface! […]
ARMPWN challenge write-up: A few weeks ago, I came accross @5aelo repo called armpwn for people wanting to have a bit of ARM fun. I had recently spent some time adding new features and perfectionning old ones to my exploit helper gdb-gef and I saw there a perfect practice case. On top of that, I had nothing better to do yesterday ☺ This challenge was really fun, and made so much easier thanks to gef especially to defeat real life protections (NX/ASLR/PIC/Canary), and on a different architecture (Intel is so ‘90). This is mostly why I’m doing this write-up, but feel curious and do it by yourself. Fun time ahead guaranteed ☺ […]
ARM has some new security videos in the works, targetting developers.
<soapbox>I hate “webinars”. Why require people to signup to watch an online video, often only at a particular time?. An evil marketing trick, good way to see how mature a company is. Just post the videos online and let people watch it when they want, and not have to register to watch them! </soapbox>
bfuller has a post ARM’s Android Community blog, with a whitepaper for OEMs on how to deal with Google making Android apps run on ChromeOS systems:
Google on May 19 announced that Android apps are coming to Chromebook. Here is a backgrounder on what the move means for developers, OEMs and consumers. […] The move is likely to have a profound impact on the Chromebook market but also more broadly on clamshell, two-in-one and hybrid form factors. In some ways, the move echoes the impact that the Android development community and ARM ecosystem had in 2009, at the dawn of the smart phone era. What exactly the announcement mean for developers, OEMs and consumers? We’ve posted a detailed article (Android Apps on Chromebook.pdf) that dives into the possibilities and implications of making Android apps available on Chromebooks. Check it out and let us know how the news will affect your work! […]
AMI has been into the x86/x64 platform for a long time, but now they’re porting some of their tools to ARM. Excerpting their press release:
American Megatrends Extends ROM Utilities Support for ARM-based Projects
AMI is extending their ROM Utilities support for ARM-based projects. These utilities allow modifications to be made to the ARM-based firmware images without having to rebuild the firmware. A single build can be modified and used on several platform derivatives. AMI customers now have additional support for various tools to use with ARM-based projects. ARM firmware support has been incorporated in the following AMI ROM Utilities: AMIBCP, AMISDE, ChangeLogo, and MMTool. These utilities allow for post-build configuration of certain settings within the ARM-based firmware images. Since the tools were extended to support ARM-based projects, the user experience remains the same. All the available tools are compatible with AMI’s flagship Aptio® V UEFI Firmware and designed to work in conjunction with the firmware.
* AMI ARM-based projects can be developed in the same Aptio development environment that BIOS engineers are already familiar with, including Linux support * Full support for manufacturing with flash, SMBIOS, setup tools and more * OEM customization tools are available to modify the firmware image without the need to rebuild the project
Eoin McCann of ARM has a new blog post on the topic of system validation that gives an introduction to how ARM enables this for it’s partners.
System Validation at ARM: Enabling our Partners to Build Better Systems […] SoCs have evolved into complex entities that integrate several diverse units of intellectual property (IP). A modern SoC may include several components such as CPUs, GPU, interconnect, memory controller, System MMU, interrupt controller etc. The IPs themselves are complex units of design that are verified individually. Yet, despite rigorous IP-level verification, it is not possible to detect all bugs – especially those that are sensitized only when the IPs interact within a system. This article intends to give you some behind-the-scenes insight into the system validation work done at ARM to enable a wide range of applications for our IP. Many SoC design teams attempt to solve the verification problem individually using a mix of homegrown and commercially available tools and methods. The goal of system validation at ARM is to provide partners with high quality IP that have been verified to interoperate correctly. This provides a standardized foundation upon which partners are able to build their own system validation SOC solutions. Starting from a strong position, their design and verification efforts can be directed more at the design differentiation they add to the SoC and its interactions with the rest of the system. […]
PS: Re: the last few sentences in the above expert, I am still trying to find the ARM equivalent of Intel CHIPSEC. And/or waiting for Linaro to finish porting LUV (which includes CHIPSEC) to ARM (but hoping they’ll also target AArch32 not only AArch64, both targets need firmware security validation tools, not just the ones they’re banking the most on). ARM is more complex than current Intel CHIPSEC situation, each ARM IP licensee will need to write a handful of new ARM-flavored CHIPSEC security tests, to deal with the nuances of their system. Is there even an ARM security team, whose charter might include a CHIPSEC port?
You must be logged in to post a comment.