Author: hucktech

LUV announces v2.1-rc2 release

~ hucktech ~ Leave a comment

Ricardo Neri of Intel posted a LONG announcement about LUV V2.1-rc2, most of which included here. There are a LOT of new features in this LUV release!

This is to announce the release of LUV v2.1-rc2. It has been a while since the last time of our last release. This is not the ideal release cadence are working to make changes. We will now release more frequently. We aim to release a new version every 4-5 weeks with the content we accumulate over that period of time. Given the large number of new features and changes in this release, it made sense to release it as rc2 of v2.1 to allow for issues to arise and stabilize towards the next release cycle.

This release include the client side of our telemetrics solution. This solution is based on the implementation done for Clear Linux[1]; abiding Intel privacy policies[2]. Please note that telemetrics is an opt-in feature and is disabled by default and only works for systems within Intel networks. We will work now on the server side of the solution.

In this release we have migrated from systemV to systemd, which is inline with most Linux distributions. Also, our telemetrics client needed it to function. Megha Dey did all the heavy lifting to migrate to systemd; which was not an easy task (kudos to her!). She worked on stabilizing network and revamping our splash screen, which now uses plymouth.

Sai Praneeth Prakhya extended our existing implementation to detect illegal access to UEFI Boot Services memory regions after boot. His extension now allows to detect such access to also conventional memory. Likewise, it now detects these acceses at runtime and long after UEFI SetVirtualAddressMap. This has been quite useful recently to detect bugs related to UEFI capsules in certain firmware implementations.

Gayatri Kammela worked on providing tools to make the netboot images more useful. She completed a reference implementation of an HTTP server to collect test results in a test farm. The documentation of this implementation can be found here[2]; we don’t provide collection services. Of course, the client-side implementation of this solution is part of this release. Along with this solution, she wrote a script to customize a netboot binary (an EFI application) to work with her reference implementation[4].

Naresh Bhat updated the kernel configuration for aarch64. He also worked on providing a more clean, unified and structured kernel command line for all the supported CPU architectures. He also enabled support of netboot images for aarch64.

Fathi Boudra kindly reworked the kernel configuration fragments to avoid unnecessary duplications.

Matt Hart added a new luv.poweroff option.

Configuration of LUV has been simplified by moving all the parameters that the user might configure a LUV.cfg file found in the boot partition of the disk image. No more meddling with the grub.cfg configuration file.

We now provide images built for both GPT and MBR partition schemes.

Updated test suites: We include FWTS V17.03.00, CHIPSEC v1.2.5 plus all the changes available as of this week towards the release of v.1.2.6, which should be coming soon. BITS was bumped to v2079. We use Linux v4.10. This release is based on the Morty version of the Yocto Project.

meta-oe and updates to the build process: Our build process changed a bit. We now include certain components from the  meta-oe layer[5]. Such layer has been added to our repository, but it still need to be added locally to the build/conf/bblayers.conf file when building.

Binary images for x86: A announcement to download binary images for x86 will be sent this week.

See rest of announcement for list of Known Issues, and Fixed Issues.

[1] https://clearlinux.org/features/telemetry
[2] http://www.intel.com/content/www/us/en/privacy/intel-privacy.html
[3] https://github.com/01org/luv-yocto/wiki/Send–LUV-test-results-to-an-HTTP-server
[4] https://github.com/01org/luv-yocto/wiki/Using-LUV-Script-modify_luv_netboot_efi.py
[5] https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/

Full announcement:
https://lists.01.org/mailman/listinfo/luv

proposed driver model for U-Boot init

~ hucktech ~ Leave a comment

Simon Glass of Chromium posted an 16-part patch to the U-Boot list, adding a driver model to the U-Boot init sequence.

[PATCH 00/16] RFC: Board init using driver model

At present we have a lot of ad-hoc init functions related to boards, for example board_early_init_f(), board_misc_init_f() and dram_init(). There are used in different ways by different boards as useful hooks to do the required init and sequence it correctly. Some functions are always enabled but have a __weak default. Some are controlled by the existence of a CONFIG. There are two main init sequences: board_init_f() (f for running from read-only flash) which runs before relocation and board_init_r() (r for relocated) which runs afterwards. One problem with the current sequence is that it has a lot of arch-specific #ifdefs around various functions. There are also #ifdefs for various features. There has been quite a bit of discussion about how to tidy this up and at least one RFC series[1].

Now that we have driver model we can use this to deal with the init sequences. This approach has several advantages:
– We have a path to remove the #ifdefs
– It is easy for multiple parts of the code to implement the same hook
– We can track what is called and what is not
– We don’t need weak functions
– We can eventually adjust the sequence to improve naming or to add new init phases
– It provides a model for how we might deal with ft_board_setup() and friends

This series starts the process of replacing the pre-relocation init sequence with a driver-model solution. It defines a uclass, adds tests and converts sandbox and a few x86 boards over to use this new setup. This series is not ready for use yet as the rest of the init sequence hooks need to be converted. But there is enough here to show the idea.

Comments welcome.

