Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: os: access to ELF auxiliary vector #67839

Open
0xF0CACC1A opened this issue Jun 5, 2024 · 12 comments
Open

proposal: os: access to ELF auxiliary vector #67839

0xF0CACC1A opened this issue Jun 5, 2024 · 12 comments
Labels
Milestone

Comments

@0xF0CACC1A
Copy link

Proposal Details

like os.Args and os.Environ, I was wondering why there is neither an API to get ELF auxiliary vector nor Aux type. C does provide them in Elf.h

@seankhliao seankhliao changed the title os: ELF auxiliary vector proposal: os: access to ELF auxiliary vector Jun 5, 2024
@gopherbot gopherbot added this to the Proposal milestone Jun 5, 2024
@ianlancetaylor
Copy link
Contributor

If we do this I think it should be in the golang.org/x/sys/unix package. The os package is mainly aimed at OS-independent functionality, but auxv is specific to ELF-based systems.

@0xF0CACC1A
Copy link
Author

so, in the current state of art, is there no way to get the full aux vector?

@ianlancetaylor
Copy link
Contributor

As far as I know there is not.

@adonovan
Copy link
Member

adonovan commented Jun 5, 2024

so, in the current state of art, is there no way to get the full aux vector?

Not from Go. In C you can usually derive it from the address of the environ symbol, but it may be non-portable.

@seankhliao
Copy link
Member

I see runtime has an internal sysauxv which x/sys/cpu hooks into, falling back to /proc/self/auxv. Is the proc file sufficient?

@0xF0CACC1A
Copy link
Author

/proc/self/auxv

could you provide a minimal example on how to retrieve auxv values?

@florianl
Copy link
Contributor

florianl commented Jun 21, 2024

#68089 advocated to expose runtime.getAuxv() and make it a public API. Exposing the auxiliary vector via os was not considered as a viable option, as os should be more of a higher level layer with cross OS compatability.
But adding a public API, like runtime.Getauxv(), would also introduce some kind of OS specifics into runtime.

An alternative, also mentioned in #67839 (comment) and go.dev/cl/458256, could be an exposure of the auxiliary vector via golang.org/x/sys. golang.org/x/sys is OS specific and therefore a perfect fit. The unknown for me in this approach is how golang.org/x/sys can get access to something, that only runtime knows about, without techniques like //go:linkname.

@ianlancetaylor
Copy link
Contributor

golang.org/x/sys/cpu already reaches into the runtime to fetch the auxiliary vector, using go:linkname. Adding an exported function in golang.org/x/sys/unix isn't going to make matters better or worse.

Reaching in from packages in x/sys is better than reaching in from arbitrary external packages, because we can change the x/sys packages ourselves, and then drop the support in runtime when we no longer support older versions of the x/sys packages.

@florianl
Copy link
Contributor

Thanks for the clarification. I really wasn't sure about x/sys, as I considered x/sys as an external package, "just" in a more controlled manner.

If it helps, I can open a CL against x/sys for GetAuxv() []uintptr using go:linkname.

@ianlancetaylor
Copy link
Contributor

Thanks, may as well wait for the proposal process.

@lmb
Copy link
Contributor

lmb commented Jun 25, 2024

Is the proc file sufficient?

/proc is tricky because it has additional permission checks and interacts with capabilities. See https://dxuuu.xyz/filecaps.html. Using auxv from the runtime really is a lot less error prone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Incoming
Development

No branches or pull requests

7 participants