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.
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.
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!
Tristan Ravitch has a nice tool on github called Whole Program LLVM, or WWLVM (Whole Library LLVM), and talks about it in a recent blog post, using it to find defects in libOTR. From the github readme:
“WLLVM provides tools for building whole-program (or whole-library) LLVM bitcode files from an unmodified C or C++ source package. It currently runs on *nix platforms such as Linux, FreeBSD, and Mac OS X. WLLVM provides python-based compiler wrappers that work in two steps. The wrappers first invoke the compiler as normal. Then, for each object file, they call a bitcode compiler to produce LLVM bitcode. The wrappers also store the location of the generated bitcode file in a dedicated section of the object file. When object files are linked together, the contents of the dedicated sections are concatenated (so we don’t lose the locations of any of the constituent bitcode files). After the build completes, one can use an WLLVM utility to read the contents of the dedicated section and link all of the bitcode into a single whole-program bitcode file. This utility works for both executable and native libraries. Currently, WLLVM works with either clang or the gcc dragonegg plugin. This two-phase build process is necessary to be a drop-in replacement for gcc or g++ in any build system. Using the LTO framework in gcc and the gold linker plugin works in many cases, but fails in the presence of static libraries in builds. WLLVM’s approach has the distinct advantage of generating working binaries, in case some part of a build process requires that. […]”
This project is not new, I just noticed it. 🙂 It isn’t Avatar/S2E, but it also interesting. I wonder if anyone is using this to test virtualized versions of coreboot, U-Boot, UEFI, SeaBIOS, and other firmware code?
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.
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.
Frederic Jacobs has an excellent discussion on Apple’s new Bitcode opcodes that is helping make applications more architecture-independent …including some security implications of shipping a machine-independent copy of your code for attackers to exploit.
Last week Damien DeVille posted a long article on how to use VMware Fusion with LLDB to do remote kenel debugging, on a Mac system: