Firmware Summit results

Al Stone of Red Hat posted a summary of the recent Firmware Summit that took place at the recent Linaro Connect event.

There’s a discussion on the state of ACPI on ARMv8, and Linux support. “So, please tell Linaro if there is something needed from the ACPI spec.  Call, write or send carrier pigeons, just let us know.

There is a discussion on ACPI’s _DSD and Device Properties. A new dsd@acpica.org mailing list has been setup to help. A new repo of information —  on how to submit, approve, and use device properties in a community approved manner:

https://github.com/ahs3/dsd/tree/v-next/documentation

https://lists.acpica.org/mailman/listinfo/dsd

Matthew Garret wrote a document on Secure Boot:
https://lists.linaro.org/pipermail/fw-summit/2015-September/000170.html

I omitted a few items from the workshop’s notes. Read the full status here:
https://lists.linaro.org/pipermail/fw-summit/2015-October/000173.html

coreboot changes

The coreboot blog has a long post, which covers the last five weeks of changes, and there were a lot: 314 commits. Some highlights:

Over one third of the commits covers Intel Skylake development, where boards and chipset code saw misc improvements and tons of clean ups.

There also was a notable effort of unifying common code across the more recent Intel SoCs, removing lots of duplicated code all over the place.

On x86, the romstage is now relocated for its final location in CBFS by cbfstool, obsoleting the old approach that had us link it twice, once to determine its final size and then to the actual location it’s supposed to run from. In the future this same approach may be extended to other files that need to be executed in place such as the FSP binary.

The romstage change eliminated the need for cbfstool’s “locate” command, and so it was removed. cbfstool also saw other extensions, the biggest one a compatible change to the format to allow for per-file attributes in CBFS. These attributes can contain additional information about a file, currently the compression method and uncompressed size of a file. cbfstool and the build system were extended to allow compressing files, libpayload is able to uncompress these files.

On the AMD side, there were various bugfixes both for new (merlin falcon) and old (Fam10) chipsets.

ARM64 and Tegra210 saw various bugfixes and improvements to power use. For the latter, coreboot also learned how to reserve memory for other functions than the main processor.
Rockchip’s RK3288 ARMv7 SoC also saw a number of bug fixes and the code was restructured to use a single mainboard directory for a large number of very similar Google Veyron mainboards based on that SoC.

Our RISCV support now boots on the Spike simulator which (besides supporting a wider variety of emulators) is notable because unlike the QEmu RISCV support, Spike supports RISCV’s revised ABI.
Speaking of emulators, recent versions of qemu-x86 expect the firmware to initialize the LAPIC, which we now do.

The ongoing effort to move CPU microcode into CBFS (and to store these as binaries in 3rdparty/blobs instead of header files in the main sources) saw some progress.

Lots of interesting things were omitted above. Full post:

coreboot changelog, most-of-september edition

LITE, Linaro IoT group

At Linaro Connect, ARM’s CEO announced a new Linaro IoT group, LITE. More details here, including the video of the announcement:

https://www.linaro.org/blog/linaro-connect-2015-kicks-off-in-san-francisco/

In Youtube video of announcement, it ironic to see ARM exec keynote interrupted by an attendee’s smartphone, which was likely ARM-based.

Many other things are in keynote video, not just LITE, since this week’s Linaro Connect is “security-themed”.

“Security is starting to become important for everything we do.” –ARM CEO

http://connect.linaro.org/program/

Mentor improves Sourcery toolchain

Mentor Graphics is adding support for AArch64 and AMD x86 in their freeware eLinux toolchains:

Mentor Embedded Linux for AMD x86 G-Series and R-Series Processors and Sourcery CodeBench Tools for AMD x86 and ARM
Linux Development for Next-Generation Embedded Systems

Mentor Embedded and AMD have joined forces to announce several software enablement products for the AMD Embedded G-Series and R-Series families of processors: Mentor Embedded Linux and Sourcery CodeBench IDE tools. To complement the offer, free versions of the Mentor Embedded Linux-Lite and Sourcery CodeBench Lite are available for customers to download. The combination of AMD’s breadth of embedded processors and Mentor Embedded’s software solutions will enable developers to build robust and powerful applications in industries such as digital gaming, industrial control & automation, retail Point-of-Sale (POS), networking equipment and storage.
http://www.mentor.com/company/news/mentor-amd-armv8-a-linux

Mentor tools up 64-bit ARM processors at AMD

