Make it possible to selectively use libc for param mod
#382
Comments
|
Thanks for the report! use-libc is a reasonable workaround. I'll look into ways we could implement this. |
sunfishcode
added a commit
that referenced
this issue
Jul 20, 2022
In the linux_raw backend, switch from using a `.init_array` constructor for obtaining the aux values to reading them from /proc/self/auxv. This avoids problems in situation where other Rust code can run before the constructor, potentially distrupting the `__environ` value. Also, for the linux_raw backend, introduce a new "use-libc-auxv" feature, which enables use of libc to read the aux values, instead of reading them from /proc/self/auxv. The "use-libc-auxv" option is enabled by default, because it's more efficient and doesn't depend on /proc, so it's likely better for most users. Mustang, for its part, continues to be able to use the incoming auxv on the stack because it controls program startup. Since it doesn't have to worry about the hazards of /proc or QEMU, it can trust the incoming values, and do less checking. Fixes #382.
|
I've now posted #385 with a fix for this. |
|
Wow, what a quick turn around. Thank you so much @sunfishcode! |
sunfishcode
added a commit
that referenced
this issue
Jul 26, 2022
In the linux_raw backend, switch from using a `.init_array` constructor for obtaining the aux values to reading them from /proc/self/auxv. This avoids problems in situation where other Rust code can run before the constructor, potentially distrupting the `__environ` value. Also, for the linux_raw backend, introduce a new "use-libc-auxv" feature, which enables use of libc to read the aux values, instead of reading them from /proc/self/auxv. The "use-libc-auxv" option is enabled by default, because it's more efficient and doesn't depend on /proc, so it's likely better for most users. Mustang, for its part, continues to be able to use the incoming auxv on the stack because it controls program startup. Since it doesn't have to worry about the hazards of /proc or QEMU, it can trust the incoming values, and do less checking. Fixes #382.
sunfishcode
added a commit
that referenced
this issue
Aug 8, 2022
* Switch from `.init_array` constructors to /proc/self/auxv. In the linux_raw backend, switch from using a `.init_array` constructor for obtaining the aux values to reading them from /proc/self/auxv. This avoids problems in situation where other Rust code can run before the constructor, potentially distrupting the `__environ` value. Also, for the linux_raw backend, introduce a new "use-libc-auxv" feature, which enables use of libc to read the aux values, instead of reading them from /proc/self/auxv. The "use-libc-auxv" option is enabled by default, because it's more efficient and doesn't depend on /proc, so it's likely better for most users. Mustang, for its part, continues to be able to use the incoming auxv on the stack because it controls program startup. Since it doesn't have to worry about the hazards of /proc or QEMU, it can trust the incoming values, and do less checking. Fixes #382. * Remove the param `init` function from the libc backend. * Fix the no-std build. * Fix the backends test to accept that the default options now depend on libc. * Use `NonNull` in `check_raw_pointer`'s return type. This allows it to pack the return value into a single pointer-sized value. * Update more code to the new `check_raw_pointer` API. * Fix an unused-import warning. * Fix copy+paste. * Thread `check_elf_base` through `check_vdso_base` too.
|
This is now released in 0.35.9. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the
linux_rawbackend, theparammodule must be loaded before any user-defined constructor functions. In our use case we are building a Ruby native gem, and cannot assure that our dylib is loaded early enough, so we end up failing this assertion.This can be fixed by using the
use-libc, but that also means we lose the benefits of Rust implementation (inlining, etc.) for other parts of this crate. Would it be possible to opt-in to just using libc for the justparammodule (something likeuse-libc-param)?The text was updated successfully, but these errors were encountered: