Move AT_EXECFN to fallback for /proc/self/exe

[am11]

In #66874, the missing header was added which enabled the fast (aux vector) path on Linux.

The issue with AT_EXECFN is that it returns the path which was passed to the process via namei. This breaks the scenario where the .NET process is used as interpreter (namely PowerShell's #!/bin/pwsh) and returns the path of script containing the shebang link to the interpreter rather than the interpreter's path. In other words, AT_EXCFN implementation != /proc/self/exe. In all the usages of minipal_getexepath() in runtime repo, we need the behavior of latter on Linux.

The fix is to remove the usage of AT_EXCFN and rely solely on /proc/self/exe for Linux (which we were accidentally using in .NET 6 due to the missing header).

The fix is to flip the order so AT_EXCFN is used as a fallback to /proc/self/exe.

Fixes#78941 (we will probably need to backport this to .NET 7)

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In #66874, the missing header was added which enabled the fast (aux vector) path on Linux.

The issue with AT_EXECFN is that it returns the path which was passed to the process via namei. This breaks the scenario where the .NET process is used as interpreter (namely PowerShell's #!/bin/pwsh) and returns the path of script containing the shebang link to the interpreter rather than the interpreter's path. In other words, AT_EXCFN implementation != /proc/self/exe. In all the usages of minipal_getexepath() in runtime repo, we need the behavior of latter on Linux.

The fix is to remove the usage of AT_EXCFN and rely solely on /proc/self/exe for Linux (which we were accidentally using in .NET 6 due to the missing header).

Fixes #78941 (we will probably need to backport this to .NET 7)

Author:	am11
Assignees:	-
Labels:	area-Host
Milestone:	-

[janvorli]

This is unfortunate w.r.t. asks on minimizing usage of the /proc file system (one example is #2534) or issues where /proc/self/exe doesn't actually return the "real" exe path (#47280). I wonder if there is a way to handle the case this PR is fixing differently.

[janvorli]

I have looked at the getauxval doc and figured out a solution that doesn't use the /proc/self/exe and yet doesn't have the problem this issue is fixing:

unsigned longentry=getauxval(AT_ENTRY);
st=dladdr((void*)entry, &info2);
if (st!=0)
{
printf("From AT_ENTRY: %s\n", info2.dli_fname);
}

I've created a .sh script with the shebang pointing to my test app with the code above and when I ran it it printed this:

From AT_ENTRY: /home/janvorli/test/testatexecfn/test

[am11]

This is unfortunate w.r.t. asks on minimizing usage of the /proc file system

Yes, that's how we discovered the missing header #66874 (comment) when running a .NET app on a system with broken procfs. After that I sent other PRs to remove the usage of procfs in runtime and sdk repos.

This PR, however, is a correctness fix; both #if HAVE_GETAUXVAL and #else branches should be equivalent, but they are not. /proc/self/exe is not perfect, but it just works on a healthy system. This is a low risk fix because we are reverting to .NET 6 behavior.

AT_ENTRY

Could you point me where the docs mention the AT_ENTRY based solution to get the executable path? I have not found any references where someone is using this approach in production. It is either /proc/self/exe or AT_EXCFN. This thread has some discussion on the pros and cons https://lkml.iu.edu/hypermail/linux/kernel/0808.1/3101.html. Each method comes with its own caveats, so I am not confident to jump right on AT_ENTRY solution (which we have never tested before) for backport fix.

[janvorli]

@am11 I've found AT_ENTRY documented in the getauxval doc. It is the entry point address, so it must be in the actual executable. So I got the idea of using dladdr that can get the full path to the executable. I have not tried to search for it anywhere, so it is possible that no one is using that.
It is possible that there are some pitfalls, so I would definitely not jump into backporting it until we were sure that it works reliably.

I have actually got an additional idea on fixing this issue. What if we just flipped the order of reading the /proc/self/exe and the AT_EXECFN instead of getting rid of the latter? Then the AT_EXECFN would be a fallback for cases when the /proc/self/exe isn't there.

[janvorli]

LGTM, thank you!

[janvorli]

All the CI failures are known issues unrelated to this change.

[am11]

Thank you.

I think we should backport this to .NET 7 (to unblock PowerShell users). cc @agocke, @vitek-karas

[janvorli]

/backport to release/7.0

[github-actions]

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3586639149