Linaro’s 96Boards initiative

Earlier this year, ARM’s Linaro created 96Boards.org.

The 96Boards initiative is designed to offer a single software and hardware community across multiple vendor boards supporting a range of different features. A fixed set of minimum functions including USB, SD, HDMI and standardized low speed and high speed peripheral connectors are provided. Vendors may add customized hardware and feature sets provided the minimum functions are available. We expect this to extend the platform life, increase the market for add-on hardware, and accelerate open source upstreaming of support for new SoC features. The 96Boards standard specification and this website are maintained by the Linaro Community Board Group (LCG). Linaro is a collaborative software engineering organization focused on the ARM architecture. Corporate members of Linaro provide funding and engineers plus direction through various steering committees and resources are split into semi-autonomous groups with their own members.

There are currently two 96Boards specifications for low-cost ARMv7-A and ARMv8-A development boards:
* The Consumer Edition (CE) targets the mobile, embedded and digital home segments.
* The Enterprise Edition (EE) targets the networking and server segments.

They have 3 boards listed currently:
* DragonBoard 410c: Board based on Qualcomm Snapdragon™ 410 processor
* The HiKey Board: Board based on HiSilicon Kirin 6220 processor
* 96Boards UART Serial Adapter: a USB to UART interface to be used with any 96Boards Consumer or Enterprise Edition board.

https://www.96boards.org/ce-specification
https://www.96boards.org/ee-specification
https://www.96boards.org/products/

Marcin Juszkiewicz has a good blog post on 96boards as well:
http://marcin.juszkiewicz.com.pl/2015/06/26/96boards-goes-enterprise/

ARM Devices has a video discussing adding 96boards hardware targets to LAVA, the CI server by Linaro for embedded device testing.

LAVA Lab to integrate HiKey from 96Boards.org

Security focus of next Linaro Connect

Linaro Connect is happening in 4 days in San Francisco.

“The theme for the week is security.”

The security track:
* Security requirements on ARMv8-A boot architecture
* Linux kernel generic TEE driver
* OP-TEE Content Decryption with Microsoft PlayReady on ARM
* Expanding security choices: DRM & CA interoperability
* Expanding security choices panel
* Secure storage in OP-TEE
* Lessons learned on migrating open source Chromium-OPTEE to 96Boards
* TBD
* TBD

More Information:
https://www.linaro.org/news/keynote-speakers-lined-up-for-linaro-connect-sfo15/
http://connect.linaro.org/sfo15/

Qualcomm Snapdragon updates

Qualcomm announces ARM-based Snapdragon 430 and 617, and Snapdragon 820 with X12 LTE modem:

Over the past several weeks, we have been revealing details about the incredible features of the Qualcomm Snapdragon 820 processor. And today we are revealing the final piece of the puzzle. The Snapdragon 820 is the most powerful mobile processor we’ve ever made. […]

Qualcomm Technologies is building up the Snapdragon line-up with two new products and several firsts. The Qualcomm Snapdragon 617 and 430 processors are designed to deliver high-end performance and experiences in affordable, high- and mid-tier devices. […]

https://www.qualcomm.com/news/snapdragon/2015/09/14/snapdragon-617-and-430-build-mid-tier-high-end-features
https://www.qualcomm.com/news/snapdragon/2015/09/14/snapdragon-820-countdown-breakthrough-lte-and-wi-fi-x12-lte-modem

Secure Boot for USBArmory

[[  UPDATE: Earlier I called this “UEFI Secure Boot”. Vincent Zimmer of Intel read their blog article more closely than I did, read the comment he just made:  click on the “Comment” link on the left side of the blog, At the moment, I am not sure what flavor(s) of “Secure Boot” InversePath is using for the USB Armory. ]]

