[llvm] [IR] Allow uses of `llvm.global_ctors` and `llvm.global_dtors` (PR #96477)

Daniil Kovalev via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 25 03:44:04 PDT 2024


kovdan01 wrote:

@nikic 

> I'd rather not allow this, because this implies that we also have to lower such references to something meaningful, outside the pointer authentication use case.

I agree that this is a significant drawback of the changes, but I'm not sure how we can limit allowed uses of these special arrays only to self-references when storing address discriminated signed pointers as ctors/dtors. Please let me know if you have thoughts on this.

> Can you explain in more detail why these weird self-references are required?

Sure. When signing pointers, we have 4 arguments affecting the result: the raw pointer itself, the key, a constant discriminator (optional, 0 by default) and a storage address to be blended with this constant discriminator (also optional; when present, we say that such signed pointer is address discriminated). Address discrimination makes it harder to substitute a signed pointer with another one: not only constant discriminators used for signing need to be equivalent, but also storage address as well, otherwise further signature check will fail when trying to execute an authenticated branch instruction.

When we want to sign ctors/dtors with address discrimination, we need to get their storage address, which is inside `llvm.global_{c|d}tors` and is obtained by `getelementptr` - so, it looks like that we can't avoid this use. Theoretically, we can try to somehow transform self-references to just references, by adding logic for handling smth like this:

```
ctor1 = ptrauth(..., getelementptr(llvm.global_ctors, ...))
llvm.global_ctors = {ctor1}
```

But I'm not sure if it's any better, since presence of any uses, not just self-references, is disallowed now.

https://github.com/llvm/llvm-project/pull/96477


More information about the llvm-commits mailing list