EFI changes for Linux v4.9

Matt Fleming sent a message to Linux Kernel/EFI lists with a set of UEFI-centric patches for Linux 4.9. Excerpting his message:

[…]There’s more work on refactoring EFI code to be architecture independent and the largest number of patches is spent cleaning up the EFI memory map code and allowing drivers on x86 to reserve EFI boot services for all of runtime. The architecture independent quest is going pretty well and it was only a couple of lines to get the esrt driver working on arm64. Other than that there’s some cleanups and fixes, and a merge of the out of tree EFI runtime driver from the FWTS project.

 * Refactor the EFI memory map code into architecture neutral files and allow drivers to permanently reserve EFI boot services regions on x86, as well as ARM/arm64 – Matt Fleming
 * Add ARM support for the EFI esrt driver – Ard Biesheuvel
 * Make the EFI runtime services and efivar API interruptible by swapping spinlocks for semaphores – Sylvain Chouleur
 * Provide the EFI identity mapping for kexec which allows kexec to work on SGI/UV platforms with requiring the “noefi” kernel command line parameter – Alex Thorlton
 * Add debugfs node to dump EFI page tables on arm64 – Ard Biesheuvel
 * Merge the EFI test driver being carried out of tree until now in the FWTS project – Ivan Hu
 * Expand the list of flags for classifying EFI regions as “RAM” on arm64 so we align with the UEFI spec – Ard Biesheuvel
 * Optimise out the EFI mixed mode if it’s unsupported (CONFIG_X86_32) or disabled (CONFIG_EFI_MIXED=n) and switch the early EFI boot services function table for direct calls, alleviating us from having to maintain the custom function table – Lukas Wunner
 * Miscellaneous cleanups and fixes
[…]

git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next

Intel SGX tutorial part 4 to be released shortly

John M. of Intel has a new blog post with status on his next Intel SGX tutorial. Nice, it looks like there are many upcoming articles!

[…] Part 4 of the Intel Software Guard Extensions (Intel SGX) Tutorial Series will be coming out in the next few days. In it, we’ll be starting our enclave implementation, focusing on the bridge/proxy functions for the enclave itself as well as the middleware layer needed for the C++ code to interact with it. If you recall from the introduction, we are planning five broad phases in the series. With part 4 we complete our transition from the first phase, which focused on concepts and design, to the development and integration in the second. I want to take a few minutes to talk about what else is coming up and roughly where we are headed over the coming weeks. Part 5 will complete the development of the enclave. While part 4 is focused on the enclave interface layer and the enclave definition language (EDL), in part 5 we will code up the internals of enclave itself. In part 6, we’ll add support for dual code paths so that the application runs on hardware that is both Intel SGX capable and incapable. In a change from our original plan for the series, part 7 will look at power events (specifically, suspend and resume) and its impact on enclaves. After that, we’ll enter into the third phase of the tutorial which focuses on testing and validation. Here, we’ll demonstrate that Intel SGX is providing the expected security benefits. We’ll also look at tuning the enclave configuration to better match our usage. The final two phases, packaging and deployment, and disposition, will follow.
[…]

https://software.intel.com/en-us/blogs/2016/09/09/intel-software-guard-extensions-intel-sgx-tutorial-series-looking-ahead
https://software.intel.com/en-us/articles/introducing-the-intel-software-guard-extensions-tutorial-series

Intel SGX tutorial part3 published today

RU.EFI updated, screen snapshot support

http://ruexe.blogspot.com/2016/09/ru-518291-beta.html

https://github.com/JamesAmiTw/ru-uefi/

 RU 5.18.291 BETA
This release is mainly for saving snapshot from RU screen as BMP file.  Which is requested by Gary and other users.  Special thanks to Mykhaylo for the help. I didn’t test this version at all, so it could be buggy.  Please leave me a message if you find any bug.

New feature:
RU.EFI: Add F12 key to capture the screen snapshot to BMP file.
File name is auto-generated: Format: “YYYYMMDDhhmmss.bmp”
RU.EXE does not support this.

See post for list of bugfixes.

Intel Distribution for Python

Intel has a new Anaconda Python distribution, built with Intel libs to enhance speed/concurrency to help.

It is registration-required freeware if you download it from Intel. It mentions below that  it might also be installable via Anaconda, unclear if registration is required for Anaconda. I’ve not found the source to this project yet, but I could’ve missed it.