InversePath has updated the USB Armory to support Secure Boot (unclear what kind of  “Secure Boot” this is..

Interesting read to see what is involved in getting Secure Boot to work, even if you don’t have one of these devices. I like the disclaimer:

IMPORTANT: enabling Secure Boot functionality on the USB armory SoC, unlike similar features on modern PCs, is an irreversible action that permanenty fuses verification keys hashes on the device. This means that any errors in the process or loss of the signing PKI will result in a bricked device uncapable of executing unsigned code. This is a security feature, not a bug. The activation and use of the Secure Boot functionality is therefore at your own risk and must be approached with care.

https://github.com/inversepath/usbarmory/wiki/Secure-boot

ARM article on U-Boot

A few weeks ago Linus Walleij of Linaro wrote an article talking about boot loader technology options for AArch32 and AArch64. Besides going into detail on U-Boot,  the blog mentions some boot loaders from Qualcomm and elsewhere:

https://www.linaro.org/blog/core-dump/u-boot-on-arm32-aarch64-and-beyond/

Microsoft and ARM collaborate on DRM/secure media solutions

ARM and Microsoft have announced support of integration of technologies that enable DERM on ARM systems, using Microsoft PlayReady and W3C Encrypted Media Extensions (EME):

Press release excerpt:

The major development in this solution is the integration of Microsoft’s PlayReady DRM with W3C EME, OpenCDM, Chromium and Linaro’s Open Portable Trusted Execution Environment (OP-TEE) on ARM TrustZone® technology. The secure media solution has been implemented on an STMicroelectronics STiH410 SoC with an ARM Cortex®-A9 processor at its core. The new solution integrates the following key components: W3C EME, Microsoft PlayReady DRM Porting Kit v3.0, OP-TEE, OpenCDM, and Chromium v43.

“The Linaro Digital Home Group is extremely pleased to deliver this open source secure media solution to the embedded developer community” said Mark Gregotski, Director of the Linaro Digital Home Group. “This collaboration demonstrates how a commercial DRM, such as Microsoft’s PlayReady, can be integrated into a security framework comprised of open-source components, including the Linaro Open Portable TEE running on ARM TrustZone. We hope this will be the catalyst to accelerate the deployment of secure DRM solutions employing open source software.”

“This is a key milestone that showcases how Microsoft PlayReady DRM works cross-platform in a standard way. We are excited about the collaboration with Linaro, ARM, OP-TEE and OpenCDM. This reference implementation simplifies and accelerates the ability of partners to build rich experiences to deliver secure media solutions, while providing market leading content protection using Microsoft PlayReady” said Dave Bossio, Group Program Manager, Windows Devices Group, Security at Microsoft Corporation.

“Trust is key to future media business models, as valuable content must be protected from server to screen,” said Shiv Ramamurthi, Director, Home Segment Marketing, ARM. “The pay TV ecosystem will see immediate content security benefits from the integration of ARM TrustZone and Microsoft PlayReady DRM technology. This latest open source initiative led by the Linaro Home Group is a milestone in the enablement of next-generation secure content and media experiences for consumers.”

“ST has been a strong contributor to the Open Portable Trusted Execution Environment (OP-TEE) in open source, a key enabler for this integration. As a natural step forward, ST is pleased its STiH410 platform is being used as a vehicle for this effort and for an exciting demo at IBC 2015,” said Yingchih Yang, Advanced System and Security Officer of the Consumer Product Division in STMicroelectronics. “Such Linaro contributions will facilitate premium content consumption across various devices including smartphones, tablets, and set-top-boxes, meeting strong market expectations.”

http://www.linaro.org/news/linaro-and-microsoft-collaborate-on-secure-media-solutions-for-arm-based-socs/?sf40842573=1
http://www.microsoft.com/playready/
https://github.com/fraunhoferfokus/open-content-decryption-module
https://github.com/w3c/encrypted-media/
http://www.w3.org/TR/encrypted-media/
https://github.com/OP-TEE

mbed

ARM has a new embedded OS called mbed, for use with the IoT. Beta was announced today:

IBM is partnering with ARM on mbed:
https://www-03.ibm.com/press/us/en/pressrelease/47579.wss
http://www.ibm.com/IoT

See this link for the various Github URLs to the source:
http://www.mbed.com/en/development/getting-started/get-code/
https://github.com/ARMmbed

More Info:
http://www.mbed.com/
http://community.arm.com/groups/internet-of-things/blog/2015/09/08/mbed-os-beta-is-here
http://community.arm.com/groups/internet-of-things/blog/tags#/?tags=mbed

(FYI, mbed.org, which is often used in the press release URLs, merely redirects to mbed.com.)

I haven’t looked at the code or the license yet. I have no idea about what firmware and boot technologies it uses… 😦

Linaro Firmware mini-Summit next month

Today on the Linaro Firmware Summit mailing list, Al Stone of Red Hat just announced the next Firmware Summit

What: Linaro Firmware mini-Sumit (at Linaro Connect)
When: Tuesday, September 22th, 2015, 2-6pm
Where: Hyatt Regency San Francisco Airport Hotel, Burlingame, CA

Initial agenda topics include:

1) Current state of ACPI on ARM
2) Support/backing for a longer term organization (i.e., mailing lists, web sites, further meetings…)
3) Use of _DSD device properties
4) Follow-up on others items from the last meeting (mostly promised documents)

