[clang] Reporting unused function with ifunc resolver

[JiaT75]

Hello!

Clang 16.0.0 and older report a warning when compiling a program that uses __attribute__((__ifunc__())) with -Wunused-function. The resolver function appears to trigger this when it is only referenced by the __attribute__. Here is an example program that should trigger the warning:

static void resolved(void) {
    return;
}

static void (*resolver (void)) (void) {
	return resolved;
}

void indirect_function(void) __attribute__((__ifunc__("resolver")));

int main() {
    indirect_function();
}

GCC does not issue a warning for the above program. Here is a godbolt.org snippet of the above code to allow you to easily test it. Let me know if you need anymore information.

[Zentrik]

This reproduces on trunk.

[mxmlnkn]

Should this really be changed taking into account the ifunc-based xz backdoor added by the issue reporter? https://www.openwall.com/lists/oss-security/2024/03/29/4

[tstellar]

We should not make this change in LLVM right now.

[MaskRay]

We should not make this change in LLVM right now.

tukaani-project/xz@82ecc53 is a legitimate change that exposes two problems:

• Static linking with glibc and gcc -fprofile-generate can lead to crashes. The instrumented resolver attempts to access TLS before it's properly set up by __libc_setup_tls (https://gcc.gnu.org/PR114115). https://maskray.me/blog/2021-01-18-gnu-indirect-function#non-preemptible-ifunc#:~:text=no_profile_instrument_function
• This Clang -Wunused-function false positive, which should be fixed by [Sema] Mark alias/ifunc targets used and consider mangled names #87130

We should be careful and don't consider all xz commits malicious.

[tstellar]

We should be careful and don't consider all xz commits malicious.

I disagree, we need to be extra careful with changes associated with the xz project right now. There's no reason why we need to get this change committed quickly. It should get extra scrutiny.

[shafik]

We should be careful and don't consider all xz commits malicious.

I disagree, we need to be extra careful with changes associated with the xz project right now. There's no reason why we need to get this change committed quickly. It should get extra scrutiny.

I concur with this sentiment, the details are still emerging on this whole incident. This so far seems like the best timeline: https://boehs.org/node/everything-i-know-about-the-xz-backdoor and a lot if still unknown.

I don't feel confident in saying I have the whole picture and I think until we get a better idea of the scope we should be taking our time.

[NuLL3rr0r]

Did GitHub just restored their access? I thought the account was suspended.

[vvdaal]

Rather offtopic but

Did GitHub just restored their access? I thought the account was suspended.

No (check https://github.com/Larhzu?tab=following), Larhzu is also still suspended. (https://github.com/JiaT75?tab=following)

[thesamesam]

I'm going to lock this for now but we can unlock it later when things have quietened down.