Implementation of `dlsym`-based `Weak` is not sandbox-friendly about getrandom HOT 6 CLOSED

The above is an exaggeration because in almost every target architecture, a function pointer will never be 1, and we have const UNINIT: *mut c_void = 1 as *mut c_void; since functions are almost often required to be aligned on even addresses, and also the lowest word of the address space is often reserved for allowing such things.

from getrandom.

Note that #427 changes UNINIT from 1 to usize::MAX. It should make the "inefficient" scenario even less likelier.

from getrandom.

One other thing to note: calling libc::dlsym(RTLD_DEFAULT, ...) (or GetProcAddress on Windows) inside a sandbox probably works just fine, provided the symbol you are looking up has already had its dynamic library loaded. Generally, it's things like libc::dlopen (or LoadLibrary on Windows) which cause issues as they load new code into a process. Things like lazy loading can complicate this, but that generally doesn't apply to libc.

So I think the current implementation is fine, even if the first call to getrandom was within a sandbox. In order to even call dlsym, libc.so will already have to be loaded, so the call to dlsym will either succeed if the symbol is present in libc, or fail otherwise.

from getrandom.

I agree with @josephlr and think that we can close this issue.

from getrandom.