| Summary: | enable amd64 (x86-64) CET by default in 23.0 profiles | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andreas K. Hüttel <dilfridge> |
| Component: | Profiles | Assignee: | Andreas K. Hüttel <dilfridge> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dilfridge, gentoo, m1027, pageexec, StormByte |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=908600 https://bugs.gentoo.org/show_bug.cgi?id=908523 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 876891 | ||
| Bug Blocks: | 949404 | ||
|
Description
Andreas K. Hüttel
2024-03-19 15:25:49 UTC
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8bfd8afef6dd8c66def48ef52abcb624c0077ad1 commit 8bfd8afef6dd8c66def48ef52abcb624c0077ad1 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-03-23 15:04:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-23 15:38:51 +0000 sys-devel/clang-common: updates for 23.0 * Promote -Wl,-z,now to vanilla, following GCC (bug #876923) * Add USE=cet to control -fcf-protection, following GCC (bug #908600, bug #927298) Bug: https://bugs.gentoo.org/876923 Bug: https://bugs.gentoo.org/927298 Closes: https://bugs.gentoo.org/908600 Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/amd64/package.use.mask | 1 + profiles/base/package.use.mask | 1 + profiles/features/musl/package.use.mask | 1 + .../clang-common/clang-common-17.0.6-r2.ebuild | 295 ++++++++++++++++++++ .../clang-common/clang-common-18.1.2-r1.ebuild | 297 +++++++++++++++++++++ .../clang-common/clang-common-19.0.0.9999.ebuild | 10 +- .../clang-common-19.0.0_pre20240316.ebuild | 10 +- sys-devel/clang-common/metadata.xml | 10 + 8 files changed, 621 insertions(+), 4 deletions(-) This is fixed in the 23.0 profiles (available and stable now). Closing. I'd like to report an issue that I'm having after enabling this. I'm not sure if it's a bug or expected behavior though. My gentoo host has a newer CPU (AMD 3600X, which has supports CET and x86-64-v3 ISA or higher). After enabling this, when I compile a binary in my gentoo host simply using `gcc main.cc -o main` and copy the binary to another host with an older CPU (Intel G5400, with only x86-64-v2 ISA), the binary cannot run (reports error "CPU ISA level is lower than required"). It turns out that the default -fcf-protection=full would set required ISA to x86-64-v3, even if -march=x86-64-v2 is specified. For compiling C codes using gcc or clang, I can workaround this problem by adding -fcf-projection=none. However, it also affects rustc compiler (presumably because it uses llvm under the hood? I'm not sure), which I haven't found a proper way to solve yet. Is this the expected behavior? I thought that this feature should only affect portage toolchain (binaries built by emerge), but not user's own code compiling. (In reply to Yikai Zhao from comment #3) > > > Is this the expected behavior? I thought that this feature should only > affect portage toolchain (binaries built by emerge), but not user's own code > compiling. If your glibc or GCC are built with -march=x86-64-v3, their target libraries will include the v3 ISA marker. You can build glibc with -march=x86-64-v2 and I think GCC with CFLAGS_FOR_TARGET too and then it should be fine. If you run `gcc -v ...` then inspect e.g. the crt files it references with readelf, you should see the ISA markers. The CET part is a coincidence here, I think. (In reply to Sam James from comment #4) > If you run `gcc -v ...` then inspect e.g. the crt files it references with > readelf, you should see the ISA markers. > > The CET part is a coincidence here, I think. Thank you so much for your reply. After some more experiments, I think you are right. The final ISA marker comes from the crt files. Previously I thought the "x86 feature: IBT, SHSTK" markers produced by -fcf-protection affects the ISA marker. I was wrong. Sorry for the noise :) You're most welcome - glad your problem is sorted! I do want to document this somewhere on the wiki, as it catches people out (a lot of people don't realise there's any real runtime target libraries in C). Note that this wasn't as much of an issue in Gentoo until.. glibc-2.38(?) when we finally enabled it in glibc, after several rounds of bugs: commit 1f0fd3e2aee01e0c09e7103c8af4183b57faef49 Author: Sam James <sam@gentoo.org> Date: Mon Jul 24 23:42:52 2023 +0100 sys-libs/glibc: drop stale workarounds As of >=2.35, all of these are fixed. Bug: https://bugs.gentoo.org/785091 Bug: https://sourceware.org/PR27318 Bug: https://sourceware.org/PR27991 Signed-off-by: Sam James <sam@gentoo.org> In case there will be (or is?) a documentation as mentioned above, let me just add: A test build can be as easy as: > echo "int main(){ return 1;}" > main.c; gcc main.c To easily check the ISA level: > readelf -a -W a.out And, for anyone like me who needs to compile for other targets with lower ISA level: A fresh virtual Gentoo machine via stage3 extracted as a systemd machine/nspawn dropped me into a pure 'x86-64' host within minutes. Building there was obviously producing binaries on 'x86-64' baseline, so ISA v1. And, just recompiling glibc with '-march=x86-64-v2' witout touching GCC was enough to make new builds be at ISA level v2. I dumped some notes at https://wiki.gentoo.org/wiki/User:Sam/ISA_markers_vs_startup_files. Discussing it more on IRC now. |
