[PATCH v2 10/13] posix: Improve thread safety of functions using environ with execveat

[Florian Weimer]

* Cristian Rodríguez:

> On Thu, Nov 28, 2024 at 2:46 PM Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> wrote:
>
>> On 28/11/24 05:22, Florian Weimer wrote:
>>
>> >> Can't we use MADV_DONTFORK here? There still the small windows between
>> >> mmap return and madvise call, but I am not very confident that adding
>> >> a possible unbounded dynamic stack allocation is best way forward
>> >> here.
>> > 
>> > No, the vfork has already happened at this point.  We would need
>> > something to unmap the mapping on a successful execve call.
>>
>> Right, and it is not clear that vfork would always execv*.  I still
>> don't like this stack solution, but I also don't have a better solution.
>
> It is my understanding there isn' t better solution without kernel
> support..  __cleanup__ attribute will not work on this case..or will
> it ? I haven't tried.

Attribute __cleanup__ won't work because on successful execve, the
thread goes away (but not it's mm).

There is an alternative approach: allocate larger buffers with mmap, and
store a pointer to that into the TCB.  Then the vfork-ing thread can
eventually reuse the mapping, or it can be deallocated once that thread
exits.

Reusing the mapping in execve leads to a race between the __getenvarray
snapshotting and the following execve systemcall: another execve
function call can happen from a signal handler, with its own
__getenvarray call.  If the execve system call after that succeeds,
everything is fine, but if it fails and the signal handler returns, we
have overwritten the environment snapshot from the interrupted execve
function call.  But I think the way we document the snapshotting rules,
this is actually fine: any variables that go missing from the
environment due to the overwrite must have been unset.

It's unclear if this is better because it increases complexity
considerably.

Thanks,
Florian