Other topics are being solicited. See the full posting on the fw-summit list archives.

https://lists.linaro.org/mailman/listinfo/fw-summit
http://sanfranciscoairport.hyatt.com/en/hotel/home.html
http://connect.linaro.org

U-Boot AArch64 and ARM Trusted Boot support

This week Linus Walleij of Linaro posted a long blog article on U-Boot this week, with good background on U-Boot on ARM, as well as current AArch64 support, including integration with ARM Trusted Firmware (ARM TF). Excerpting the concluding paragraphs of the blog:

We now have pieced together a system that will start U-Boot from ARM Trusted Firmware and then have U-Boot load the Linux kernel and a device tree and start it. Are there problems remaining?
* One of the big outstanding issues are those where things are fragile because memory references need be hard-coded in U-Boot or ARM Trusted Firmware. For example U-Boot currently assumes that ARM TF will use 16MB of the DRAM memory. If the ARM TF change things around and use more or less memory, U-Boot needs to be reconfigured and recompiled. U-Boot on the other hand, will then pass whatever knowledge it has about the memory to the Linux kernel by augmenting the device tree. So if ARM TF could communicate the memory available to U-Boot and the OS this would be great.
* U-Boot relies on prior boot stages such as ARM Trusted Firmware to install PSCI handlers, while on ARMv7 this was usually done by augmenting U-Boot to do the same. Letting U-Boot install PSCI handlers is a bit bogus, since it is a piece of resident code left in memory after U-Boot has executed and not really “boot loader” code. U-Boot was augmented to compile these into a special memory area, copy them there and leave them around for the operating system to use later. Still there are people who might like to do this on ARMv8 U-Boot, especially those not using ARM Trusted Firmware.
* People apparently toy with the idea of booting U-Boot on bare metal, using a very small or no ROM nor ARM Trusted Firmware, letting U-Boot just execute immediately on the system. As U-Boot relies on something else to set up main memory and providing PSCI, this currently does not work. Doing this would require U-Boot to initialize memory and install PSCI handlers. It would also need to be small enough to execute from on-chip RAM.
* Chain of trust booting with signed boot levels, signed U-Boot and a signed kernel image and a signed device tree, making an example of a totally locked-down system. The Flattened Image Tree (FIT) supported by U-Boot is likely the best way forward here, but requires U-Boot to access public key infrastructure to verify images unless you want to compile the public key directly into U-Boot, which is often not a good idea.
* Fastboot – the Android boot protocol used by the Little Kernel, exists in U-Boot but has not been tested or verified. It can use USB or Ethernet alike.
* More hardware support – such as booting from the USB stick or MMC/SD card found in the Juno board. This was not covered by the experimental port.

Read the full article here:

https://www.linaro.org/blog/core-dump/u-boot-on-arm32-aarch64-and-beyond/

ARM Tech Conference in November

(This week is Intel’s Developer Conference….) ARM has a Developer Conference in November in California. Like the Intel devcon, many of the presentations at the ARM event look very interesting, here’s a sampling:

* Building an ARM Cortex M4 Automated Firmware Update System
* The Future of Security for the Connected Car
* Use cases for ARM TrustZone dealing with mixed criticality applications
* Deploying Trusted Code to TrustZone: Easy as 1,2,3!
* IoT protocols for constrained devices
* Designing Security and Trust into Connected Devices
* Protection for Premium Content for Mobile, Smart TV, STB’s
* Resilient Internet of Things Security The End of Flat Security Models
* Bringing Mali, the Android GPU of Choice, to Wearables
* C++ Exception Handling on the ARMv7 Architecture
* De-Mystifying Automotive ADAS Collision Avoidance systems with Programmable SoCs
* Efficient Interrupts on ARM Cortex-M Microcontrollers
* Addressing Debug Challenges for ARM based Heterogeneous Multicore SoCs
* ARM-based Secure IoT with Secure Boot and Secure software platform that delivers Data integrity, confidentiality, Anonymity and Non-Repudiation
* ARM mbed powering the Internet of Things that really matter
* Multi-Abstraction Hardware/Software Debug for ARM(R)v7/v8 Based SoCs
* New Intrusion Detection Methodology for IoT Cybersecurity using Programmable SoCs
* Development Tools for Writing Secure Software Targeting Cortex-M Processors
* IoT Security Therapy Panel: Becoming Less Insecure
* Windows 10 IoT for Embedded ARM Devices
* Building Confidence for the Internet of Tomorrow: How ARM-Powered Solutions Will Secure the IoT
* Code Verification Explained: Code Coverage and Unit Testing
* Improving Software Security through Standards Compliance and Structural Coverage Analysis
* New Approaches for Securing Mobile and Iot Devices Through Cognitive Technologies
* The Benefits and Ease of Establishing a PUF-Based Root of Trust on ARM Trustzone
* Resolving Security and Power Conflicts in ARM Cortex-M7 IoT SoCs
* Simplifying Software Development for Socs Containing Multiple Cortex-M Based Processors

September 4th is the Early Bird discount rate change. Expo passes are free.

http://schedule.armtechcon.com/list

http://www.armtechcon.com/passes-pricing/

AArch64 support for ACPI BERT in Linux

ACPI is not only in the firmware of Intel-based systems, but it’s also now inside ARM-based systems. Today on the Linaro-ACPI mailing list, there was a patch for ACPI BERT support for AArch64. I think support had already been in for Intel already, unclear how long.

APEI Boot Error Record Table (BERT) support

Under normal circumstances, when a hardware error occurs, kernel will be notified via NMI, MCE or some other method, then kernel will process the error condition, report it, and recover it if possible. But sometime, the situation is so bad, so that firmware may choose to reset directly without notifying Linux kernel. Linux kernel can use the Boot Error Record Table (BERT) to get the un-notified hardware errors that occurred in a previous boot. In this patch, the error information is reported via printk. Once error log is printed out clear error status so it would not be print during next boot again.

ACPI/APEI is designed to verifiy/report H/W errors, like Corrected Error(CE) and Uncorrected Error(UC). It contains four tables: HEST, ERST, EINJ and BERT. The first three tables have been merged for a long time, but because of lacking BIOS support for BERT, the support for BERT is pending until now. Recently on ARM 64 platform it is has been supported. So here we come. The following log is a BERT record after system reboot because of hitting a fatal error.

BERT: Obtained BERT iomem region <00000000fe801000-00000000fe802000> for BERT.
[Hardware Error]: Error record from previous boot:
[Hardware Error]: event severity: fatal
[Hardware Error]:  Error 0, type: fatal
[Hardware Error]:   section_type: memory error
[Hardware Error]:   physical_address: 0x00000000fe800000
[Hardware Error]:   physical_address_mask: 0x0000000000000fff
[Hardware Error]:   card: 0 module: 1 bank: 0 device: 1 row: 1 column: 1 bit_pos

For more information about BERT, please refer to ACPI Specification version 6.0, section 18.3.1.

For more information about this patch, see this thread:
https://lists.linaro.org/pipermail/linaro-acpi/2015-August/005611.html

For more on BERT, also see /src/acpi/bert/bert.c in the FirmWareTestSuite (FWTS).

Click to access ACPI_6.0.pdf

http://www.spinics.net/lists/linux-acpi/msg57384.html
https://lists.linaro.org/mailman/listinfo/linaro-acpi

WPBT attacks from the past: Alex at SyScan12

The recent Lenovo LSE blunder made most of the world aware of Windows WBPT ACPI table and how the firmware injects an executable into the OS, a feature of Windows that all OEMs are likely using. While the media is wondering about WBPT and why it’s not prominently displayed on many web sites, Xeno of LegbaCore pointed out that Alex Ionescu gave a talk at SyScan 2012 on this specific topic:

ACPI 5.0 Rootkit Attacks Againts Windows 8
Alex Ionescu
This talk will disclose certain new features of the ACPI 5.0 Specification which is now public and was primarily designed to support ACPI on ARM Embedded SoCs for the upcoming release of Windows 8. Some of these new features have important security considerations which have not been traditionally monitored by security products and/or users, specifically in the areas of covert code execution at Ring 0 privileges.

https://www.syscan.org/index.php/download/get/a722b1acb9396d82323da3a78235fdc0/SyScan12Slides.zip
https://www.syscan.org/index.php/archive/view/year/2012/city/sg/pg/program
https://www.syscan.org/index.php/archive/view/year/2012/city/sg/pg/speakers#004
https://www.syscan.org/index.php/download/previous
http://www.alex-ionescu.com/

