This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v2 0/3] posix: Execute file function fixes
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 20 Feb 2016 08:37:34 -0200
- Subject: Re: [PATCH v2 0/3] posix: Execute file function fixes
- Authentication-results: sourceware.org; auth=none
- References: <1455905134-21014-1-git-send-email-adhemerval dot zanella at linaro dot org> <56C75FE3 dot 2030606 at cs dot ucla dot edu> <56C769A9 dot 6080301 at linaro dot org> <56C773F2 dot 5000608 at cs dot ucla dot edu> <55B9700F-CABA-41B9-88BD-0822F85A5DDA at linaro dot org> <56C7A17F dot 3090701 at cs dot ucla dot edu>
> Em 19 de fev de 2016, Ãs 21:13, Paul Eggert <email@example.com> escreveu:
>> On 02/19/2016 12:19 PM, Adhemerval Zanella wrote:
>> And it is a regression only if you consider dynamic allocation an alternative,
> It's a regression in that it would break some applications that currently work. An application that is simple (no signal handling, single-threaded, etc.) can invoke programs with many arguments now, but the same application won't work if that patch is installed.
It is debatable since it is using a non-conforming implementation do to so.
> Come to think of it, execlp, posix_spawn, and posix_spawnp can all use malloc, since POSIX does not require them to be async-signal-safe. So you can go back to using malloc for their implementations, when they are given large argument vectors. The only conformance problem here will be execl and execle.
Execlp can not because since it can be used in following vfork. Posix-spawn can, although In match I noted a mmap area with map_stack to provide a better strategy since it may use a large allocated area only in certain cases.
> For these two, I suggest a machine-dependent implementation, with the default being something along the lines of the attached (this is totally untested, I'm just trying to give the gist).
>> A better strategy would be set either hard limits on stack usage in design phase or to focus on enable GLIBC to use a better stack protection mechanism (preferable through compiler assistance).
> The latter sounds like a good idea, but is a bigger project and I doubt whether we'd want to wait for that project to be finished before fixing the exec-family problems in question.
I agree, but I also do not see a point in rely on faulty stack allocation mechanisms.
Anyway I see with Joseph comments the only missing point is total mmap area of posix_spawn which sets a hard limit for old shell argument handling and posix_spawnp. We can either document these limit or add a logic to calculate total argument list and mmap an area to accommodate all of it.