Hi!

As it was brought up recently in #1113864, it seems like we are
lacking support from glibc (and Linux) for full CET coverage on amd64.

On the kernel there seems to still be missing support for IBT, which
means glibc cannot add support to enable it yet, although it has
scaffolding for it (tunables and ELF markings etc). But at least both
have support for shadow stacks.

I think it would be nice to enable CET support, via glibc's configure
--enable-cet=permissive option on amd64, so that we can start to
exercise this.

AFAIUI --enable-cet might currently be too strict, and could refuse to
load shared objects that have not yet been marked as supporting CET
(shadow stacks and/or IBT), such as packages not using dpkg-buildflags,
or for projects with source in assembler that have not been marked with
the appropriate section.

I think other distributions pass --enable-cet=permissive as well, and I
think previously they were passing --enable-cet and had to either
revert that due to breakage or switch to --enable-cet=permissive.
Checking now Fedora for example I see this:

  <https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1412>

Thanks,
Guillem

Hi,

Reading the report, this feature was announced in the Trixie release notes.

https://www.debian.org/releases/stable/release-notes/whats-new.html#hardening-against-rop-and-cop-jop-attacks-on-amd64-and-arm64

You may want to consider a backport to Trixie.

I was checking that enable-cet could cause plugins or libraries loaded with
dlopen to fail, while enable-cet=permissive deactivates CET while dlopen
gets executed.

As per other distros, checking provided Fedora link and SUSE, both seem to
set enable-cet in their strict version (probably after they have rebuilt
the archive with permissive option).

https://build.opensuse.org/projects/openSUSE:Factory/packages/glibc/files/glibc.spec?expand=1


 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Hi,

Unfortunately, configuring glibc with --enable-cet=permissive causes the
upstream tst-shstk-legacy-1g test to fail, at least on my laptop (Zen 3
based). This seems similar to this upstream bug, although without using
a specific -march= option:

https://sourceware.org/bugzilla/show_bug.cgi?id=31877

This needs a bit more investigation to understand why this test fails.

Regards
Aurelien