C Compiler Warnings

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


hardware-effects: Demonstration of various hardware effects in C++

This repository demonstrates various hardware effects that can degrade application performance in surprising ways and that may be very hard to explain without knowledge of the low-level CPU and OS architecture. For each effect I try to create a proof of concept program that is as small as possible so that it can be understood easily.

Those effects obviously depend heavily on your CPU microarchitecture and model, so the demonstration programs may not showcase the slowdown on your CPU, but I try to make them as general as I can. That said, the examples are targeting x86-x64 processors (Intel and AMD) and may not make sense on other CPU architectures. I try to make them compatible with Windows, but they are mainly tested on Linux.

Currently the following effects are demonstrated:

bandwidth saturation
branch misprediction
branch target misprediction
cache aliasing
cache/memory hierarchy bandwidth
data dependencies
denormal floating point numbers
false sharing
hardware prefetching
memory-bound program
non-temporal stores
software prefetching
write combining


Conan for UEFI??

An open source, secure, vendor-neutral, pre-OS packaging tool for updating platform microcode and firmware might be interesting. So when I saw this UEFI test app:


it was interesting to note that it includes some support for the Conan C/C++ packaging tool for UEFI, eg:


I’ve no time today to study it closely, so I’m unsure if it is using conan as an OS-present tool, or it has conan running as a pre-OS UEFI app. Big difference! 🙂

Conan is a C/C++ packaging tool. The official docs don’t mention UEFI support:

Conan can be installed in many Operating Systems. It has been extensively used and tested in Windows, Linux (different distros), OSX, and is also actively used in FreeBSD and Solaris SunOS. There are also several additional operating systems on which it has been reported to work. […] Conan works and is being actively used on Windows, Linux (Ubuntu, Debian, RedHat, ArchLinux, Raspbian), OSX, FreeBSD, and SunOS, and, as it is portable, it might work in any other platform that can run python. In the documentation, examples for a specific OS might be found, such as conan install . -s compiler=”Visual Studio”, which will be specific for Windows users. If on a different system, the reader should adapt to their own platform and settings (for example conan install . -s compiler=gcc). […] Also conan works with any build system. In the documentation, CMake will be widely used, because it is portable and well known. But conan does not depend on CMake at all; it is not a requirement. Conan is totally orthogonal to the build system. There are some utilities that improve the usage of popular build systems such as CMake or Autotools, but they are just helpers. Furthermore, it is not necessary that all the packages are built with the same build system. It is possible to depend on packages created with other build system than the one you are using to build your project.


PS: Above project uses CMake, and Conan supports CMake. And there’s also this CMake/UEFI project, but appears to not be native UEFI use of CMake:


c2rust.com: C to Rust translator

Re: https://firmwaresecurity.com/2017/04/08/corrode-rust-to-c-translator/

There’s another C to Rust translator:



Microsoft: C++ Developer Guidance for Speculative Execution Side Channels

C++ Developer Guidance for Speculative Execution Side Channels
Matt Miller Colin Robertson Mike B

This article contains guidance for developers to assist with identifying and mitigating speculative execution side channel hardware vulnerabilities in C++ software. These vulnerabilities can disclose sensitive information across trust boundaries and can affect software that runs on processors that support speculative, out-of-order execution of instructions. This class of vulnerabilities was first described in January, 2018 and additional background and guidance can be found in Microsoft’s security advisory. The guidance provided by this article is related to the class of vulnerabilities represented by CVE-2017-5753, also known as Spectre variant 1. This hardware vulnerability class is related to side channels that can arise due to speculative execution that occurs as a result of a conditional branch misprediction. The Visual C++ compiler in Visual Studio 2017 (starting with version 15.5.5) includes support for the /Qspectre switch provides a compile-time mitigation for a limited set of potentially vulnerable coding patterns related to CVE-2017-5753. The documentation for the /Qspectre flag provides more information on its effects and usage.[…]


[…]An accessible introduction to speculative execution side channel vulnerabilities can be found in the presentation titled The Case of Spectre and Meltdown by one of the research teams that discovered these issues.[…]


Torito C Library

Joaquin Cono Bolillo has created the Torito C Library, a Standard C Library for UEFI x86-64 target platform for Microsoft Visual Studio 2017.

“torito C Library” is an implementation targeting the ANSI/ISO C Standard Library compatibility to create applications for different operating systems using design –and debug– infrastructure provided by Microsoft Visual Studio 2017 VS2017.

Goal: The “torito C Library” is designed to enable the developer to create Standard C programs for UEFI Shell, Windows NT and Linux (in future releases) running in x86-64 mode. Standard C compliant source code shall be easily portable to operating systems supported by “torito C Library”.

The “torito C Library” shall provide full library compatibility with: ANSI X3.159-1989 (“ANSI C”),  ISO/IEC 9899 First edition 1990-12-15 (“C90”),  ISO/IEC 9899 First edition 1990-12-15, Amendment 1, 1995-04-01 (“C95”)

The “torito C Library” is still in state of EVALUATION
Field tests are urgently required.
Feedback is very WELCOME.
A non-EVALUATION-library will be provided for helpful supporters for free.
The functions below are already implemented and carefully tested, every single one of them:

_ModuleEntryPoint, _iob, _setjmp, _snprintf, _vsnprintf, abs, asctime, atexit, atoi, atol, calloc, clearerr, clock, ctime, difftime, div, exit, fclose, feof, ferror, fflush, fgetc, fgetpos, fgets, fopen, fprintf, fputc, fputs, fread, free, freopen, fscanf, fseek, fsetpos, ftell, fwrite, gets, gmtime, isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, isxdigit, labs, ldiv, localtime, longjmp, main(argc, argv), malloc, memcmp, memcpy, memmove, memset, mktime, nprintf, perror, printf, putc, putchar, puts, rand, realloc, rewind, scanf, setbuf, setvbuf, snprintf, sprintf, srand, sscanf, strcat, strchr, strcmp, strcpy, strcspn, strefierror, strerror, strftime, strlen, strncat, strncmp, strncpy, strpbrk, strspn, strstr, strtok, strtol, strtoul, swprintf, time, tolower, toupper, ungetc, vfprintf, vfscanf, vprintf, vscanf, vsnprintf, vsprintf, vswprintf, wcscat, wcschr, wcscmp, wcscpy, wcscspn, wcslen, wcsncat, wcsncmp, wcsncpy, wcspbrk, wcsrchr, wcsspn, wcsstr, wcstok, wmemcmp, wmemcpy, wmemmove, wprintf.


Corrode: Rust to C translator

I wish UEFI Forum had bindings to languages other than C, such as Rust, which has multiple community implementations.

I also wish there was a Rust-to-C project for Tianocore. 😉





CPP-UEFI-Wrapper is a new project to create a C++ wrapper for C-centric UEFI. It is just getting started, not yet ready for use.


C++ UEFI Wrapper:
This project is a C++ wrapper for the UEFI specification, intended for people who write UEFI applications (OS loaders, shells, etc.) The project is composed of two parts, 1) The low-level wrapper, that uses structs and pointers to directly implement the UEFI specification. and 2) The high-level, object-oriented wrapper, that uses classes to represent various UEFI protocols. Features:
* Uses modern C++14 features (constexpr, static_assert, strongly typed enums).
* Mainly intended for UEFI applications, not UEFI drivers or firmwares.
* Relies on some C/C++ headers, but does not require a hosted standard library (obviously).