https://software.intel.com/en-us/blogs/2016/09/08/intel-distribution-for-python

A few excerpts from their home page below:

Get up to 97 times faster numerical processing on SciPy stack: NumPy, SciPy, and scikit-learn boosted by the Intel® Math Kernel Library. Speed up data analytics with pyDAAL and parallelize Python workloads with enhanced Intel® Threading Building Blocks (Intel® TBB).

The all-included, out-of-the box distribution accelerates core Python packages including NumPy, SciPy, pandas, scikit-learn, Jupyter, matplotlib, and mpi4py. It integrates the powerful Intel® Math Kernel Library (Intel® MKL), Intel® Data Analytics Acceleration Library (Intel® DAAL) and pyDAAL, Intel® MPI Library, and Intel® Threading Building Blocks (Intel® TBB).

Multithreaded Python workloads can take advantage of multicore architectures from Intel using Intel TBB optimized thread scheduling and efficient communication with the Intel MPI Library.

Installing and managing your Python environment is made easy with the all-in-one installer from Intel or by installing packages from Anaconda Cloud using conda. Third-party packages can be installed with both conda and PIP.

Use the Intel® Distribution for Python powered by Anaconda as a drop-in replacement for your current Python environment to get high performance out of the box. Your Python applications immediately gain significant performance and can further be tuned to extract every last bit of performance using the Intel® VTune™ Amplifier.

The Intel® Distribution for Python is available for free for Python 2.7.x and 3.5.x on OS X*, Windows* 7 and later, and Linux*.

PS: Alas, this does not to appear to be integrated with Intel’s port of CPython to UEFI. 🙂

Big changes at Intel Security…

There are some changes at Intel Security, Texas Pacific Group (TPG), a private equity firm, has acquired them.

Their web site has been replaced with a single article:

September 7, 2016

Intel Security Stakeholders,

Today, Intel and TPG made an exciting announcement that I want to share with you directly.  We unveiled a strategic partnership with the goal of creating one of the largest independent, pure-play cybersecurity companies in the industry. To enable this partnership, we are creating a new corporate entity, to be named McAfee, of which Intel will continue to own 49% and TPG, a leading global alternative asset firm with substantial experience investing in best-in-class technology companies, will own 51%. We will have access to significant financial, operational, and technology resources, enabling us to realize our full potential as a standalone business.[…]

http://www.intelsecurity.com/

http://press.tpg.com/phoenix.zhtml?c=254315&p=irol-newsArticle&ID=2200331

I think the CHIPSEC team works under Intel Security. I wonder where they work today?

US-CERT on validation of Grey Market hardware

US-CERT has issued a new thread advisory, on network infrastructure, including some emphasis on hardware/firmware security advice. I’m excerpting their recommendations on on hardware validation:

[…]
6. Validate Integrity of Hardware and Software

Products purchased through unauthorized channels are often known as “counterfeit,” “secondary,” or “grey market” devices. There have been numerous reports in the press regarding grey market hardware and software being introduced into the marketplace. Grey market products have not been thoroughly tested to meet quality standards and can introduce risks to the network. Lack of awareness or validation of the legitimacy of hardware and software presents a serious risk to users’ information and the overall integrity of the network environment. Products purchased from the secondary market run the risk of having the supply chain breached, which can result in the introduction of counterfeit, stolen, or second-hand devices. This could affect network performance and compromise the confidentiality, integrity, or availability of network assets. Furthermore, breaches in the supply chain provide an opportunity for malicious software or hardware to be installed on the equipment. In addition, unauthorized or malicious software can be loaded onto a device after it is in operational use, so integrity checking of software should be done on a regular basis.

Recommendations:

  * Maintain strict control of the supply chain; purchase only from authorized resellers.
  * Require resellers to implement a supply chain integrity check to validate hardware and software authenticity.
  * Inspect the device for signs of tampering.
  * Validate serial numbers from multiple sources.
  * Download software, updates, patches, and upgrades from validated sources.
  * Perform hash verification and compare values against the vendor’s database to detect unauthorized modification to the firmware.
  * Monitor and log devices, verifying network configurations of devices on a regular schedule.
  * Train network owners, administrators, and procurement personnel to increase awareness of grey market devices.
[…]
Full advisory:
https://www.us-cert.gov/ncas/alerts/TA16-250A