[1] https://lists.denx.de/pipermail/u-boot/2011-August/098718.html

37 files changed, 980 insertions(+), 45 deletions(-)
[…]
create mode 100644 doc/driver-model/board-info.txt
[…]

More information:
https://lists.denx.de/listinfo/u-boot

SELoader: Secure EFI Loader

~ hucktech ~ Leave a comment

Secure EFI Loader
The SELoader is designed to authenticate the non-PE files which cannot be verified by the MOK verify protocol supplied by shim loader, such as grub configuration, initrd, grub modules and so on. The SELoader employs PKCS7 Verify Protocol available since UEFI Specification version 2.5 to verify the signature to prove the integrity of checked file. If BIOS doesn’t support it, a pre-built Pkcs7VerifyDxe driver is provided. In order to estabilish the chain of trust, the SELoader is required to be signed by a private key corresponding to a DB certificate, the shim certificate, the vendor certificate or a shim MOK certificate. The specifical key is determined by the Secure Boot scheme you will use. Using UEFI Secure Boot, MOK verify protocol and SELoader Secure Boot together, the boot process will be completely trustworthy.

https://github.com/jiazhang0/SELoader

CHIPSEC gets new MMIO BAR module

~ hucktech ~ Leave a comment

Experimental module that may help checking SMM firmware for MMIO BAR hijacking
vulnerabilities described in the following presentation:
`BARing the System: New vulnerabilities in Coreboot & UEFI based systems <http://www.intelsecurity.com/advanced-threat-research/content/data/REConBrussels2017_BARing_the_system.pdf&gt;`_ by Intel Advanced Threat Research team at RECon Brussels 2017
Usage:
  “chipsec_main -m tools.smm.rogue_mmio_bar [-a <smi_start:smi_end>,<b:d.f>]“
 
– “smi_start:smi_end“: range of SMI codes (written to IO port 0xB2)
– “b:d.f“: PCIe bus/device/function in b:d.f format (in hex)
Example:
    >>> chipsec_main.py -m tools.smm.rogue_mmio_bar -a 0x00:0x80
    >>> chipsec_main.py -m tools.smm.rogue_mmio_bar -a 0x00:0xFF,0:1C.0

 

EFI TBOOT

~ hucktech ~ Leave a comment

The EFI TBOOT project is currently under development! EFI TBOOT is mostly a proof of concept at this point. It is not currently functional. It can be built and installed as an EFI boot loader. It only works in conjunction with Xen at the moment. The current development work is being done on Fedora 25 x64. The status as of March 14, 2017 is:
 – EFI TBOOT will boot, but it needs a few key strokes to get going (this is for debugging purposes).
 – EFI TBOOT will relocate itself to EFI runtime memory and setup a shared runtime variable with Xen.
 – EFI related configuration setup is done as well as standard TBOOT pre-launch configuration.
 – Xen is launched and has code to call EFI TBOOT back after EBS.
 – EFI TBOOT then does the SENTER successfully in the callback.
 – The post launch entry point is reached but the switch back to long mode is not working.
[…]
EFI TBOOT needs a number of platform support files used with TXT (called Authenticated Code Modules or ACMs). For convenience the packages can be gotten from the OpenXT mirror:
http://mirror.openxt.org/
[…]

https://github.com/rossphilipson/efi-tboot

Hardware.io 2017 CFP is open

~ hucktech ~ Leave a comment

Security Conference is a platform for hardware and security community where researchers showcase and discuss their innovative research on attacking and defending hardware. The objective of the conference revolves around four key concerns in hardware, firmware and related protocols i.e. backdoors, exploits, trust and attacks (BETA).

Training: 19th – 20th Sept 2017
Conference: 21st – 22nd Sept 2017
http://hardwear.io/

 

FWTS 17.03.00 released

~ hucktech ~ Leave a comment

Ivan Hu of Canonical announced the release of FWTS 17.03.00. There’s a new SBBR test, and a slew of bugfixes.

New Features :
  * ACPICA: Update to version 20170224
  * sbbr: Add “–sbbr” flag to support running SBBR Tests.
  * acpi: iort: Add support for SMMUv3

http://fwts.ubuntu.com/release/fwts-V17.03.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/17.03.00
https://launchpad.net/ubuntu/+source/fwts
https://lists.01.org/mailman/listinfo/luv

https://community.arm.com/iot/b/blog/posts/arm-server-standards-part-2-sbbr-specification-released

Intel firmware bug bounty program!

~ hucktech ~ Leave a comment

https://www.hackerone.com/blog/Intel-launches-its-first-bug-bounty-program

 

UEFI-Dumper

~ hucktech ~ Leave a comment

“UEFI-Dumper is a simple perl script to get access to your Insyde Bios hidden menus.”

The source code says: Copyright (c) 2013 Nurlan Mukhanov (aka Falseclock).

https://github.com/Falseclock/UEFI-dumper

The tool appears brand-new, from Github epoch. But given the 2013 date in the copyright, it is probably older. A quick search finds the same code from a 3-year-old post:
http://developers-club.com/posts/182676/

When I noticed this, I sent an FYI to the the UEFI Security team and to Insyde’s security team, in case they hadn’t seen it. Kevin Davis of Insyde responded with:

“Insyde Software takes the security of our customer’s platforms very seriously. InsydeH2O and SETUP page settings are based on public specifications.  Insyde is aware that the UEFI-Dumper allows individuals to get the information about SETUP pages that customers have hidden. Insyde believes that current customer platforms are following our guidelines for protecting sensitive system variables from malicious changes. As the first BIOS vendor to ship production systems supporting the UEFI standards, Insyde has always worked to improve the UEFI standards and our InsydeH2O BIOS.  Our customers are encouraged to work with their Insyde contacts to continue to build secure systems.”

[1] https://www.insyde.com/contact/reportsecurity

Raytheon seeks Embedded Vulnerability Researcher

~ hucktech ~ Leave a comment

 […] Our Embedded System Vulnerability Researchers analyze a variety of devices to understand how they work and how they behave when they break. If it runs code, somebody in our office has looked at it. Candidates must be proficient with binary analysis techniques and familiar with vulnerability types such as heap corruption, use after free, and buffer overflows. Projects will be undertaken in small teams with close coordination with customers. A typical day may involve extracting firmware from a board, studying disassembly, or writing code to audit a device. Required Skills: Experience with C or C++ Proficient with static and dynamic binary analysis techniques Familiar with software vulnerabilities Experience reading and writing PowerPC Experience using reverse engineering tools such as IDA Pro, Binary Ninja, or objdump Experience using debuggers such as gdb Comfortable working in a Linux environment 3 or more of the “desired skills” below. Desired Skills: 4+ years of professional experience in VR, RE or related fields Experience developing embedded systems Knowledge of RTOS or Linux kernel internals Understanding of network protocols (TCP/IP stacks, RF communications, routing protocols, or others). Understanding of exploit mitigations such as DEP and ASLR Experience reading and writing non-PowerPC assembly (ARM, Intel, MIPS, or other) Experience using JTAGs or other techniques for firmware extraction Security Clearance: Qualified applicants may be subject to a security investigation and must meet minimum qualifications for access to classified information[…]

https://jobs.raytheon.com/job/-/-/4679/4223100?codes=3640

Intel Xeno Phi memory modes

~ hucktech ~ Leave a comment

James Reinders has an article in InsideHPC describes Intel XeonPhi memory modes:

[…]In this article, I will discuss one of the “mode” options that Intel Xeon Phi processors have to offer unprecedented configurability: memory modes. For programmers, this is the key option to really study because it may inspire programming changes. In my next article, I’ll tackle the other mode option (cluster modes). The memory modes allow the MCDRAM to be used as either a high bandwidth cache or a high bandwidth memory, or a little of each.[…]

http://insidehpc.com/2017/03/intel-xeon-phi-memory-mode-programming-mcdram-nutshell/

 

 

LUV adds EFI_WARN_ON_ILLEGAL_ACCESSES

~ hucktech ~ Leave a comment

Sai Praneeth Prakhya of Intel has posted a patch to the LUV project list, with new clever new abilities to increase LUV’s ability to detect bad UEFI firmware.

Presently, LUV detects illegal accesses by firmware to EFI_BOOT_SERVICES_* regions only during “SetVirtualAddressMap()”. According to UEFI spec, this function will be called only once; by kernel during boot. Hence, LUV cannot detect any other illegal accesses that firmware might do after boot. Moreover, LUV can detect illegal accesses *only* to EFI_BOOT_SERVICES_CODE/DATA regions. This patch set tries to address the above mentioned two issues:
1. Detect illegal accesses to other EFI regions (like EFI_LOADER_CODE/DATA, EFI_CONVENTIONAL_MEMORY)
2. Detect illegal accesses to these regions even after kernel has booted
Recently, we came across machines with buggy firmware that access EFI memory regions like EFI_CONVENTIONAL_MEMORY, EFI_BOOT_SERVICES_CODE/DATA and EFI_LOADER_CODE/DATA even after kernel has booted. Firmware accesses these regions when some efi_runtime_service() is invoked by test cases like FWTS. These illegal accesses can potentially cause kernel hang. Hence, it’s good to have a test case in LUV which can detect these illegal accesses and hence report them to user. This requires making changes to kernel and searching dmesg for relative warnings. As there are 9 patches to linux kernel to enable this feature and putting all these 9 kernel patches in a single LUV patch makes the LUV patch gigantic; hence I have split them into smaller ones (as suggested by Ricardo). The first patch in this series (“linux-yocto-efi-test: Do not support EFI_BOOT_SERVICES_WARN”) removes support to “EFI_BOOT_SERVICES_WARN” and the later patches add all the bits and pieces together and the 10th patch (“linux-yocto-efi-test: Introduce EFI_WARN_ON_ILLEGAL_ACCESSES”) enables the (new) feature.

Full patch:
https://lists.01.org/mailman/listinfo/luv
.