In our previous article about Stack Clash, we covered the basics of the Stack Clash vulnerability. To summarize, an attacker first uses various means to bring the heap and stack close together. A large stack allocation is then used to “jump the stack guard.” Subsequent stores into the stack may modify objects in the heap or vice versa. This, in turn, can be used by attackers to gain control over applications.
GCC has a capability (
-fstack-check), which looked promising for mitigating Stack Clash attacks. This article will cover how
-fstack-check works and why it is insufficient for mitigating Stack Clash attacks.
Continue reading “Stack Clash mitigation in GCC: Why -fstack-check is not the answer”
The Linux perf tool was originally written to allow access to the performance monitoring hardware that counts hardware events, such as instructions executed, processor cycles, and cache misses. However, it can also be used to count software events, which can be useful in gauging how frequently some part of the system software is executed.
Recently someone at Red Hat asked whether there was a way to get a count of system calls being executed on the system. The kernel has a predefined software trace point,
raw_syscalls:sys_enter, which collects that exact information; it counts each time a system call is made. To use the trace point events, the
perf command needs to be run as root.
Continue reading “How to use the Linux perf tool to count software events”
Several months ago, I took over the maintenance of the flex package in Fedora and decided to kick the tires by rebasing the package in Fedora Rawhide. I downloaded and hashed the latest tarball at the time, flex-2.6.4, tweaked the spec file, and fired up a local build. Unfortunately, it failed with a
SIGSEGV at build time:
./stage1flex -o stage1scan.c ./scan.l
make: *** [Makefile:1695: stage1scan.c] Segmentation fault (core dumped)
Some debugging with gdb led me to the conclusion that the segmentation fault was the result of a block of memory returned from the
reallocarray function being written to during flex initialization. In this article, I’ll describe the issue further and explain changes made to address it.
Continue reading “Implicit function declarations: flex’s use of “reallocarray””
Red Hat Developer Toolset augments Red Hat Enterprise Linux with the latest, stable versions of GCC that install alongside the original base version. This version of Red Hat Developer Toolset 8.1 Beta includes the following new components:
- GCC 8.2.1
- GDB 8.2
- binutils 2.30
- elfutils 0.176
- Valgrind 3.14.0
This Beta release is supported on Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 for AMD64 and Intel 64 architectures. It also supports the following architectures on Red Hat Enterprise Linux 7: 64-bit ARM, big- and little-endian variants of IBM POWER (), and IBM Z. See below for more information about each updated component.
Continue reading “Red Hat Developer Toolset 8.1 Beta now available”
One of the most important concepts introduced in C++11 was move semantics. Move semantics is a way to avoid expensive deep copy operations and replace them with cheaper move operations. Essentially, you can think of it as turning a deep copy into a shallow copy.
Move semantics came along with several more or less related features, such as rvalue references, xvalues, forwarding references, perfect forwarding, and so on. The standard C++ library gained a function template called
std::move, which, despite its name, does not move anything.
std::move merely casts its argument to an rvalue reference to allow moving it, but doesn’t guarantee a move operation. For example, we can write a more effective version of
void swap(T& a, T& b)
T t(std::move (a));
a = std::move (b);
b = std::move (t);
This version of swap consists of one move construction and two move assignments and does not involve any deep copies. All is well. However,
std::move must be used judiciously; using it blithely may lead to performance degradation, or simply be redundant, affecting readability of the code. Fortunately, the compiler can sometimes help with finding such wrong uses of
std::move. In this article, I will introduce two new warnings I’ve implemented for GCC 9 that deal with incorrect usage of
Continue reading “Understanding when not to std::move in C++”
A new version of the OpenMP standard, 5.0, was released in November 2018 and brings several new constructs to the users. OpenMP is an API consisting of compiler directives and library routines for high-level parallelism in C, C++, and Fortran programs. The upcoming version of GCC adds support for some parts of this newest version of the standard.
This article highlights some of the latest features, changes, and “gotchas” to look for in the OpenMP standard.
Continue reading “What’s new in OpenMP 5.0”
As part of the GCC developers‘ on-demand range work for GCC 10, I’ve been playing with improving the backward jump threader so it can thread paths that are range-dependent. This, in turn, had me looking at the jump threader, which is a part of the compiler I’ve been carefully avoiding for years. If, like me, you’re curious about compiler optimizations, but are jump-threading-agnostic, perhaps you’ll be interested in this short introduction.
Continue reading “A gentle introduction to jump threading optimizations”
In part 1, I shed light on trade-offs involved in the GCC implementation choices for various types of front-end warnings, such as preprocessor warnings, lexical warnings, type-safety warnings, and other warnings.
As useful as front-end warnings are, those based on the flow of control or data through the program have rather inconvenient limitations. To overcome them, flow-based warnings have increasingly been implemented in what GCC calls the “middle end.” Middle-end warnings are the focus of this article.
Continue reading “Understanding GCC warnings, Part 2”
Most of us appreciate when our compiler lets us know we made a mistake. Finding coding errors early lets us correct them before they embarrass us in a code review or, worse, turn into bugs that impact our customers. Besides the compulsory errors, many projects enable additional diagnostics by using the
-Wextra command-line options. For this reason, some projects even turn them into errors via
-Werror as their first line of defense. But not every instance of a warning necessarily means the code is buggy. Conversely, the absence of warnings for a piece of code is no guarantee that there are no bugs lurking in it.
In this article, I would like to shed more light on trade-offs involved in the GCC implementation choices. Besides illuminating underlying issues for GCC contributors interested in implementing new warnings or improving existing ones, I hope it will help calibrate expectations for GCC users about what kinds of problems can be expected to be detected and with what efficacy. Having a better understanding of the challenges should also reduce the frustration the limitations of the available solutions can sometimes cause. (See part 2 to learn more about middle-end warnings.)
The article isn’t specific to any GCC version, but some command-line options it refers to are more recent than others. Most are in GCC 4 that ships with Red Hat Enterprise Linux (RHEL), but some are as recent as GCC 7. The output of the compiler shown in the examples may vary between GCC versions. See How to install GCC 8 on RHEL if you’d like to use the latest GCC.
Continue reading “Understanding GCC warnings”
I work at Red Hat on GCC, the GNU Compiler Collection, and I spent most of the past year making GCC easier to use. Let’s look at C and C++ improvements that will be in the next major release of GCC, GCC 9.
Continue reading “Usability improvements in GCC 9”