[buyemune-sys]

The problem

A glibc executable that touches environ carries a COPY relocation for it: the executable's .bss holds its own copy of the pointer. solo copies musl's environ value into it once (SH_OBJECT("environ", …), lib/glibc_shim.cpp:4991). From then on there are two variables: the guest reads and writes its own, while musl's getenv/setenv/system/popen use musl's.

As long as the guest leaves environ alone, nothing shows. But setproctitle implementations (nginx, postgres, Tarantool and others) repoint environ to a heap copy and overwrite the original string area with the process title. musl then reads overwritten memory.

Example, in Tarantool after box.cfg{} under solo run:

os.getenv('HOME')   -- nil (natively: /home/...)

Child processes get a garbage environment as well.

The fix

This follows the existing optind/optarg synchronization around getopt (lib/glibc_shim.cpp:1557). Before getenv, setenv, unsetenv, putenv, clearenv, execvp, system, popen and tzset, the bridge pulls the guest's pointer into musl; after the calls that may reallocate the environment, it pushes musl's value back. The guest's copy is looked up as environ or __environ through ElfImage::lookupGlobal. Only a successful lookup is cached, so the library-only case (no guest executable) behaves as before: musl's variable is the ABI.

All of these names are added to overrideNames; otherwise resolution would find musl's functions first.

Test

The guest repoints environ to its own array {"SOLO_GUEST_ENV=repointed", 0} and reads it back through getenv. Needle: guest environ repointed=repointed.

• on main: guest environ repointed=smoke-value. It already fails on the PIE guest, because this toolchain emits a COPY relocation for PIE too;
• with the fix: ./build test passes.