"H.J. Lu" <hjl.to...@gmail.com> writes: >> 2. 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 -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
