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!

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?
https://firmwaresecurity.com/2015/08/10/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!
https://firmwaresecurity.com/2015/07/07/two-uefi-form-tools-plus-one-uefi-c-module-complexity-tool/

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s