In my previous article about nsswitch.conf I talked about how simple, perhaps too simple, this config file is to use. What I didn’t cover then was how simplistic its internal implementation is. Specifically, an application only loads this file once—the first time it’s needed.
Continue reading Coming in glibc 2.33: Reloadable nsswitch.conf
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
Daylight saving time transitions, a zone name change, and the removal of some obsolete files: These are some of the changes that occurred in the Time Zone Database (tzdata) package that provides Red Hat Enterprise Linux (RHEL) and applications with time zone information.
Continue reading 2020 Time Zone Database (tzdata) changes
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”
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
One of the GNU C Library’s (glibc’s) unwritten rules is that a program built against an old version of glibc will continue to work against newer versions of glibc. But how does this work? What hidden magic lets you call the same function with different results, just based on when you built your program?
Continue reading “How the GNU C Library handles backward compatibility”
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””
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.
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”
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
When you write a program, you have to test it. Run, program, run! Did it do what you expected? Yay! Maybe you’ll even set up a testsuite to run it many times, just to be sure. You might even create some sample files for it to work with.
Continue reading Microcontainers for Unit Testing
