"H.J. Lu" hjl.tools@gmail.com writes:
- What I tried to ask about in the message you reply to, was how to write a test within the Nettle testsuite, to verify that enabling CET really has effect on a test executable (on systems where it is expected to have effect). It's not obvious to me if and how the patch improves that.
The -z ibt -z shstk linker option creates the output marked as CET enabled regardless of input. When it is used to build the Nettle libraries and tests in the Nettle testsuite, tests will fail on CET Linux if ENDBR is missing at indirect branch targets.
That will test that low-level cet is working (e.g., needed ENDBR isntructions are there). I was asking for a different kind of test, verifying that if a test executable is linked with nettle, and everything is built with -fcf-protection=full passed to the gcc frontend, and run on a cet enabled system, then a violation of cet will result in a crash. I outlined a way to write such a test, do you think it is feasible?
A test like that can give us confidence that cet is properly enabled all the way. And then regular unit tests will cover the details, with a ./configure CC='gcc -fcf-protextion=full' && make && make check on a CET-enabled system.
I'd prefer to not passing any special linker flags when linking the test executables, they should as far as possible be linked the same way as non-test programs using Nettle.
Regards, /Niels