This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 0/3] posix: Execute file function fixes
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
- Date: Fri, 19 Feb 2016 11:58:42 -0800
- 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>
On 02/19/2016 11:14 AM, Adhemerval Zanella wrote:
I do not agree it is a regression since it fixes two important issues:
exec async-signal-safeness and vfork usage.
Even if a change makes improvements in some ways, the change can still
be a regression in other ways. The proposed change plainly has such
regressions.
the vector of attack might be limited
Agreed. Still, the vector is there.
The current '__libc_use_alloca' is a fragile and arbitrary stack
control flow and since it does not track total stack usage against
runtime imposed limit it does not add anything related to security.
Certainly __libc_use_alloca is an imperfect mechanism. However, if code
touches buffers before going past them, __libc_use_alloca results in
reliable stack overflow protection in the common case where
sufficiently-large guard pages are at the top of the stack. So it's an
exaggeration to say that __libc_use_alloca adds nothing to security.