statham-arm wrote: In #176187 you mention "The mitigation is not compatible with execute-only mode since it performs a load from a code region." In that case, this patch should include a check for that case: if someone enables this hardening option and also execute-only, they should get an error message rather than generating code that will perform an illegal memory access at run time.
Also, could you add some documentation for the option in `clang/docs`, explaining _what_ the mitigation does, and what it does / does not mitigate? Feel free to correct this if I've got any of it wrong, but I think the key points are * the mitigation inserts code that performs a data load from the function's return address before returning to it * the data load is not conditional on whether or not the return address passed the AUT instruction * therefore, when this sequence is speculated, the L2 cache (shared between instruction and data) ends up containing the cache line corresponding to the return address regardless of the results of AUT, and hence, it can't be used as an oracle to discover whether AUT succeeded * however this only affects the shared I/D cache layer; if someone is able to find a way to probe the I-cache specifically, then this mitigation doesn't help. (But we hope that's harder.) * also, if the code _at_ the return address performs any memory access of its own within the speculation horizon, like a load instruction, then that will still be speculatively performed conditional on the AUT, so probing the results of that may still allow the same oracle. https://github.com/llvm/llvm-project/pull/176171 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
