glibc

Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level

Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level

One of the most important early decisions when building a Linux distribution is the scope of supported hardware. The distribution’s default compiler flags are significant for hardware-platform compatibility. Programs that use newer CPU instructions might not run on older CPUs. In this article, I discuss a new approach to building the x86-64 variant of Red Hat Enterprise Linux (RHEL) 9 and share Red Hat’s recommendation for that build.

Continue reading Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level

Share
Stack clash mitigation in GCC, Part 3

Stack clash mitigation in GCC, Part 3

In previous posts, Stack Clash Mitigation in GCC — Background and Stack Clash mitigation in GCC: Why -fstack-check is not the answer, I hopefully showed the basics of how stack clash attacks are structured and why GCC’s existing -fstack-check mechanism is insufficient for protection.

So, what should we do? Clearly we want something similar to -fstack-check, but without the fundamental problems. Enter a new option: -fstack-clash-protection.

The key principles for code generation to prevent a stack clash attack are:

Continue reading “Stack clash mitigation in GCC, Part 3”

Share
Toward _FORTIFY_SOURCE parity between Clang and GCC

Toward _FORTIFY_SOURCE parity between Clang and GCC

GCC combined with glibc can detect instances of buffer overflow by standard C library functions. When a user passes the -D_FORTIFY_SOURCE={1,2} preprocessor flag and an optimization level greater or equal to -O1, an alternate, fortified implementation of the function is used when calling, say, strcpy. Depending on the function and its inputs, this behavior may result in a compile-time error, or a runtime error triggered upon execution. (For more info on this feature, there’s an excellent blog post here on the subject).

Continue reading Toward _FORTIFY_SOURCE parity between Clang and GCC

Share
Implicit function declarations: flex’s use of “reallocarray”

Implicit function declarations: flex’s use of “reallocarray”

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[2]: *** [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””

Share
A platform interface for the GNU C Library

A platform interface for the GNU C Library

Application developers continue to need newer versions of libraries, including core runtimes like GNU C Library (glibc), for their applications. In this article, I’ll look at some issues related to upgrading glibc in an operating system (OS) distribution, and I also encourage you to read Florian Weimer’s excellent blog post on the topic.

The problem

Deciding between a library rebase or continued backporting of commits involves a complex set of risks and rewards. For some customers and users, it is important not to rebase the library (ensuring the lowest risk of impact by change); but for others, the rebase brings valuable bug fixes (lowest risk of impact from known issues). In other cases, the newer library may perform better, even if the interfaces haven’t changed, because it can take advantage of newer hardware or a newer Linux kernel (performance advantage to first mover).

There is no way to simultaneously satisfy all the requirements of slow-moving versus fast-moving development. The recent work in Fedora Modularity is aimed at solving the root of this problem, but there is a limit to this work. The further down the stack you go, the harder the problem becomes. The potential for breakage further up the stack increases. You can’t always arbitrarily change a component’s installed version without consequences, either at build time or at runtime.

Continue reading “A platform interface for the GNU C Library”

Share
The Non-complexity of /etc/nsswitch.conf

The Non-complexity of /etc/nsswitch.conf

In most glibc-based operating systems, there’s a file /etc/nsswitch.conf that most people ignore, few people understand, but all people generally rely on. This file determines where the system finds things like host names, passwords, and protocol numbers. Does your company use LDAP? NIS? Plain files? The nsswitch file (it stands for “name services switch”) tells the system what service to use for each type of name lookup.

Continue reading The Non-complexity of /etc/nsswitch.conf

Share