Tried building sys-devel/gcc-14.2.1_p20241221 with USE="cet" two times, unfortunately each time libgccjit.so.0 lacks CET/shadow stack markings: > $ readelf -n /usr/lib/gcc/x86_64-pc-linux-gnu/14/libgccjit.so.0 | grep -q -a SHSTK > (no output) This means that any program that this library is loaded into (for example Emacs) cannot ever have CET enforcement since such enforcement requires that all of its library dependencies carry appropriate markings. I'm not sure if this is a Gentoo or an upstream bug, but reporting here since the sys-devel/gcc ebuild clearly has a "cet" USE flag.
Sorry, my bad, that CET testing command line (coming from a script) accidentally kept "-q" as a grep option, and the library does in fact have CET support: > $ readelf -n /usr/lib/gcc/x86_64-pc-linux-gnu/14/libgccjit.so.0 | grep -a SHSTK > Properties: x86 feature: IBT, SHSTK
Thanks for the followup. Please feel free to file bugs with any CET issues. I've only played with it in enforcing very lightly (with the glibc tunable) and hit some issue with Java and didn't yet go back to it. H.J. still has a fork with the patches needed for OpenJDK, I think.
Thanks, I mostly try reporting these issues upstream where it makes sense. In general, most of the CET issues seem to be caused either by code written in assembly or in Rust - for the later there might be a system-wide solution possible. To add a bit more detail to this libgccjit.so.0 false alarm: I think it was indeed missing CET markings when build the first time with USE="cet" on a otherwise non-CET system (that's why my script flagged it), then re-building GCC fixed it.