Thanks for reminding us, Xeno!

RISC-V Raven processor talk at HotChips

HotChips 2015 is happening in Cupertino, California later this month, 23-25th. Today Krste Asanovic posted a message on the RISC-V blog:

RISC-V at HotChips: Analyst Kevin Krewell has posted a HotChips preview at EE Times, which mentions the RISC-V Raven-3 presentation to be made in the last session at HotChips by Yunsup Lee.  UC Berkeley will again be sponsoring a table at HotChips to promote RISC-V, so please drop by if you’ll be there and want to chat about RISC-V uptake.

Hot Chips is a symposium on High Performance Chips, sponsored by the IEEE Technical Committee on Microprocessors and Microcomputers, in cooperation with ACM SIGARCH. The RISC-V presentation is on the “Raven” processor:

Raven: A 28nm RISC-V Vector Processor with Integrated Switched-Capacitor DC-DC Converters and Adaptive Clocking
by: Yunsup Lee, Brian Zimmer, Andrew Waterman, Alberto Puggelli, Jaehwa Kwak, Ruzica Jevtic, Ben Keller, Stevo Bailey, Milovan Blagojevic, Pi-Feng Chiu, Henry Cook, Rimas Avizienis, Brian Richards, Elad Alon, Borivoje Nikolic and Krste Asanovic, University of Berkeley

The EE Times blog article, by Kevin Krewell of Tirias Research, gives a good overview of all the vendors presenting at HotChips, focusing on the traditional ones (Intel, ARM, AMD, etc.), and calls RISC-V an “odd duck”. 🙂

The last session on Tuesday is traditionally the main “big” processor session. […] The odd duck in the session is an implementation of UC Berkeley RISC-V Vector Processor. Last year the Berkeley contingent showed off RISC-V instruction set in the break area, but now with a real chip, they made it to inside the auditorium. It’s not too often you see a chip design of this integration and complexity coming from academia. What started as a project to give universities a royalty-free and extendable CPU architecture to build on, has gained traction, especially in India and Asia for development purposes.”

RISC-V and Open Hardware aside, there are many other interesting presentations at Hot Chips 2015, including talks from Intel, ARM, AMD, and others. There are a handful of other Open Hardware/Maker-related talks, eg: Adapteva is talking about their Kickstarted chip, and Univerisity of Wisconson’s MIAOW project, an OpenGL API-compatible GPGPU.

http://www.hotchips.org/
https://blog.riscv.org/
http://www.eetimes.com/author.asp?section_id=36&doc_id=1327424

DHS announces firmware security grant to Intelligent Automation

Yesterday the DHS announced a contract with Intelligent Automation (i-a-i.com) to work on methods to safeguard firmware, and other code in mobile devices. DHS press release excerpt:

The Department of Homeland Security (DHS) Science and Technology Directorate (S&T) today announced a $1.2 million cybersecurity Mobile Technology Security (MTS) research and development (R&D) award that will help secure mobile devices for the federal government. The Broad Agency Announcement HSHQDC-14-R-B0015, issued by the S&T Cyber Security Division, awarded the contract to Intelligent Automation, Inc. (IAI) of Rockville, Md. to work on mobile security research in device layer protection. “Ensuring that mobile devices used across the public and private sector are secure is a priority for S&T,” said DHS Under Secretary for Science and Technology Dr. Reginald Brothers. “This project will provide an innovative solution for protecting mobile devices from malicious activity.” The MTS award is a part of the Mobile Device Security (MDS) R&D project which aims to accelerate the adoption of secure mobility by government and private sector organizations. The MDS project is developing R&D technologies in mobile device instrumentation, transactional security methods, mobile security management tools and mobile device layer protection.   The mobile device layer protection project will evaluate innovative approaches to protect mobile-device layers – such as firmware, operating system, applications and identity – against infections by malicious applications. IAI will implement a software security solution called TRUsted Monitor and Protection for the multicore Advanced RISC Machines (ARM) platform in an effort to severely impact an attacker’s ability to operate in existing and future mobile devices.

http://www.dhs.gov/science-and-technology/news/2015/08/06/dhs-st-awards-12m-rockville-company
http://i-a-i.com/
http://scitech.dhs.gov/cyber-research