Category: Uncategorized

UEFI boot support for locked SEDs updated

~ hucktech ~ Leave a comment

Eric Dong of Intel has updated UEFI’s TCG OVAL support, used with SEDs, how the UEFI-based system will work with the locked SEDs, when the user has no valid password:

[Patch] SecurityPkg OpalPasswordDxe: Enhance input password process.

Enhance the input password process, when device in unlock status and user press ESC, shutdown the device. If user reach the max try number, shutdown the device.

+  L”Confirm: Not unlock device and continue boot?.”,
+  L”Press ENTER to confirm, Press Esc to input password”,
+  L”Warning: system in unkown status, must shutdown!”,
+  L”Press ENTER to shutdown.”,

– L”Opal password retry count is expired. Keep lock and continue boot.”,
+ L”Opal password retry count exceeds the limit. Must shutdown!”,
  L”Press ENTER to continue”,

For more information, see the patch on the edk2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

Intel SGX talk at VirusBulletin

~ hucktech ~ Leave a comment

The antivirus-centric conference VirusBulletin is happening this October, and there’s an Intel SGX talk on the agenda:

Trusted Code Execution on Untrusted Platform Using Intel SGX
Prof. Guevara Noubir (Northeastern University)
Amirali Sanatinia (Northeastern University)

Today, isolated trusted computation and code execution is of paramount importance to protect sensitive information and workflows from other malicious privileged or unprivileged software. Intel Software Guard Extensions (SGX), is a set of security architecture extensions introduced in the Skylake microarchitecture that enables a Trusted Execution Environment (TEE). It provides an ‘inverse sandbox’, for sensitive programs, and guarantees the integrity and confidentiality of secure computations even from the most privileged malicious software (e.g. OS, Hypervisor). SGX-capable CPUs only became available in production systems in Q3 2015, however they are not yet fully supported and adopted in systems. Besides the capability in the CPU, the BIOS also needs to provide support for the enclaves, and not many vendors have released the required updates for the system support. This led to many wrong assumptions being made about the capabilities, features, and ultimately dangers of secure enclaves. By having access to resources and publications such as white papers, patents and the actual SGX-capable hardware and software development environment, we are in a privileged position to be able to investigate and demystify SGX. In this paper, we first review the previous Trusted Execution technologies, such as ARM Trust Zone and Intel TXT, to better understand and appreciate the new innovations of SGX. Then we look at the details of SGX technology, cryptographic primitives and the underlying concepts that power it, namely the sealing, attestation, and the Memory Encryption Engine (MEE). Then we look at the use cases such as trusted and secure code execution on an untrusted cloud platform, and Digital Rights Management (DRM). This is followed by an overview of the software development environment and the available libraries.

https://www.virusbulletin.com/conference/vb2016/abstracts/trusted-code-execution-untrusted-platform-using-intel-sgx

https://www.virusbulletin.com/conference/vb2016/programme

Microsoft’s RIoT (Robust IoT)

~ hucktech ~ Leave a comment

Microsoft Research has released a paper on their new Robust IoT platform:

RIoT – A Foundation for Trust in the Internet of Things
Paul England, Andrey Marochko, Dennis Mattoon, Stefan Thom, and David Wooten
21 April 2016
MSR-TR-2016-18

RIoT (Robust Internet-of-Things) is an architecture for providing foundational trust services to computing devices. The trust services include device identity, sealing, attestation, and data integrity. The term “Robust” is used because the minimal trusted computing base is tiny, and because RIoT capabilities can remotely re-establish trust in devices that have been compromised by malware. The term IoT is used because these services can be provided at low cost on even the tiniest of devices.

http://research.microsoft.com/apps/pubs/default.aspx?id=264838

Troy Martin’s Windows Device Guard trilogy

~ hucktech ~ Leave a comment

Troy Martin of 1E has written the final of this 3-part blog posts on Device Guard, a new feature of Windows 10, targetting enterprise sysadmins.

