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).

 

CLKSCREW: breaking TEEs with energy mgmt

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

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

http://radare.org/get/r2snow.pdf

http://radare.org/

 

 

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)

http://www.uefi.org/learning_center/presentationsandvideos

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

https://www.community.arm.com/iot/embedded/b/blog/posts/a-few-intricacies-of-writing-armv8-m-secure-code

https://www.community.arm.com/processors/b/blog/posts/useful-tips-for-developing-secure-software-on-armv8-m

https://www.community.arm.com/processors/b/documents/posts/whitepaper—armv8-m-architecture-technical-overview

https://developer.arm.com/products/architecture/m-profile/docs/100720/latest/secure-software-guidelines

https://developer.arm.com/docs/100739_0100/latest/the-arm-c-language-extensions-acle-for-armv8m

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:

 

https://www.kickstarter.com/projects/esden/1bitsy-and-black-magic-probe-demystifying-arm-prog

 

MapleSyrup: ARM security tool

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 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

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!

http://wccftech.com/intel-manufacture-arm-chips/

Position Independent Executables for ARM

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

 

https://lkml.org/lkml/2016/6/28/989