Intel releases firmware source code to Arduino 101

Zoe Romano posted a new blog entry on Arduino.cc site, about Intel releasing the source code to the Arduino 101 firmware.

[…] Weโ€™re very happy to announce that the source code of the real-time operating system (RTOS) powering the Arduino 101 and Genuino 101 is now available for hacking and study purposes. The package contains the complete BSP (Board Support Package) for the Curie processor on the 101. It allows you to compile and modify the core OS and the firmware to manage updates and the bootloader. (Be careful with this one since flashing the wrong bootloader could brick your board and require a JTAG programmer to unbrick it). The firmware runs on the x86 chip inside the Curie module and communicates with the ARC core (which runs your Arduino sketches) using these callbacks. Right now, the x86 core takes care of handling Bluetooth Low Energy (BLE) and USB communication, offloading the ARC core. You can use the code which implements these functionalities as a starting point for your custom extra features. […]

Intel releases the Arduino 101 firmware source code


https://downloadcenter.intel.com/download/25832
https://github.com/01org/corelibs-arduino101
http://forum.arduino.cc/index.php?board=103.0

Hardening Linux containers

https://twitter.com/alexstamos/status/722893515382915072

Aaron Grattafiori of NCC Group has just published research on Linux containers and security hardening.

[…] Our recently-posted whitepaper starts off exploring the various motivations behind Linux containers and how they contrast with more traditional hardware virtualization on modern general purpose CPUs. The whitepaper then explores Linux namespaces, cgroups, and capabilities in depth, listing example use and illustrating potential risks. Next is an in-depth discussion of the various threats to any container deployment, either container to host attacks, cross-container attacks,and other potential threats to any container deployment, regardless of size. To counter these threats and add future defense in depth, this whitepaper also includes an exploration of key security features such as user namespaces, seccomp-bpf and Mandatory Access Control. While these features are often discussed as they relate to containers, the protections can be applied to any Linux application, regardless of container deployment. After exploring container basics, threats, and security features, an overview of Docker, LXC and CoreOS Rkt is included. This overview covers the container solution background, key components and includes a brief security analysis of each platform. This section ends by contrasting different container defaults, before enumerating various security recommendations to counter weaknesses (both in general for any container platform, and specifically for LXC, Docker and CoreOS Rkt). These configuration tweaks, security actions, strategies and recommendations help establish hardened Linux containers and adding defense in depth to any application deployment. To conclude, a number of future related technologies are briefly explored such as unikernels, microservices and other container platforms, this also includes a discussion of hybrid container/hardware virtualization using minimal hypervisors. […]

Full paper:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/april/understanding-and-hardening-linux-containers/
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-10pdf

LibEnclave: create Intel SGX secure enclaves in Rust

Jethro Beekman has released libenclave, a Rust-based tool for Intel SGX’s SDK for Windows:

This guide will get you started building SGX secure enclaves in Rust using libenclave and sgxs-tools. […]

https://github.com/jethrogb/sgx-utils
https://github.com/jethrogb/sgx-utils/blob/master/doc/GUIDE.md

Intel to release SGX for Linux

Dan Zimmerman of Intel posted a status update regarding Linux availability of an SDK for Intel SGX:

Excerpting the blog:

The Intel intends to:
* Open-Source the Intelยฎ SGX SDK for Linux* and associated Platform Software in June 2016.
* There will be a few user-space components where binaries will be provided instead of source

It sounds like this will be a freeware release that includes partial source, not a proper open source project. At least, I am not sure how it can be called “Open Source” if it includes a few binaries instead of source…

Going a bit off SGX-topic, in his blog post, Dan mentions:

“Whenever I talk with developers about Intelยฎ SGX, one of the first questions asked is โ€˜When will Linux support be availableโ€™?”

I am glax Intel SGX team is paying attention to Linux. There are many other Intel teams that only pay attention to Windows. ๐Ÿ˜ฆ

Full blog:

https://software.intel.com/en-us/blogs/2016/04/11/intel-software-guard-extensions-sdk-for-linux-availability-update

UEFI Customized Secure Boot: EDK2 branch

Chao B Zhang of Intel has created a branch of the Tianocore EDK-II for Customized Secure Boot, presumably a new flavor mentioned in the UEFI Forum’s private issue tracking system (or it is public, not sure yet what branch will contain). It sounds like some new post-2.6, pre-2.7 feature that Microsoft is requesting. I wonder how this will impact non-Windows OSes…

Excerpted readme:

[Staging/Customized-Secure-Boot]: Create branch for Customized Secure Boot

Create a remote branch Staging/Customized-Secure-Boot for EC1263 feature. This staging branch is requested by Jeremiah Cox of Microsoft for ECR 1263 Customized Secure Boot feature. This ECR has some conflicting language/figures that may result in in consistent implementations. Customized Secure Boto feature provides capabilities for automated platform deployment by enterprises, OEMs, system integrators, and enthusiasts into custom, higher security Secure Boot configurations.ย  This can mitigate chain of custody concerns in the supply chain of a given hardware platform. It further provides the ability to manage multiple UEFI certificate signers and image revocations from multiple signers.ย  It also provides a viable solution to enterprise, enthusiast, and OS vendor signing of images while maintaining overall security of the pre-boot environment.ย  Finally, it provides for a consistent programmatic and secure re-deployment of already-deployed systems.

More info:
https://github.com/tianocore/edk2-staging/tree/Customized-Secure-Boot
https://mantis.uefi.org/mantis/view.php?id=1263 (UEFI Forum members only, not for public)
https://lists.01.org/mailman/listinfo/edk2-devel

new Intel patch adding TCG OPAL unlock to Linux NVMe

Rafael Antognolli of Intel posted a patch to the Linux-(NVMe,Block,Kernel) mailing lists, adding TCG OPAL unlock support to NVMe:

Add Opal unlock support to NVMe. This patch series implement a small set of the Opal protocol for self encrypting devices. It’s implemented only what is needed for saving a password and unlocking a given “locking range”. The password is saved on the driver and replayed back to the device on resume from suspend to RAM. It is specifically supporting the single user mode. It is not planned to implement the full Opal protocol (at least not for now).

Add optane OPAL unlocking code. This code is used to unlock a device during resume from “suspend to RAM”. It allows the userspace to set a key for a locking range. This key is stored in the module memory, and will be replayed later (using the OPAL protocol, through the NVMe driver) to unlock the locking range. The nvme_opal_unlock() will search through the list of saved devices + locking_range + namespaces + keys and check if it is a match for this namespace. For every match, it adds an “unlocking job” to a list, and after this, these jobs are “consumed” by running the respective OPAL “unlock range” commands (from the OPAL spec):
ย  * STARTSESSION
ย  * SET(locking range, readwrite)
ย  * ENDSESSION

NVMe: Add ioctls to save and unlock an Opal locking range. Two ioctls are added to the NVMe namespace: NVME_IOCTL_SAVE_OPAL_KEY and NVME_IOCTL_UNLOCK_OPAL. These ioctls map directly to the respective nvme_opal_register() and nvme_opal_unlock() functions. Additionally, nvme_opal_unlock() is called upon nvme_revalidate_disk, so it will try to unlock a locking range (if a password for it is saved) during PM resume.

For more information, see the post on the list archives:
http://lists.infradead.org/mailman/listinfo/linux-nvme

new Microsoft ACPI table: WSMT

As mentioned earlier this week, Microsoft just released a spec for their new ACPI table WSMT (Windows SMM Security Mitigations Table):

Windows SMM Security Mitigations Table

The Windows SMM Security Mitigations Table specification contains details of an ACPI table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features. This information applies for Windows Server Technical Preview 2016, and Windows 10, version 1607. […]

Full spec:
http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx

The UEFI Forum maintains ACPI specs. AFAICT, their ACPI spec list does not yet list this new WSMT table.
http://www.uefi.org/acpi

Also, there’s a strange copyright in this spec:

Portions of this software may be based on NCSA Mosaic. NCSA Mosaic was developed by the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Distributed under a licensing agreement with Spyglass, Inc.