[…]
Welcome to the third and final blog in the series on Device Guard!!
Device Guard hardens various attack surfaces on an endpoint creating a “chain of trust” from the hardware through to the Windows OS kernel and to software running in Windows.
Device Guard components run in isolation from the Windows kernel and is secured by a Windows Hyper-V container called Virtual Secure Mode (VSM).
It is evident that Device Guard provides revolutionary endpoint security in Windows 10; a formidable opponent and offense against viruses, malware, bad actors and other modern day threats. Time to start taking advantage of it and securing the enterprise!!
[…]

Qualcomm QSEE

~ hucktech ~ Leave a comment

There are some interesting developments in Qualcomm’s Secure Execution Environment (QSEE).

https://twitter.com/daniel_bilar/status/724925150089633794
http://bits-please.blogspot.co.il/2016/05/war-of-worlds-hijacking-linux-kernel.html
http://bits-please.blogspot.com/2016/05/qsee-privilege-escalation-vulnerability.html

PLASMA: interactive disassembler generates pseudocode

~ hucktech ~ Leave a comment

There’s a new disassembler that looks like it has nice output:

PLASMA is an interactive disassembler. It can generate a more readable assembly (pseudo code) with colored syntax. You can write scripts with the available Python api. It supports :
*  architectures : x86, ARM, MIPS{64} (partially)
 *  formats : ELF, PE, RAW

https://github.com/joelpx/plasma

Linux UEFI updates for Linux 4.7

~ hucktech ~ Leave a comment

Matt Fleming has submitted some UEFI updates for Linux. Excerpted/edited announcement:

Folks, this is the second pull request containing v4.7 material. The commits are listed in priority order, with the first patch fixing an oops in the EFI capsule code sitting in tip/efi/core, and the rest being a compiler warning fix, static checker fix, and a couple of cleanups.

* efivarfs: Make efivarfs_file_ioctl static (2016-05-05 16:52:19 +0100)
* Fix an oops in the EFI capsule code reported by the 0day bot because efi_capsule_pending() was grabbing a mutex in the emergency reboot path
* Fix a compiler warning about excessive stack usage in the new efibc driver by kmalloc’ing the efivar_entry object
 * It’s potentially unsafe to pass the address of a pointer to the firmware in efi_capsule_supported(). Instead we can skip the dynamic allocation entirely and put the capsule object on the stack
* Simplify the locking in the efivars code by merging two of efivar_init()’s parameters into one
* Cleanup efivarfs_file_ioctl by marking it as static since it has no external users
* efibc: Fix excessive stack footprint warning
* efi: Merge boolean flag arguments
* efi/capsule: Make efi_capsule_pending() lockless
* efi/capsule: Move ‘capsule’ to the stack in efi_capsule_supported()
* efivarfs: Make efivarfs_file_ioctl static

For more information, see the message on the linux-efi mailing list archives:
http://vger.kernel.org/majordomo-info.html
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next

The UEFI Forum has a security advisory mechanism. They released 2 PDFs, each with a handful of advisories in the EDK2 codebase, back in 2015. There haven’t been any updates since 2015. If you want more recent updates on EDK2 source code, at least for the Linux codepath, watching these linux-efi updates is probably the most transparent way for non-members of the UEFI Forum. If you are a member of the UEFI Forum, I presume they have private forums and issue tracking systems to track non-public advisories. You can also watch the EDK2 commits for security patches, like any open source project.

EDK2 fork for LLVM security analysis

~ hucktech ~ Leave a comment

Steven Shi of Intel\SSG\STO\UEFI Firmware has created an LLVM Clang-centric fork of the EDK2 project. The EDK2 project already supports LLVM clang alongside GCC and ICC and MCS, but this fork appears to be taking advantage of some of LLVM’s security features, like Clang’s Static Analyzer, “special checkers for edk2 security” sounds interesting!

