Detecting String Truncation with GCC 8

Continuing in the effort to detect common programming errors, the just-released GCC 8 contains a number of new warnings as well as enhancements to existing checkers to help find non-obvious bugs in C and C++ code. This article focuses on those that deal with inadvertent string truncation and discusses some of the approaches for avoiding the underlying problems. If you haven’t read it, you might also want to read David Malcolm’s article Usability improvements in GCC 8.

Why Is String Truncation a Problem?

It is well-known why buffer overflow is dangerous: writing past the end of an object can overwrite data in adjacent storage, resulting in data corruption. In the most benign cases, the corruption can simply lead to incorrect behavior of the program. If the adjacent data is an address in the executable text segment, the corruption may be exploitable to gain control of the affected process, which can lead to a security vulnerability. (See CWE-119 for more on buffer overflow.)

Continue reading “Detecting String Truncation with GCC 8”


Recommended compiler and linker flags for GCC

Did you know that when you compile your C or C++ programs, GCC will not enable all exceptions by default?  Do you know which build flags you need to specify in order to obtain the same level of security hardening that GNU/Linux distributions use (such as Red Hat Enterprise Linux and Fedora)? This article walks through a list of recommended build flags.

The GNU-based toolchain in Red Hat Enterprise Linux and Fedora (consisting of GCC programs such as gcc, g++, and Binutils programs such as as and ld)  are very close to upstream defaults in terms of build flags. For historical reasons, the GCC and Binutils upstream projects do not enable optimization or any security hardening by default. While some aspects of the default settings can be changed when building GCC and Binutils from source, the toolchain we supply in our RPM builds does not do this. We only align the architecture selection to the minimum architecture level required by the distribution.

Consequently, developers need to pay attention to build flags, and manage them according to the needs of their project for optimization, level of warning and error detection, and security hardening.

Continue reading “Recommended compiler and linker flags for GCC”


Memory Error Detection Using GCC


GCC has a rich set of features designed to help detect many kinds of programming errors. Of particular interest are those that corrupt the memory of a running program and, in some cases, makes it vulnerable to security threats. Since 2006, GCC has provided a solution to detect and prevent a subset of buffer overflows in C and C++ programs. Although it is based on compiler technology, it’s best known under the name Fortify Source derived from the synonymous GNU C Library macro that controls the feature: _FORTIFY_SOURCE. GCC has changed and improved considerably since its 4.1 release in 2006, and with its ability to detect these sorts of errors. GCC 7, in particular, contains a number of enhancements that help detect several new kinds of programming errors in this area. This article provides a brief overview of these new features. For a comprehensive list of all major improvements in GCC 7, please see GCC 7 Changes document.

Continue reading “Memory Error Detection Using GCC”


What Lies Beneath: A tour of the dark gritty underbelly of OpenJDK

java icon 240 × 171OpenJDK is the premier open source Java implementation. The OpenJDK project provides the code used to build Red Hat’s Java releases for Fedora and RHEL and the Java releases used on most other Linux distributions. It also forms the basis of Oracle’s proprietary Java binary releases.

The Red Hat OpenJDK team has been working for some time now, along with organizations like the London Java Community (LJC) and some of our academic partners (e.g. Glasgow & Manchester) to encourage researchers and developers to dive into the innards of OpenJDK’s Java Virtual Machine (JVM) and see how it actually works. One reason is the entirely selfish one that we would like to enlarge the community of potential contributors to the OpenJDK project. Another is that we think it is no bad thing for Java developers, as indeed for any developers, to understand the tools they are using at a deeper level and appreciate how a well designed tool shields them from having to manage some of the more complex aspects of the runtime environment in which their programs execute.

Continue reading “What Lies Beneath: A tour of the dark gritty underbelly of OpenJDK”


Array allocation in C++

This technical article covers a subtlety in C++ array allocation and how we changed the GNU C++ compiler to deal with it properly. When a programmer writes

T *p = new T[3];

the C++ compiler allocates room for at least three copies of objects of type T on the heap. These objects require 3 * sizeof(T) bytes. For this example, assume sizeof(T) is 12, then it is straightforward to allocate 36 bytes (for example, using malloc). But what happens if the array length is 3937053355 (or 16909515400900422315 on a 64-bit architecture)? Then 47244640260 bytes are required. This number cannot be expressed in 32-bits, so if 32-bit arithmetic is used to perform the multiplication, the result is a mere 4. Unless special care is taken, a C++ implementation will provide a pointer to a heap area that is much too small for holding the requested number of objects (4 bytes instead of 47244640260 bytes).

Continue reading “Array allocation in C++”


7 ways to improve your application’s performance with the new Developer Toolset 1.1 release

Are you missing out on opportunities to increase your applications’ performance? As an application developer building on Red Hat Enterprise Linux, you invest a lot of time and effort into making your applications compelling and useful for your users. You probably also want to see good performance. But beyond good design, careful algorithm selection and compiler optimizations, what can a developer use to boost their application performance?

1. The latest GCC release and associated tools

The very first thing a Red Hat Enterprise Linux developer should be aware of is the availability of Red Hat Developer Toolset. I described the content and architecture of this new offering from Red Hat in my last blog post. Developer Toolset 1.x gives you the gcc-4.7 toolchain, which, at the time of writing, is the current upstream major release.

Continue reading “7 ways to improve your application’s performance with the new Developer Toolset 1.1 release”


Is your C++ development team missing out? Developer Toolset: newer tools on and for multiple RHEL releases

Wouldn’t it be nice if your software development team could use one common set of development tools based on the latest, stable upstream versions for your Red Hat Enterprise Linux development? Think of all the extra years of open source innovation – the features, optimizations and new standards support it would allow your team to build into your products. That would be great, wouldn’t it?

Fortunately, this is already available to you today, and in this blog post I’ll explain how it works and how you can get it. Red Hat Developer Toolset provides a set of additional tools installed in parallel with those delivered as part of Red Hat Enterprise Linux itself. Currently featuring the GCC C/C++ compiler and GDB debugger and backed up by Red Hat’s solid customer support, Red Hat Developer Toolset 1.0 is a great way to unlock performance in your team and your software very easily.

And if you’re already a Red Hat Developer Program subscriber, you can install the tools right now. The Red Hat Developer Toolset version 1.1 Beta, released in October 2012,
showcased a good number of additional performance analysis tools. We’re just getting started with this new offering and have plans to include other tools in the future.

Continue reading “Is your C++ development team missing out? Developer Toolset: newer tools on and for multiple RHEL releases”