EDK2 fork for LLVM security analysis

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!

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:

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?

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!


Clang static analysis of firmware sources

Last month Alexander Tarasikov wrote a blog post on Clang static analyzers and firmware, ranging from UEFI to U-Boot and other technologies:

In this blog post I mainly want to summarize my latest experiments at using clang’s static analyzer and some thoughts on what could be further done at the analyzer, and open-source software quality in general. It’s mostly some notes I’ve decided to put up.
In one of my previous posts I have drawn attention to gathering code coverage in low-level software, such as bootloaders. With GCOV being quite easy to port, I think more projects should be exposed to it. Also, AddressSanitizer now comes with a custom infrastructure for gathering code coverage, which is more extensive than GCOV.



Clang hardening

While improving the documentation (d’oh!) of our home grew obfuscator based on LLVM, we wrote a cheat sheet on clang’s hardening features, and some of ld ones. It turns out existing hardening guides generally focus on GCC, while Clang also has an interesting set of hardening features. So let’s share it in this blog post!
Note0: Everything in this post is based on Clang/LLVM 3.7
Note1: Debian provides a very interesting hardening guide here: https://wiki.debian.org/Hardening
Note2: This post does not cover the use of Asan. Unlike the options presented here, it’s unlikely to go into release build, rather in debug builds.



Android deprecates GCC, switch to Clang

From the Android NDK Changelog for NDK Build 2490520:

    PSA: Everyone should be switching to Clang.
    Clang has been updated to 3.8svn (r243773, build 2481030).
        Note that this is now a nearly pure upstream clang.
        Also note that Clang packaged in the Windows 64 NDK is actually 32-bit.
    Support for emulated TLS.
        __thread is now supported by the compiler by emulating ELF TLS with pthread thread-specific data.
        C++11 thread_local will work in some cases, but will not work for data with non-trivial destructors except when running on Marshmallow (android-23) or newer because those cases require support from libc.
        Does not yet work with Aarch64 when TLS variables are accessed from a shared library.

    GCC in the NDK is now deprecated.
        Time to start using Clang if you haven’t already. If you have problems with Clang, please file bugs!
        The NDK will not be upgrading to 5.x, nor will we be accepting non-critical backports.
        Maintenance for miscompiles and internal compiler errors in 4.9 will be handled on a case by case basis.
    GCC 4.8 has been removed. All targets now use GCC 4.9.





EBC, The EFI Byte Code, is a UEFI feature that supports Intel (Itanium, x86, and x64) instructions in a single bytecode. The Intel C Compiler can target EBC, and UEFI drivers can use EBC instead of native drivers, to save space (1 binary, instead of 3).

The other week I gave a firmware security tools talk at BlackLodgeResearch.org, and Vincent Zimmer of Intel showed up. I had a slide complaining that EBC is only supported by Intel C Compiler, a commercial-only product, and that the UEFI Forum should fund a ‘summer-of-code’-style effort to get EBC into GCC or LLVM CLang. After the talk, Vincent mentioned that ICC had to do a bit of unexpected work to generate EBC, and would blog about it. Well, he did blog about it, a few days ago, just catching up to it, and describe the problem.

If you know of someone on the LLVM CLang or GCC project, please try to add a request for EBC support.

Not only would it be nice to have LLVM CLang work with EBC to have an alternative to ICC, and for LLBVM’s Klee fuzzer (to fuzz UEFI via OVMF), but ALSO because the Capstone Framework RE tool uses LLVM’s intermediate form and would then get EBC support!!

Today, radare2, another RE tool, already has EBC support.

If technically possible, it might be nice if ARM added AArch32 and AArch64 support, and EBC support in their compiler, so that EBC could actually target all UEFI platforms with a single blob. ARM/Linaro already has something that appears to overlap in some ways:

Also, there’s a C#/IL to EBC translation project on Github. If you get it to work, let me know!


ARM update on GCC and Clang compilers

A few days ago, the ARM Software Dev Tools blog posted their 2015Q2 update on their use of Open Source Toolchains. The post talks about ARM changes in GNU GCC as well as LLVM. It appears they’re getting ready to present at GNU Cauldron in August. Look at their blog for more information. They’ve got some YouTube video and presentation slides, as well.

One thing this blog post clarified to me was what codebase ARM’s C compiler was based on: LLVM Clang:

“The commercial toolchain we offer to our customers, ARM Compiler 6, is in fact based on open source clang.”

More Information: