Libc++ Hardening Modes
The libc++ documentation details hardening modes (Unchecked, Fast, Extensive, Debug) to prevent undefined behavior. Users adjust levels via compiler options. Vendors customize modes, assertion handling, and ABI configurations for enhanced safety.
Read original article
The libc++ documentation outlines different hardening modes available for users and vendors to prevent undefined behavior in the standard library. The modes include Unchecked, Fast, Extensive, and Debug, each offering varying levels of checks and performance impact. Users can adjust the hardening level by passing options to the compiler. Vendors can set default hardening modes and customize assertion failure handling. Assertion categories like valid-element-access and valid-input-range ensure container and range validity. Hardening assertion failures in production modes immediately halt the program, while debug mode provides error messages for easier debugging. Vendors can override the default assertion handler mechanism. Hardening modes do not affect the ABI, but certain checks may require changes in the ABI configuration. ABI options like _LIBCPP_ABI_BOUNDED_ITERATORS enable additional checks for specific containers. ABI tags encode hardening modes for interaction between translation units. The documentation also covers hardened containers status, testing procedures, and further reading resources.
Related
Memory sealing for the GNU C Library
The GNU C Library introduces mseal() system call for enhanced security by preventing address space changes. Adhemerval Zanella's patch series adds support, improving memory manipulation protection in upcoming releases.
Own Constant Folder in C/C++
Neil Henning discusses precision issues in clang when using the sqrtps intrinsic with -ffast-math, suggesting inline assembly for instruction selection. He introduces a workaround using __builtin_constant_p for constant folding optimization, enhancing code efficiency.
GCC's new fortification level: The gains and costs
GCC introduces _FORTIFY_SOURCE=3 for enhanced security by detecting buffer overflows in C programs at runtime. This level offers precise object size estimates, improving fortification coverage and revealing more issues in glibc. Despite potential impacts, the security benefits outweigh costs, emphasizing the importance of fortification for application security.
How GCC and Clang handle statically known undefined behaviour
Discussion on compilers handling statically known undefined behavior (UB) in C code reveals insights into optimizations. Compilers like gcc and clang optimize based on undefined language semantics, potentially crashing programs or ignoring problematic code. UB avoidance is crucial for program predictability and security. Compilers differ in handling UB, with gcc and clang showing variations in crash behavior and warnings. LLVM's 'poison' values allow optimizations despite UB, reflecting diverse compiler approaches. Compiler responses to UB are subjective, influenced by developers and user requirements.
How the STL Uses Explicit
The WG21 meeting in St. Louis discusses a paper on using the `explicit` keyword in C++ proposals to establish a style guide for consistency. Guidelines differ between industry and Standard Library practices.
1 commentsAll the current popular runtimes come with memory safety out of the box.
https://dconf.org/2017/talks/bright.pdf was right on the money.
Still, something is better than nothing.
Related
Memory sealing for the GNU C Library
The GNU C Library introduces mseal() system call for enhanced security by preventing address space changes. Adhemerval Zanella's patch series adds support, improving memory manipulation protection in upcoming releases.
Own Constant Folder in C/C++
Neil Henning discusses precision issues in clang when using the sqrtps intrinsic with -ffast-math, suggesting inline assembly for instruction selection. He introduces a workaround using __builtin_constant_p for constant folding optimization, enhancing code efficiency.
GCC's new fortification level: The gains and costs
GCC introduces _FORTIFY_SOURCE=3 for enhanced security by detecting buffer overflows in C programs at runtime. This level offers precise object size estimates, improving fortification coverage and revealing more issues in glibc. Despite potential impacts, the security benefits outweigh costs, emphasizing the importance of fortification for application security.
How GCC and Clang handle statically known undefined behaviour
Discussion on compilers handling statically known undefined behavior (UB) in C code reveals insights into optimizations. Compilers like gcc and clang optimize based on undefined language semantics, potentially crashing programs or ignoring problematic code. UB avoidance is crucial for program predictability and security. Compilers differ in handling UB, with gcc and clang showing variations in crash behavior and warnings. LLVM's 'poison' values allow optimizations despite UB, reflecting diverse compiler approaches. Compiler responses to UB are subjective, influenced by developers and user requirements.
How the STL Uses Explicit
The WG21 meeting in St. Louis discusses a paper on using the `explicit` keyword in C++ proposals to establish a style guide for consistency. Guidelines differ between industry and Standard Library practices.