Problem description
SHSTK is an x64 security feature that is part of Intel CET, and support for it was added in PR #2992. The problem is, this PR only applies to the make build system, and not the cmake one, so when built with cmake, libzstd.so is still not marked as SHSTK-compatible, and this causes SHSTK not to be supported on applications that use libzstd.
How to reproduce
On systems that use cmake to build the library:
user@fedora:~$ readelf -n /usr/lib64/libzstd.so | grep SHSTK
... (no results) ...
Proposed fix
The crux of the issue is that when cmake compiles lib/decompress/huf_decompress_amd64.S, it doesn't pass any flags to the compiler. The object therefore gets compiled without -fcf-protection, which causes cet.h not to emit a .note.gnu.property section in the object, which in turn causes the final libzstd.so not to have that section either.
This can be fixed by simply using the C compiler flags when building assembly files, to ensure that -fcf-protection gets passed on them:
diff --git a/build/cmake/CMakeModules/AddZstdCompilationFlags.cmake b/build/cmake/CMakeModules/AddZstdCompilationFlags.cmake
index 3e7bcce5..cddb7ceb 100644
--- a/build/cmake/CMakeModules/AddZstdCompilationFlags.cmake
+++ b/build/cmake/CMakeModules/AddZstdCompilationFlags.cmake
@@ -113,6 +113,9 @@ macro(ADD_ZSTD_COMPILATION_FLAGS _C _CXX _LD)
endif ()
endif ()
+ # Use the C flags as ASM flags
+ set(CMAKE_ASM_FLAGS "${CMAKE_C_FLAGS}")
+
# Remove duplicates compilation flags
foreach (flag_var CMAKE_C_FLAGS CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_RELWITHDEBINFO
Confirmed that it fixes the issue:
user@fedora:~$ readelf -n libzstd.so.1.5.7 | grep SHSTK
Properties: x86 feature: IBT, SHSTK
Problem description
SHSTK is an x64 security feature that is part of Intel CET, and support for it was added in PR #2992. The problem is, this PR only applies to the make build system, and not the cmake one, so when built with cmake,
libzstd.sois still not marked as SHSTK-compatible, and this causes SHSTK not to be supported on applications that use libzstd.How to reproduce
On systems that use cmake to build the library:
Proposed fix
The crux of the issue is that when cmake compiles
lib/decompress/huf_decompress_amd64.S, it doesn't pass any flags to the compiler. The object therefore gets compiled without-fcf-protection, which causescet.hnot to emit a.note.gnu.propertysection in the object, which in turn causes the finallibzstd.sonot to have that section either.This can be fixed by simply using the C compiler flags when building assembly files, to ensure that
-fcf-protectiongets passed on them:Confirmed that it fixes the issue: