Aaron Ballman, the lead Clang compiler maintainer and a member of the WG21 (C++) and WG14 (C) standard development teams, has initiated a discussion about introducing a security enhancement mode into the Clang compiler. This new mode will allow a set of options to be activated all at once for enhanced protection, similar to the '-fhardened' flag added in GCC 14, which activates the options '-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -ftrivial-auto-var-init=zero -fPIE -pie -Wl,-z,relro,-z,now -fstack-protector-strong -fstack-clash-protection -fcf-protection=full'.
It is noted that work is currently underway to add security enhancement capabilities to the C and C++ standards, but this process is not quick. Meanwhile, specific options with additional protection mechanisms are already available in Clang. The implemented protection methods often lead to individual incompatibilities with existing code or ABI violations, making it impossible to activate them by default. Additionally, such options are fragmented (flags for controlling compilation, machine instruction generation flags tied to hardware architectures, warnings, diagnostic modes, macros), poorly documented, and tend to fall off the radar of many developers.
A unified configuration simplifies the activation of security-related options and makes their application easier. Several options for activating the enhanced security mode are being considered, such as activation through the flag '-fhardened', a configuration set '--config=hardened', a separate driver (clang --driver-mode), or separate options '-fhardened, -mhardened and -Whardened', tied to compilation, code generation, and warning output. The mode may cover:
- Compiler capabilities: -ftrivial-auto-var-init, -fPIE, -fcf-protection, etc.
- Features related to code generation for target platforms: -mspeculative-load-hardening, -mlvi-hardening, etc.
- Warnings: -Wall, -Wextra, -Werror=return-type, etc.
- Security enhancement modes in the standard function library.
- Macros: _FORTIFY_SOURCE, _GLIBCXX_ASSERTIONS, etc.
- Requirement for an explicit choice of the language standard used.
- Refusal to compile code using deprecated C89 and C++98 standards.
- Passing additional flags to the linker, for example, to enable address randomization.
Source: opennet.ru
