Tag: clang

C Compiler Warnings

~ hucktech ~ Leave a comment

Spoiler alert:

[…]All the flags presented so far can be combined into the following list, provided below for copy-pasting purposes :
-Wall -Wextra -Wcast-qual -Wcast-align -Wstrict-aliasing -Wpointer-arith -Winit-self -Wshadow -Wswitch-enum -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wfloat-equal -Wundef -Wvla -Wdeclaration-after-statement -Wc++-compat

https://fastcompression.blogspot.com/2019/01/compiler-warnings.html

clang: Automatic variable initialization

~ hucktech ~ Leave a comment

Automatic variable initialization: Add an option to initialize automatic variables with either a pattern or with zeroes. The default is still that automatic variables are uninitialized. Also add attributes to request uninitialized on a per-variable basis, mainly to disable initialization of large stack arrays when deemed too expensive.[…]

https://reviews.llvm.org/rL349442

LLVM 7.0.0 released

~ hucktech ~ Leave a comment

[…]It is the result of the community’s work over the past six months, including: function multiversioning in Clang with the ‘target’ attribute for ELF-based x86/x86_64 targets, improved PCH support in clang-cl, preliminary DWARF v5 support, basic support for OpenMP 4.5 offloading to NVPTX, OpenCL C++ support, MSan, X-Ray and libFuzzer support for FreeBSD, early UBSan, X-Ray and libFuzzer support for OpenBSD, UBSan checks for implicit conversions, many long-tail compatibility issues fixed in lld which is now production ready for ELF, COFF and MinGW, new tools llvm-exegesis, llvm-mca and diagtool. And as usual, many optimizations, improved diagnostics, and bug fixes.[…]

Some highlights:

Early support for UBsan, X-Ray instrumentation and libFuzzer (x86 and x86_64) for OpenBSD. Support for MSan (x86_64), X-Ray instrumentation and libFuzzer (x86 and x86_64) for FreeBSD.

AArch64 target: Assembler and disassembler support for the ARM Scalable Vector Extension has been added.

A new Implicit Conversion Sanitizer (-fsanitize=implicit-conversion) group was added. Please refer to the Undefined Behavior Sanitizer (UBSan) section of the release notes for the details.

An existing tool named diagtool has been added to the release. As the name suggests, it helps with dealing with diagnostics in clang, such as finding out the warning hierarchy, and which of them are enabled by default or for a particular compiler invocation.

clang-tidy: New module zircon for checks related to Fuchsia’s Zircon kernel.

The DEBUG macro has been renamed to LLVM_DEBUG, the interface remains the same.

A new tool named llvm-mca has been added. llvm-mca is a static performance analysis tool that uses information available in LLVM to statically predict the performance of machine code for a specific CPU.

http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html
http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html
http://releases.llvm.org/7.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html
http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html
http://lists.llvm.org/pipermail/llvm-announce/2018-September/000080.html

LLVM: Introduce a new pass to do Speculative Load Hardening (SLH) to mitigate Spectre variant 1

~ hucktech ~ Leave a comment

A new speculative load hardening pass was added for X86, aiming to mitigate Spectre variant #1

http://llvmweekly.org/issue/237

https://reviews.llvm.org/rL336990

 

LLVM: Speculative Load Hardening (a Spectre variant #1 mitigation)

~ hucktech ~ Leave a comment

http://lists.llvm.org/pipermail/llvm-dev/2018-March/122085.html

 

LLVM 6.0.0 Released, includuing Spectre variant2 mitigations

~ hucktech ~ Leave a comment

This release is the result of the community’s work over the past six months, including: retpoline Spectre variant 2 mitigation, significantly improved CodeView debug info for Windows, GlobalISel by default for AArch64 at -O0, improved scheduling on several x86 micro-architectures, Clang defaults to -std=gnu++14 instead of -std=gnu++98, support for some upcoming C++2a features, improved optimizations, new compiler warnings, many bug fixes, and more.

https://llvm.org/releases/download.html#6.0.0
https://llvm.org/releases/6.0.0/docs/ReleaseNotes.html
https://llvm.org/releases/6.0.0/tools/clang/docs/ReleaseNotes.html
https://llvm.org/releases/6.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html
https://llvm.org/releases/6.0.0/tools/lld/docs/ReleaseNotes.html
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-announce

LLVM 5.0.0 released

~ hucktech ~ Leave a comment

Lots of changes for Intel/AMD/ARM/MIPS/PowerPC, eg AMD Rhyzen support. And new PDB tool. Clang has new diagnostic/”lint” abilities. The static analyzer uses Microsoft’s Z3 solver. New C and C++ features (wow, C++ is at C++17 already!). Many other changes! I wish I had time to look at it more detail today… 😦

http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html
http://releases.llvm.org/5.0.0/tools/clang/docs/ReleaseNotes.html
http://releases.llvm.org/5.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html

http://lists.llvm.org/pipermail/llvm-announce/2017-September/000075.html

https://en.wikipedia.org/wiki/C%2B%2B17

LLVM can now emit/parse/diff Windows PDBs

~ hucktech ~ Leave a comment

PDBs are the sidecar symbol files for Windows. The spec used to be private, now is public, and now it is great to see Clang supporting them. Last time I looked, GCC does not support them.

http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html

ARM updates C/C++ compilers

~ hucktech ~ Leave a comment

ARM has updated it’s C/C++ compiler toolchains.

C and C++ update for Arm Compiler 6:
As you are hopefully aware, Arm Compiler 6 has been available for 3+ years now, and has grown in maturity, and optimization quality release on release. As I write this, the latest available version is 6.8, and 6.6 has been qualified for use in safety-related development. We offer full support for the latest Arm processors, across the Cortex-A, R, and M, and SecureCore families. Arm Compiler 6 is available within DS-5 and Keil MDK toolchains. Furthermore the qualified version is available for purchase stand-alone. Arm Compiler 6 is based on the LLVM framework, using the modern Clang compiler front-end, and this is reflected in the name of the executable, Armclang. The compiler is then integrated into the full Arm tools suite, enabling use of legacy assembler code built with Armasm, as well as gas format assembler directly with Armclang. Finally the Arm linker (Armlink) brings in the optimized C and C++ libraries, or if desired the size optimized Arm C MicroLib library, as well as (optionally) implementing link-time optimizations across the source code.[…]

https://community.arm.com/tools/b/blog/posts/c-and-cpp-update-for-arm-compiler-6
https://developer.arm.com/products/software-development-tools/compilers/Arm-compiler

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?
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/

Clang static analysis of firmware sources

~ hucktech ~ Leave a comment

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.
[…]

http://allsoftwaresucks.blogspot.ru/2016/02/noted-on-firmware-and-tools.html

Clang hardening

~ hucktech ~ Leave a comment

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.

http://blog.quarkslab.com/clang-hardening-cheat-sheet.html

Android deprecates GCC, switch to Clang

~ hucktech ~ Leave a comment

From the Android NDK Changelog for NDK Build 2490520:

Clang:
    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:
    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.

https://android.googlesource.com/platform/ndk.git/+/master/CHANGELOG.md

 

EBC

~ hucktech ~ Leave a comment

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.
http://vzimmer.blogspot.com/2015/08/efi-byte-code.html

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!!
http://www.capstone-engine.org/

Today, radare2, another RE tool, already has EBC support.
https://firmwaresecurity.com/2015/07/26/tool-mini-review-radare2/

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:
http://people.linaro.org/~christoffer.dall/arm-vm-spec-v1.0.txt

Also, there’s a C#/IL to EBC translation project on Github. If you get it to work, let me know!
https://github.com/nnliaohua/CIL2EBC-ToolChain

ARM update on GCC and Clang compilers

~ hucktech ~ Leave a comment

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:
http://community.arm.com/groups/tools/blog/2015/06/30/open-source-toolchains–arm-status-update-q2-2015