"H.J. Lu" <hjl.tools(a)gmail.com> writes:
> You need to write a run-time test in configure.ac to check if CET is enabled
> since CET requires processor, kernel and user space support.
Do you think a test like this would be feasible? It needs both compile
time and run time checks:
1. Check (preprocessor) if building on x86, and on an operating system
with unix-style signal handling. If not, define test_main to
exit with return code 77 (SKIP macro in testutils.h).
2. Use inline assembly in some way to define a trivial function with no
ENDBR mark, and produce a function pointer to it.
3. If __CET__ is defined by the compiler, check for runtime support
(hardware + kernel, but *not* the current mode set up based on ELF
flags in the executable). If it's supported, install a signal handler
for whatever for whatever signal happens on indirect jumps without
ENDBR marks, and which exits the process with return code 0
(success). Call the asm function via the function pointer. If the
call returns, fail the test by calling abort.
4. Otherwise, call the asm function via the function pointer, and exit
with return code 77. (To exercise the inline asm, but still indicate
that the feature inteded to be tested could not be tested).
Then the test will fail if either we're running a CET-enabled build on a
CET enabled system, but for for some reason the test executable didn't
get it this protection. Or we're running on a non-CET x86 system where
the inline asm is somehow broken.
No additional configure checks needed (except if we want a proper test
for signal/sigaction rather than depending on preprocessor predefines).
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.