Maybe I am just noticing this paragraph, and Microsoft always uses that on copyright pages, and does not mention other old software, only NCSA Mosaic. But why NCSA Mosaic-centric copyrights in an WSMT ACPI table?? Microsoft IE 1.0 was based on NCSA Mosaic source code, via Spyglass purchase, but that was long before EFI or ACPI. I didn’t notice anything Win9x/BIOS/ISA-PNP-centric about WSMT. :-).

In related news, Jiewen Yao of Intel has submitted the WSMT definition into the tianocore EDK-II project:

MdePkg: Add WSMT definition. This patch adds Windows SMM Security Mitigation Table @ http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx

ย …/WindowsSmmSecurityMitigationTable.hย ย ย ย ย ย ย ย ย ย ย  | 39 ++++++++++++++++++++++
ย 1 file changed, 39 insertions(+)

+#define EFI_ACPI_WINDOWS_SMM_SECURITY_MITIGATION_TABLE_SIGNATUREย  SIGNATURE_32(‘W’, ‘S’, ‘M’, ‘T’)

Jiewen also submitted a 12-part patch, enhancing SMM to deal with this new table:

[PATCH 00/12] Enhance SMM Communication by using fixed comm buffer. This series patches are generate to meet Microsoft WSMT table definition on FIXED_COMM_BUFFERS requirement. Before this series patches, the DXE or OS module can use any non-SMM memory as communication buffer to exchange data with SMM agent. Microsoft WSMT table has requirement to support fixed communication buffer – so that SMM agent can only support communication buffer with type EfiReservedMemoryType/EfiRuntimeServicesCode/EfiRuntimeServicesData/EfiACPIMemoryNVS, which will not be used by OS during runtime. So we clean up all SMM handler to only use these memory regions for SMM communication, and enhance check in SmmMemLib to catch the violation. This series patches are validated on real platforms with SMM enabled. This series patches are validated on OVMF ia32-x64 with SMM enabled.

For full patch, see list archives:
https://lists.01.org/mailman/listinfo/edk2-devel

CHIPSEC training at REcon

The Intel CHIPSEC team doesn’t give training often, so when they do, it is worth mentioning.

Like last year, CHIPSEC will be offering training at REcon!

A variety of attacks targeting system firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, OS loaders and secure booting. This training will detail and organize objectives, attack vectors, vulnerabilities and exploits against various types of system firmware such as legacy BIOS, SMI handlers and UEFI based firmware, mitigations as well as tools and methods available to analyze security of such firmware components. It will also detail protections available in hardware and in firmware such as Secure Boot implemented by modern operating systems against bootkits. The training includes theoretical material describing a structured approach to system firmware security analysis and mitigations as well as many hands-on exercises to test system firmware for vulnerabilities. After the training you should have basic understanding of platform hardware components and various types of system firmware, security objectives and attacks against system firmware, mitigations available in hardware and firmware. You should be able to apply this knowledge in practice to identify vulnerabilities in BIOS and perform forensic analysis of the firmware.

https://recon.cx/2016/training/trainingfirmware.html

WinFlashROM: moving hosts

Darmawan Salihun has posted a new blog about WinFlashROM, a Windows port of FlashROM he did, and is moving it from Google Code to Github:

“This is old news because the code haven’t been updated for years. However, it might still relevant for those who want to port flashrom or other similar utility to present day Windows. I haven’t developed Windows driver anymore since Windows Server 2003. I’m not even sure if WDM-style driver is still in use in Windows. But, I might be returning to develop Windows driver this year. So, yeah, you (and I) never know.”

More information:
https://github.com/pinczakko/winflashrom
http://bioshacking.blogspot.co.id/2016/04/moving-winflashrom-code-to-github.html

(I haven’t looked into this, but I wonder if the CHIPSEC HAL for Windows (and Linux) might be useful in such a port. At least the kernel driver is maintained by Intel….)

AMI adds Redfish support

https://twitter.com/AMI_PR/with_replies

AMI has announced Redfish support for their UEFI implementation:

American Megatrends Announces Out-of-Band BIOS Configuration through Redfish

AMIย  is proud to announce out-of-band BIOS configuration compatible with DMTF Redfish. DMTF’s Redfish API platform was created by DMTF’s Scalable Platforms Management Forum as an open industry standard specification designed to provide end users simple and powerful, yet scalable management platform hardware. To meet the needs of end users, Redfish allows users to develop solutions that combat homogenous interfaces and reduced functionality. Redfish utilizes a combination of REST, JSON and OData and serves as a secure replacement for IPMI-over-LAN. AMI’s OOB (Out-of-Band) Firmware Management delivers extended management solutions through the adoption of Redfish between BIOS, BMC and Extensible Management Architecture (EMA). AMI OOB Firmware Management provides complete Redfish support and allows for the consistent exchange of information between the BIOS and BMC. AMI has been diligently working on providing an OOB firmware solution for datacenter solutions providers such as QCT (Quanta Cloud Technology).

https://ami.com/news/press-releases/?PressReleaseID=354
https://ami.com/products/bios-uefi-firmware/aptio-v/
http://www.dmtf.org/standards/redfish
http://redfish.dmtf.org/

HyperBone: minimalistic VT-X hypervisor with hooks

https://twitter.com/_jsoo_/status/720226750832087042

PG-compatible feature list:
ย ย ย  Syscall hooks via MSR_LSTAR
ย ย ย  Kernel inline hooks
ย ย ย  Kernel page substitution
ย ย ย  Kernel page EPT TLB splitting
ย ย ย  MSR hooks
ย ย ย  IDT hooks

Supported hardware: Intel processors with VT-x and EPT support
Supported platforms: Windows 7 – Windows 10, x64 only

More info:
https://github.com/DarthTon/HyperBone

Motherboard interview on Intel UEFI and IoT security

Motherboard has an interview with Brian Richardson of the Intel UEFI team, on the topic of IoT security. Wide range of topics covered!

http://motherboard.vice.com/en_uk/blog/protecting-firmware-is-crucial-for-iot-technology

 

USB Type-C authentication protocol: defense against bad cables

https://twitter.com/CypressSemi/status/721416739372855301

The USB-IF has developed a cryptographic-based authentication protocol to help protect from bad USB Type-C cables!

http://www.engadget.com/2016/04/13/usb-type-c-authentication-protocol/

http://www.businesswire.com/news/home/20160412005983/en/USB-3.0-Promoter-Group-Defines-Authentication-Protocol

Click to access USB_Type-C_Authentication_PR_FINAL.pdf

http://www.usb.org/press

Intel Tamper Protection Toolkit

Intel has posted a blog post on their Intel Tamper Protection toolkit:

Intelยฎ Tamper Protection Toolkit Helps Protect the Scrypt Encryption Utility against Reverse Engineering

Roman Kazantsev, Denis K., Thaddeus Letnes

This article describes how the Intelยฎ Tamper Protection Toolkit can help protect critical code and valuable data in a password-based encryption utility (Scrypt Encryption Utility) [3] against static and dynamic reverse-engineering and tampering. Scrypt [4] is a modern secure password-based key derivation function that is widely used in security-conscious software. There is a potential threat to scrypt described in [2] when an attacker can force generation of weak keys by forcing use of specific parameters. Intelยฎ Tamper Protection Toolkit can be used to help mitigate this threat. We explain how to refactor relevant code and apply tamper protection to the utility.

https://software.intel.com/en-us/articles/intel-tamper-protection-toolkit-helps-protect-the-scrypt-encryption-utility-against-reverse
https://software.intel.com/en-us/tamper-protection

Vincent on Intel FSP and EDK-II interactions

Vincent Zimmer of Intel has a new blog post, on UEFI’s EDK-II and Intel FSP (Firmware Support Package), and how the FSP works with the EDK-II. Good background, with lots of links.

https://firmware.intel.com/blog/open-source-platforms-edkii-using-intel-fsp

 

For more information on UEFI and FSP, also read the APress book, which Vincent is one of the authors:

Book Review: Embedded Firmware Solutions