An LTO pass that inserts a __cfi_check() function that validates a call based on a hash of the call-site-known type and the target pointer.
Diff Detail
- Repository
- rL LLVM
Event Timeline
Please also add design documentation to docs/ControlFlowIntegrityDesign.rst.
include/llvm/Transforms/IPO/CrossDSOCFI.h | ||
---|---|---|
21 ↗ | (On Diff #42257) | Why is this in a header? Were you planning to add unit tests for this function? |
lib/Transforms/IPO/CrossDSOCFI.cpp | ||
2 | module's | |
11 | Please do. | |
49 | This will yield a different result depending on the endianness of the host machine. | |
64 | This function doesn't look like it is defined anywhere. | |
90 | This is already happening, no? | |
101 | This won't be necessary if we teach the clang frontend to not emit bitset entries for declarations when doing cross-DSO. | |
105 | This isn't exactly right; MDNode::isDistinct() corresponds directly to whether the bitset entry has global scope. I would check isDistinct here and assert that the identifier is an MDString (since we don't support hashing anything else). | |
lib/Transforms/IPO/PassManagerBuilder.cpp | ||
603 | I'd prefer if this stated what the function does (i.e. "create function that ..."). | |
test/Transforms/CrossDSOCFI/basic.ll | ||
6 | Probably should check for hash values here since we know what they're going to be. | |
37–44 | The body of the test could be made a lot simpler. E.g. these don't need to be vtables. |
include/llvm/Transforms/IPO/CrossDSOCFI.h | ||
---|---|---|
22 ↗ | (On Diff #42258) | Oh, I see that you need this in the frontend. I wonder if there's a better way to do this that doesn't involve the frontend and the pass conspiring to use the same hash values? Maybe the bitset identifiers should be hash values in cross-DSO mode? |
include/llvm/Transforms/IPO/CrossDSOCFI.h | ||
---|---|---|
22 ↗ | (On Diff #42258) | Switched to hash values in bitset identifiers. The frontend now emits 2 bitset entries for each function or vtable entry: one with a string identifier for local checks, and one with a hash value for cross-DSO checks. We don't use hash values for local checks because of possible hash function collisions that could weaken the checks. |
lib/Transforms/IPO/CrossDSOCFI.cpp | ||
50 | Moved to clang (see D15367) and fixed. | |
91 | You mean insertion at the end of the module? I think so, but I wonder if anything else can be done to ensure that nothing gets reordered later. | |
102 | Moved to a separate function and replaced a "continue" with an assert, just in case. | |
106 | This is gone. |
lib/Transforms/IPO/CrossDSOCFI.cpp | ||
---|---|---|
85 | Early return here. | |
92 | Sure, so let's word the FIXME like that. | |
112 | I think this will break if the ConstantInts are not of type i64. Can you handle this gracefully? | |
141 | Isn't this non-deterministic? I think it will depend on the ConstantInt addresses. | |
test/Transforms/CrossDSOCFI/basic.ll | ||
18 | I think you can make these tests more specific once the non-determinism has been fixed in the code. |
lib/Transforms/IPO/CrossDSOCFI.cpp | ||
---|---|---|
113 | It can be a requirement but we shouldn't produce invalid IR if it happens. I think the easiest thing to do is to return nullptr from CrossDSOCFI::extractBitSetTypeId if the ConstantInt is not i64. | |
test/Transforms/CrossDSOCFI/basic.ll | ||
6 | You can test for the label names as well (here and below). |
module's