Hello,
I forked a edk2 branch to apply the LLVM compiler and tool chain technologies (http://www.llvm.org/) on the edk2 codebase in below link. If you are also interested in the LLVM/Clang support, please take a look. I welcome and appreciate any feedback or contribution to this branch.

https://github.com/shijunjing/edk2 branch llvm : https://github.com/shijunjing/edk2/tree/llvm

So far, this branch focus on below items:
* Clang compiler optimization for edk2 code size improvement, e.g. Link Time Optimization (LTO)
* Clang Static Analyzer (scan-build) for edk2, e.g. special checkers for edk2 security, checkers for Intel Firmware Engine automation

There are 4 new tool chains are introduced in branch llvm:
* CLANG38: Clang3.8.0 build tool chain, and enable code size optimization flag (-Os) by default on both Ia32 and X64.
* CLANGLTO38: Base on CLANG38 to enable LLVM Link Time Optimization (LTO) for more aggressive code size improvement.
* CLANGSCAN38: Base on CLANG38 to seamlessly integrate Clang scan-build analyzer infrastructure into edk2 build infrastructure.
* GCCLTO53: Enabled GCC Link Time Optimization (LTO) and code size optimization (-Os) for more aggressive code size improvement.

There are several known issues as below. WELCOME and APPRECIATE any suggestion to them:
* Not use gold linker for now, but directly use standard ld. GNU gold linker ld-new (GNU Binutils 2.26.20160125) 1.11 fails to link edk2 static library file (*.dll) with error message: “ld: internal error in do_layout, at ../../binutils-2.26/gold/object.cc:1819” Have submitted a bug in Bug 20062 – Gold2.26 fail to link Uefi firmware with internal error in do_layout, but ld works (https://sourceware.org/bugzilla/show_bug.cgi?id=20062)
* CLANG LTO optimization (on ld, not on gold) can generate incorrect code. Current CLANGLTO38 LTO X64 debug build will generate wrong code for BasePrintLib.inf and LzmaCustomDecompressLib.inf modules, and the Ovmf boot will hang in these two modules. Already add work around to disable the lto optimization in these two modules’ inf files. Please see the log of commit 6a55aa9c3fa58f275041bf8cda138643f04baf5c
* GCC LTO optimization can generate incorrect code. Current GCCLTO53 is even worse than CLANGLTO38, and there are more modules need to disable the LTO optimization to work around the CPU exceptions during boot time.

For more info, see the patch on the edk2-devel list:
https://github.com/shijunjing/edk2
https://github.com/shijunjing/edk2/tree/llvm
https://lists.01.org/mailman/listinfo/edk2-devel

I wonder if this project is related to the Intel LLVM KLEE/S2E static analysis project that they are hopefully going to open source this year?

Intel firmware security research at WOOT

I hope they take the handful of metrics that William’s LangToolUEFIZBIOS(sp) — his grad project — did. It’ll be a lot simpler as a LLVM filter, no need for all the Java ANTLR code!

Two UEFI Form tools, plus one UEFI C Module complexity tool

ASUS brick warning for Windows updates

~ hucktech ~ Leave a comment

Some ASUS users are having UEFI-related Windows update problems that may brick their systems. A few news sites have stories on this:

[…] KB3133977, a security update for Windows 7, has been identified as the cause for this problem. Following its installation, it forces Windows 7 to enable Secure Boot, even though it is actually not supported by Microsoft anymore. This eventually prevents the system from properly rebooting. Microsoft has clearly stated that it is in no way responsible for this predicament. Providing clarification, a company spokesperson stated that the problem occurs because of how Asus has created some of its motherboards with its own modified version of the Secure Boot feature. In other words, users facing problems in this regard will have to contact Asus directly to have the issue addressed. […]

http://tech.firstpost.com/news-analysis/a-microsoft-windows-7-update-is-bricking-some-pcs-with-asus-motherboards-313729.html
http://www.thecountrycaller.com/60295-microsoft-corporation-msft-windows-7-update-is-bricking-pcs/
http://www.pcper.com/news/General-Tech/Another-reason-not-use-UEFI-Secure-Boot

https://support.microsoft.com/en-us/kb/3133977

UEFI ported to RISC-V!

~ hucktech ~ 2 Comments

There’ve been a few presentations on porting UEFI to the RISC-V, but now there is public code! Abner Chang of HPE has submitted multiple patches with RISC-V support for various components of EDK-II.

[PATCH 0/3] *** EDK2 base tools support RISC-V processor***

EDK2 base tools support RISC-V arch. EDK2 build tool changes to generate RISC-V PE/Coff image from RISC-V ELF file, handle RISC-V relocations and generate EDK2 FW with RISC-V image machine type.

BaseTools: Support build RISC-V PE/Coff image.
 
The changes on BaseTools is for building RISC-V ELF image and PE/Coff Image. Also to generate FW and FV for RISC-V arch.     

[PATCH 0/2] *** EDK2 MDE for RISC-V processor ***

MdePkg: MDE implementations for RISC-V arch. The implementations of RISC-V MDE base libraries.

    Add RISC-V architecture image file machine code.
    Add RISC-V architecture relocation type.    
    Add RISC-V architecture context buffer.
    Add RISC-V architecture exception types.
    Add RISC-V architecture PXE tag definition.    
    Add RISC-V architecture EFI image machine type.
    Add RISC-V architecture removable media boot path.
    Add RISC-V architecture processor binding.
    
[PATCH] OvmfPkg/PciHostBridgeDxe: [RISC-V] Add back OVMF PciHostBridge module.

Use OVMF PCI host bridge driver as the RISC-V platform BUS.
This driver is used by RISC-V Virtualization package (RiscVVirtPkg).
Currently the platfrom spec for RISC-V is not yet ready, thus we use PCI host bridge in temporarily.

[PATCH] RiscVVirtPkg: RISC-V QEMU package.

This is RISC-V QEMU package. The image which built from this package can be launched on QEMU RISC-V port (not official QEMU). RiscVVirtPkg utilizes below modules from EDK2 OVMF package,
 – PciHostBridge DXE driver.
   Use PCI host bridge driver as RISC-V platform bus spec for adopting PC/AT components.
 – QemuFwCfgLib
   QEMU firmware configuration.
 – OVMF ACPI timer lib.
 – QemuFlashFvbServicesRuntimeDxe
 – QemuVideoDxe
 – XenIoPciDxe

[PATCH] RiscVPkg: RISC-V processor package.

 New processor package added to EDK2 open source for RISC-V.
 
[PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.

The implementation of RISC-V DxeIpl.

This is only the first round of these multiple patches, given initial discussion it is likely there will be another round. In the discussion for this patch, it appears there is more support upcoming, not yet public. In the thread, Abner mentioned:

“The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for review. I have been told to upstream RISC-V code first and then submit the spec. I will confirm this again.”

I am looking forward to seeing what happens with the RISC-V UEFI port, and seeing some consumer devices based on RISC-V!

For more info, see the various threads on the EDK2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

Debian drops Intel 486/586 support for i386 target

~ hucktech ~ Leave a comment

Ben Hutchings announced a policy change at Debian, i386 must now be 686-class processors:

Debian i386 architecture now requires a 686-class processor:

Last year it was decided to increase the minimum CPU features for the i386 architecture to 686-class in the stretch release cycle.  This means dropping support for 586-class and hybrid 586/686processors.(Support for 486-class processors was dropped, somewhat accidentally, in squeeze.) This was implemented in the Linux kernel packages starting with Linux 4.3, which was uploaded to unstable in December last year. In case you missed that change, gcc for i386 has recently been changed to target 686-class processors and is generating code that will crash on other processors.  Any such systems still running testing or unstable will need to be switched to run stable (jessie). The older processors will continue to be supported in jessie until at least 2018, and until 2020 if i386 is included in jessie LTS.

[1] The following processors, supported in jessie, are now unspported:

* AMD K5, K6, K6-2 (aka K6 3D), K6-3
* DM&P/SiS Vortex86, Vortex86SX
* Cyrix III, MediaGX, MediaGXm
* IDT Winchip C6, Winchip 2
* Intel Pentium, Pentium with MMX
* Rise mP6
* VIA C3 ‘Samuel 2’, C3 ‘Ezra’

True, this is not firmware-centric, but Debian is pretty upstream when it comes to embedded Linux systems…

For more info, see the full post on the debian-devel-announce list:

https://lists.debian.org/msgid-search/1462623810.19332.46.camel@decadent.org.uk

NIST SP 800-160 Draft 2 released

~ hucktech ~ Leave a comment

Greg Otto has a new story on FedScoop about NIST and IoT security, with NIST’s 2nd edition of SP 800-160:

“This one is unique, it is special because it addresses the fundamental things that they need to do to build security into these systems from the start,” said NIST Fellow Ron Ross in an interview with FedScoop at the Public Sector Innovation Summit. “It’s a different approach. It doesn’t come at the security from the bottom-up, it comes at it from the top down. That’s the number one priority because if we do that right, everything else falls into place.”

There are MANY references to firmware in this spec!! Public comment period for this spec is now through July, so PLEASE send them firmware-centric feedback!

Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems
NIST Special Publication 800-160
Second Public Draft
May 2016
Public comment period: May 4 through July 1, 2016

This publication addresses the engineering-driven actions necessary to develop more defensible and survivable systems—including the components that compose and the services that depend on those systems. It starts with and builds upon a set of well-established International Standards for systems and software engineering published by the ISO, the IEC, and the IEEE and infuses systems security engineering techniques, methods, and practices into those systems and software engineering processes. The ultimate objective is to address security issues from a stakeholder requirements and protection needs perspective and to use established engineering processes to ensure that such requirements and needs are addressed with appropriate fidelity and rigor, early and in a sustainable manner throughout the life cycle of the system.

http://csrc.nist.gov/publications/PubsSPs.html
http://www.nist.gov/itl/csd/building-security-into-cyber-physical-systems-nist-researchers-suggest-approach-for-trustworthy-modern-infrastructure.cfm

NIST pushing holistic cybersecurity process for IoT

Matt Turck: landscape of IoT

~ hucktech ~ Leave a comment

Matt has written a very good article on the business side of IoT, showcasing the vendors creating IoT devices.

Great article from an investor perspective (so no coverage of open source unless there’s a startup backing it).  In addition to fancy infographic PDF with dozens of corporate logos/icons, they also have an interactive web site that is basically an HTML table spreadsheet version of that data, with a search ability (try searching for ‘security’ to see the IoT security vendors on this landscape.

I only wish Matt had focused a bit on security. 😦 It would be a great indicator for investors, perhaps tracking Internet Of Shit’s twitter feed references to a startup’s product would be another indicator? 🙂

Internet of Things: Are We There Yet? (The 2016 IoT Landscape)

http://dfkoz.com/iot-landscape/

Anders Fogh’s Rowhammer summary

~ hucktech ~ Leave a comment

Anders Fogh has a new blog post with a concise summary of Rowhammer:

Row hammer the short summary: I resonantly realized how much stuff was published on the row hammer and how much I was missing a short summary. So I wrote one and you are now reading the result. The summary is moderately technical and is kept short with intend. I may or may not update this post – but please let me know if you think I missed something important. There will be no new results here. Short version of how dram works. […]

Full post:

http://dreamsofastone.blogspot.de/2016/05/row-hammer-short-summary.html

List of UEFI vendors who care about security

~ hucktech ~ Leave a comment

Which UEFI vendors care — or at least may care — about security? The list (alphabetically) is shorter than you might expect:

AMD
AMI
Apple
Dell
Hewlett Packard Enterprises
HP Inc.
Insyde Software
Intel Corp.
Lenovo
Microsoft
Phoenix Technologies

Nobody else. If your vendor is not listed above, ask them why you should purchase a UEFI-based system from them.

The above list is from the list of vendors who have feedback mechanisms listed on the UEFI Forum’s security contact page.

http://uefi.org/security

Intro to Intel SGX Sealing

~ hucktech ~ Leave a comment

https://twitter.com/intelswfeed/status/727993359516745729

Alexander B. of Intel has written a blog post describing the Sealing abilities of Intel SGX:

Introduction to Intel® SGX Sealing:
This post is intended to introduce developers to the Sealing capability available on SGX enabled platforms. Sealing is the process of encrypting enclave secrets for persistent storage to disk. This allows secrets to be retrieved if the enclave is torn down (either due to power event or by the application itself), and subsequently brought back up. Encryption is performed using a private Seal Key that is unique to that particular platform and enclave, and is unknown to any other entity. […] For a more detailed treatment of SGX sealing capabilities, refer to the following documents: […]

Full post:
https://software.intel.com/en-us/blogs/2016/05/04/introduction-to-intel-sgx-sealing
https://software.intel.com/en-us/sgx

 

ARM System Validation process

~ hucktech ~ Leave a comment

Eoin McCann of ARM has a new blog post on the topic of system validation that gives an introduction to how ARM enables this for it’s partners.

System Validation at ARM: Enabling our Partners to Build Better Systems
[…] SoCs have evolved into complex entities that integrate several diverse units of intellectual property (IP). A modern SoC may include several components such as CPUs, GPU, interconnect, memory controller, System MMU, interrupt controller etc. The IPs themselves are complex units of design that are verified individually. Yet, despite rigorous IP-level verification, it is not possible to detect all bugs – especially those that are sensitized only when the IPs interact within a system. This article intends to give you some behind-the-scenes insight into the system validation work done at ARM to enable a wide range of applications for our IP. Many SoC design teams attempt to solve the verification problem individually using a mix of homegrown and commercially available tools and methods. The goal of system validation at ARM is to provide partners with high quality IP that have been verified to interoperate correctly. This provides a standardized foundation upon which partners are able to build their own system validation SOC solutions. Starting from a strong position, their design and verification efforts can be directed more at the design differentiation they add to the SoC and its interactions with the rest of the system. […]

Full blog post:
https://community.arm.com/groups/processors/blog/2016/04/05/system-validation-at-arm-enabling-our-partners-to-build-better-systems

PS: Re: the last few sentences in the above expert, I am still trying to find the ARM equivalent of Intel CHIPSEC. And/or waiting for Linaro to finish porting LUV (which includes CHIPSEC) to ARM (but hoping they’ll also target AArch32 not only AArch64, both targets need firmware security validation tools, not just the ones they’re banking the most on). ARM is more complex than current Intel CHIPSEC situation, each ARM IP licensee will need to write a handful of new ARM-flavored CHIPSEC security tests, to deal with the nuances of their system. Is there even an ARM security team, whose charter might include a CHIPSEC port?

 

FWTS gains IPMI BMC Info tool

~ hucktech ~ Leave a comment

Deb McLemore of IBM has submitted a BMC Info, new IPMI tool to FirmWare Test Suite (FWTS).

Introduce IPMI BMC Info

This feature adds the foundation to perform an IPMI BMC Info check that will determine if a Host is capable of IPMI messaging and if so will perform a basic IPMI message exchange to determine the version of IPMI running on the hardware.  In the future the IPMI infrastructure can be used to further interrogate the FRU Inventory and other Sensors to help correlate data and surface any discrepancies on inventory or hardware characteristics.

For more information, see the patch sent to the fwts-devel mailing list:
https://lists.ubuntu.com/mailman/listinfo/fwts-devel

PXE boot support added to U-Boot’s EFI payload

~ hucktech ~ Leave a comment

Alexander Graf of SuSE has submitted a new patch to his EFI payload for U-Boot, adding PXE boot support!

[PATCH 0/4] efi_loader: PXE boot support

One of the most common boot cases with EFI on arm64 is to boot from the network using PXE boot. While TianoCore implements that just fine, we were lacking support for it in U-Boot so far. But no longer! Here is a patch set, enabling PXE booting of EFI payloads. With this patch set, I was successfully able to automatically boot our normal (usually used with TianoCore based systems) environment to boot and run grub2 and a kernel from there with U-Boot.

* efi_loader: Add network access support
* bootp: Move vendor class identifier set to function
* net: Move the VCI and client arch values to Kconfig
* distro: Add efi pxe boot code

For more information, see the U-Boot list:
http://lists.denx.de/mailman/listinfo/u-boot