Slides from my ARM IoT Firmware Emulation workshop this morning at @hack_lu:
https://t.co/dupGiEuWmkand also the code to intercept nvram calls while emulating firmware:https://t.co/21vVe4fqzt#hackLU
— 🐘 @therealsaumil@infosec.exchange (@therealsaumil) October 16, 2018
Tag: ARM
Alex Matrosov joins NVIDIA!!
This is great news for NVIDIA security!!
Also anyone from ARM Ltd must be quite excited to see recent career paths of ex-CHIPSEC Project members. Alex and Yuriy of Eclypsium has an ARM port of CHIPSEC, which they says they they’re going to release (when!?!). Now Alex is joining Nvidia and will also be focusing on ARM. Note to the Linaro team working on the AArch64 port of LUV-live, once CHIPSEC works on ARM, you really need to get this project active again.
I hope the CHIPSEC team, and or (ARM Ltd, Linaro, Eclypsium, or now NVIDIA) helps update the CHIPSEC Project’s release of CPython. Today it is a binary-only release for x86 and x64, in the Github source tree. It’ll need ARM versions of CPython, and hopefully make CPython build for CHIPSEC transparent, or at least sign the blobs. Actually, this points out an upstream problem to Tianocore: CHIPSEC is an example of an ISV with a UEFI app that needs CPython, and has to ship it themselves. Tianocore should consider shipping CPython binaries along with ShellPkgBin binaries.
PS: I also just noticed that their book has a nice (new?) domain name: http://bootkits.io/ (no HTTPS).
Beginner’s Guide to Exploitation of ARM, by Billy Ellis
CLKSCREW: breaking TEEs with energy mgmt
https://twitter.com/daniel_bilar/status/912003921295618049
CLKSCREW: Exposing the perils of security-oblivious energy management
https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang
0x0atang.github.io/files/usenix17_clkscrew_preprint.pdf
https://hacks.hyperspacer.com/app/items/15303894
VisUAL: ARM emulator
Created by Salman Arif, 2015, Imperial College London. Last release 2015.
Reversing ARM firmware using Radare: scripts/bins available
Re: https://firmwaresecurity.com/2017/03/31/reversing-arm-firmware-using-radare-presentation-available/
The samples for this presentation are also available. Previously, it was just the presentation PDF.
http://radare.org/get/r2snow.zip
UEFI Plugfest slides uploaded
https://uefi.blogspot.com/2017/03/uefi-plugfest-2017-in-nanjing.html
Tim Lewis of Insyde has a blog post with an update for the UEFI plugfest. *Multiple* presentations on security!!
State of UEFI – Mark Doran (Intel)
Keynote: China Information Technology Ecosystem – Guangnan Ni (Chinese Academy of Engineering).
The Role of UEFI Technologies Play in ARM Platform Architecture – Dong Wei (ARM)
ARM Server’s Firmware Security – Zhixiong (Jonathan) Zhang, Cavium
SMM Protection in EDK II – Jiewen Yao (Intel)
Server RAS and UEFI CPER – Mao Lucia and Spike Yuan (Intel)
A More Secure and Better User Experience for OS-based Firmware Update – David Liu (Phoenix)
UEFI and IoT: Best Practices in Developing IoT Firmware Solutions – Hawk Chen (Byosoft)
Establishing and Protecting a Chain of Trust with UEFI – David Chen (Insyde)
Implementation of Hypervisor in UEFI Firmware – Kangkang Shen (Huawei)
Lessons Learned from Implementing a Wi-Fi and BT Stack – Tony Lo (AMI)
UEFI Development Anti-Patterns – Chris Stewart (HP)
Alexander on U-Boot+UEFI+GRUB on ARM
Here’s one interesting presentation for the upcoming OpenIoT and Embedded Linux Conference:
Marrying U-Boot, uEFI and grub2 – Alexander Graf, SUSE
Booting is hard. Booting in the ARM world is even harder. State of the art are a dozen different boot loaders that may or may not deserve that name. Each gets configured differently and each has its own pros and cons. As a distribution this is a nightmare. Configuring each and every one of them complicates code that really should be very simple. To solve the problem, we can just add another layer of abstraction (grub2) on top of another layer of abstraction (uEFI) on top of another layer of abstraction (u-boot). Follow me on a journey on how all those layers can make life easier for the distribution and how much fun uEFI really is. After this talk, you will know how ARM systems boot, what uEFI really means, how uEFI binaries interact with firmware and how this enables convergence of the Enterprise and Embedded markets.
Alexander Graf, KVM Wizard, SUSE
Alexander started working for SUSE about 8 years ago. Since then he worked on fancy things like SUSE Studio, QEMU, KVM and openSUSE on ARM. Whenever something really useful comes to his mind, he tends to implement it. Among others he did Mac OS X virtualization using KVM, nested SVM, KVM on PowerPC and a lot of work in QEMU for openSUSE on ARM. He is the upstream maintainer of KVM for PowerPC, QEMU for PowerPC and QEMU for S390x.
https://openiotelcna2017.sched.com/event/9IuS
https://openiotelcna2017.sched.com/?s=firmware
https://openiotelcna2017.sched.com/?s=u-boot
http://events.linuxfoundation.org/events/openiot-summit
http://events.linuxfoundation.org/events/embedded-linux-conference
Writing secure C code for ARM
new AArch64 vm-spec validation tools
Riku Voipio of Linaro has announced the release of some new tools that validate the VM to the Linux cross-distro list.
Some time ago we drafted a specification[1] for AArch64 virtual machines. Now we are launching verification tools that let everyone verify that the whole stack (host hypervisor, guest firmware and guest OS image) implements the spec 2[]. For some extra background see the blog post on vmspec [3]. From the cross-distro point of view, we are interested in finding out if
– QEMU shipped is new enough (2.6+)
– a compatible EFI for arm64 guests is available
– a vmspec compatible cloud guest image is available
If the image comes with cloud-init, vmspec-boot can be used directly to verify compliance. Without cloud-init, one can run vmspec-verify inside the guest to verify manually. The tools are still under development, for example the ACPI test returns a failure even if the guest would support ACPI if forced. Feedback and patches are always welcome. The README.md lists a handful of guest images that have been used in testing. I’d be most happy to add more links to the list!
[1] http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v2.0.pdf
[2] https://github.com/linaro/vmspec-tools
[3] http://www.linaro.org/blog/core-dump/ensuring-bootable-arm-vm-images/
Full message:
https://lists.linaro.org/mailman/listinfo/cross-distro
ACPIview
Evan Lloyd and Sami Mujawar of ARM have submitted a new ACPI UEFI Shell tool for Tianocore.
[edk2] [PATCH] 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, and the command is also intended for Debug1. 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.
The code is available for examination at:
https://github.com/EvanLloyd/tianocore/tree/651_acpiview_v1
1Bitsy and Black Magic Probe
1Bitsy and Black Magic Probe has a Kickstarter campaign worth checking out:
AMI adds Redfish support for AArch64 systems
AMI has announced support of Redfish for AArch64:
MapleSyrup: ARM security tool
https://twitter.com/suqdiq/status/805453613699043328
Maplesyrup Register Display Tool:
Maplesyrup is a tool that can be used to help determine the security state of an ARM-based device by examining the system register interface of the CPU. Maplesyrup is for anyone who has low level access to a handset or single-board PC running an ARMv7A/v8A based processor and is interested in knowing the register level configuration of their CPU at OS runtime. These registers contain featureset and security information that may influence operation of the system kernel and running applications. Linux provides featureset and platform information to the user in the /proc and /sys filesystems, but the configurations governing how these features operate is sometimes hidden to the user. In some cases, the OS will make use of the information to conform to implementation specific features and not indicate this to the user. In other cases, these features may not be managed by the operating system at all, but nevertheless could potentially affect the operation of the system by configuring how a CPU controls access to security domains, executes specific instructions, and handles CPU exceptions.[…]
https://github.com/iadgov/Maplesyrup
ARM assembly language tips from ARM
If you write (or read ARM Cortex-M0 assembly, you might want to read this article:
ARM big.LITTLE and cache flushing
[[
UPDATE: Here’s a message from Mark Rutland of ARM that clarifies some issues in Mono blog post:
https://lists.linaro.org/pipermail/linaro-toolchain/2016-September/005900.html
]]
Below is an excerpt of an email from Riku Voipio to the Linaro cross-distro and toolchain lists, about the recent ARM big.LITTLE issue discovered by the Mono project:
As painfully found out by mono team, if big/little cores have different cache line sizes, __clear_cache doesn’t work as expected. This affects any home-grown cache flushing mechanism as well.
Protip, if you suspect your application issues might related to big.LITTLE, use taskset(1) or hwloc-bind(1) to tie the process to either big or little cluster (or just a single core).
Here’s an excerpt from the Mono blog post (spoiler alert: it’s the final paragraph):
[…] Summary: Some ARM big.LITTLE CPUs can have cores with different cache line sizes, and pretty much no code out there is ready to deal with it as they assume all cores to be symmetrical. Worse, not even the ARM ISA is ready for this. An astute reader might realize that computing the cache line on every invocation is not enough for user space code: It can happen that a process gets scheduled on a different CPU while executing the __clear_cache function with a certain cache line size, where it might not be valid anymore. Therefore, we have to try to figure out a global minimum of the cache line sizes across all CPUs. Here is our fix for Mono: Pull Request. Other projects adopted our fix as well already: Dolphin and PPSSPP.
More info:
http://www.mono-project.com/news/2016/09/12/arm64-icache/
https://lists.linaro.org/pipermail/linaro-toolchain/2016-September/005899.html
ARM reading list
ARM has created a list of books on ARM, rated by experience level:
Intel to license ARM tech
[…] Intel, will now manufacture chips for other companies such as ARM. To be more precise, it will be licensing technology from Britain’s ARM holdings. […]
I wonder what this means for Intel and ARM?? I’ve deleted a few paragraphs of speculation, to save you time, as I have no clue. 🙂
I hope that Intel also releases a version of a RISC-V chip!
OpenBSD adds W^X support for ARM
“Start using to XN flag to enforce that mappings without PROT_EXEC are non-executable.”
Firmware Security 
You must be logged in to post a comment.