_DSD Guidance updated

Re: this previous post:

Guidance on using ACPI _DSD with Linux

Al Stone of Red Hat published an updated version of 3 documents giving guidance on using _DSD ACPI:

[RFC DSD v3 00/04] How to Use the ACPI _DSD Device Properties UUIDs

A copy of the ChangeLog is also attached so that you can see what the primary changes were for this second version.

https://github.com/ahs3/dsd/tree/master/documentation

https://github.com/ahs3/dsd/commit/7fbdce494b9b7b952e709e43b8dbbfd5cf8d4fcb
https://github.com/ahs3/dsd/commits/master

Click to access _DSD-device-properties-UUID.pdf

Click to access _DSD-hierarchical-data-extension-UUID-v1.pdf

cryptboot

Interesting new project. I wish most modern Linux distros let you control keys in ways like this. Check out the entire web page on Github, nice read for Linux/UEFI even if you don’t plan on using cryptboot.

https://github.com/xmikos/cryptboot

Encrypted boot partition manager with UEFI Secure Boot support

With encrypted boot partition, nobody can see or modify your kernel image or initramfs. GRUB boot loader supports booting from encrypted boot partition, but you would be still vulnerable to Evil Maid attacks. One possible solution is to use UEFI Secure Boot. Get rid of preloaded Secure Boot keys (you really don’t want to trust Microsoft and OEM), enroll your own Secure Boot keys and sign GRUB boot loader with your keys. Evil maid would be unable to boot modified boot loader (not signed by your keys) and whole attack is prevented. cryptboot simply makes this easy and manageable.

Requirements
* Linux (x86_64)
* UEFI firmware with enabled Secure Boot
* separate /boot partition encrypted with LUKS
* cryptsetup
* openssl
* efitools
* sbsigntools
* efibootmgr
* grub (grub-efi on Debian based distributions)

[…]

And this article points out something else crazy: “but current TrustedGRUB2 doesn’t even support UEFI yet.

USBee

Dan goodin has an article on Ars about some BadUSB-like malware:

Meet USBee, the malware that uses USB drives to covertly jump airgaps

In 2013, a document leaked by former National Security Agency contractor Edward Snowden illustrated how a specially modified USB device allowed spies to surreptitiously siphon data out of targeted computers, even when they were physically severed from the Internet or other networks. Now, researchers have developed software that goes a step further by turning unmodified USB devices into covert transmitters that can funnel large amounts of information out of similarly “air-gapped” PCs. The USBee—so named because it behaves like a bee that flies through the air taking bits from one place to another—is in many respects a significant improvement over the NSA-developed USB exfiltrator known as CottonMouth. That tool had to be outfitted with a hardware implant in advance and then required someone to smuggle it into the facility housing the locked-down computer being targeted. USBee, by contrast, turns USB devices already inside the targeted facility into a transmitter with no hardware modification required at all. “We introduce a software-only method for short-range data exfiltration using electromagnetic emissions from a USB dongle,” researchers from Israel’s Ben-Gurion University wrote in a research paper published Monday. “Unlike other methods, our method doesn’t require any [radio frequency] transmitting hardware since it uses the USB’s internal data bus.”
[…]

Click to access USBee.pdf

http://arstechnica.com/security/2016/08/meet-usbee-the-malware-that-uses-usb-drives-to-covertly-jump-airgaps/

 

FaceWhisperer

https://twitter.com/scanlime/status/771553651961630720

“FaceWhisperer: USB host add-on for the ChipWhisperer side-channel analysis tool.

FaceWhisperer is a hardware add-on for the ChipWhisperer side-channel analysis tool, for working with devices that primarily communicate over USB. The goal is to create a USB host controller scripted with an experiment, all running totally synchronous with the target. This should give predictable timing each time the experiment is run from a target reset. The (untested) goal is to use standard USB requests as a data exfiltration method while glitching the device code that fulfills these requests. […]

https://github.com/scanlime/facewhisperer

Xenpwn

“Xenpwn is a toolkit for memory access tracing using hardware assisted virtualization. It runs as a normal user space application inside the management domain (dom0) of a Xen hypervisor and can be used to trace any memory accesses performed by another VM running on the same hypervisor. The toolkit uses libvmi for interaction with the Xen hypervisor API and relies on simutrace for efficient storage of memory traces. Xenpwn was used to discover double fetch vulnerabilities in the inter domain communication of the Xen hypervisor resulting in XSA 155. Further research on identifying double fetches in other software is still ongoing.[…]”

https://github.com/felixwilhelm/xenpwn

Voltron integration for Binary Ninja

https://github.com/snare/binjatron
https://github.com/snare/voltron
http://ho.ax/

Binary Ninja plugin for Voltron integration.

Features:
* Synchronise the selected instruction in Binary Ninja with the instruction pointer in the debugger
* Mark breakpoints that are set in the debugger in Binary Ninja
* Set and delete breakpoints in the debugger from Binary Ninja

Voltron

Binary Ninja

 

new Minnowboard variant

It sounds like this new Minnowboard Turbot Quad Core from ADI will be out in December for around $190.

“ADI Engineering announced an upcoming Quad Core varient of the MinnowBoard Turbot that will used the E3845 SoC. Compatible with the existing MAX and Turbots this brings a new level of performance to the SoC for those computationally expensive tasks.”

For more info, click on the G+ link in the above tweet, WordPress appears to discard G+-based URLs today.

From the Netgate pre-order page:

Improvements over MinnowBoard Turbot Dual Core
* Twice the core count. Higher clock speed.
* Over 2.5 times FASTER than the MinnowBoard Tubot dual core.
*  Better Ethernet! This board has Intel i211 vs Realtek NIC.
* Fansink keeps it cool! Suitable for higher temp applications.

http://store.netgate.com/Turbot4.aspx

Nothing here yet AFAICT: http://minnowboard.org/

Talos Secure Workstation: coreboot + POWER8

https://twitter.com/coreboot_org/status/771398728179736579

New potential product on CrowdSupply with a NICE set of features (…and I wonder how secure it will be):

* Blob-free operation
* Fully libre (open-source) IBM OPAL primary firmware w/ PetitBoot interface
* Fully libre (open-source) OpenBMC secondary (IPMI / OoBM) firmware
* NO signing keys preventing firmware modification

https://www.crowdsupply.com/raptorcs/talos

Steven Ellis: firmware updating on Linux

Steven Ellis of Red Hat has a new article on OpenSource.com on updating firmware and UEFI, with lots of good stuff to read. He mentions his next article will be on the topic of patching SSD firmware, which sounds very interesting. Spoiler alert: I’m exerpting his Recommendations from the end of the post:

[…] In this article, I’ll walk through my recent firmware update on Linux, and I’ll share a few recommendations based on that experience. […]
Recommendations:
* More vendors should allow UEFI BIOS updates directly from the BIOS-style interface. UEFI shell command-line isn’t for the casual user.
* If your vendor supplies a bootable image, try to use that first.
* Investigate what supported tools are available, but consider using a live image for patching. I’m somewhat wary of tools that build and install their own kernel modules.
* Assist projects—like flashrom—to avoid these issues in the future.
[…]

https://opensource.com/life/16/8/almost-open-bios-and-firmware-update-tips-linux-users

Filippo Valsorda: reversing OpenBSD FDE passwords

Filippo Valsorda of the CloudFlare Security Team wrote a blog on OpenBSD’s full-disk-encryption, after he lost his password.

So I lost my OpenBSD FDE password
The other day I set up a new OpenBSD instance with a nice RAID array, encrypted with Full Disk Encryption. And promptly proceeded to forget part of the passphrase. […] I did a weak attempt at finding some public bruteforce tool, and found nothing. I say weak because somewhere in the back of my brain, I already wanted to take a peek at the OpenBSD FDE implementation. Very little is documented, and while I do trust OpenBSD, I want to know how my data is encrypted. So this was the “perfect” occasion. […]

https://blog.filippo.io/so-i-lost-my-openbsd-fde-password/
https://github.com/FiloSottile/openbsd-fde-crack
Related info:
http://thiébaud.fr/openbsd_softraid.html

 

FFRI on CHIPSEC

FFRI have done a presentation on CHIPSEC:

Monthly Research 2016.7: About security assessment framework “CHIPSEC”

Click to access MR201607_About_security_assessment_framework_CHIPSEC_ENG.pdf

http://www.ffri.jp/search_result/index.htm?q=CHIPSEC

http://www.ffri.jp/blog/2016/08/2016-08-09.htm