From: "Ollie Wild" <aaw@google.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: "Luck, Tony" <tony.luck@intel.com>,
linux-kernel@vger.kernel.org,
parisc-linux@lists.parisc-linux.org, linux-mm@kvack.org,
linux-arch@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
Ingo Molnar <mingo@elte.hu>, Andi Kleen <ak@suse.de>
Subject: Re: [patch 0/3] no MAX_ARG_PAGES -v2
Date: Thu, 14 Jun 2007 13:58:58 -0700 [thread overview]
Message-ID: <65dd6fd50706141358i39bba32aq139766c8a1a3de2b@mail.gmail.com> (raw)
In-Reply-To: <1181810319.7348.345.camel@twins>
> @@ -1385,6 +1401,10 @@ int do_execve(char * filename,
> goto out;
> bprm->argv_len = env_p - bprm->p;
>
> + retval = expand_arg_vma(bprm);
> + if (retval < 0)
> + goto out;
> +
> retval = search_binary_handler(bprm,regs);
> if (retval >= 0) {
> /* execve success */
At this point bprm->argc hasn't been finalized yet. For example, the
script binfmt reads the script header and adds additional arguments.
The flush_old_exec() function is a better place to call this.
I'm not 100% sure this is the right way to handle this, though. The
problem isn't as simple as ensuring the stack doesn't overflow during
argument allocation. We also need to ensure the program has
sufficient stack space to run subsequently. Otherwise, the observable
behavior is identical. Since we can't realistically predict
acceptable stack availability requirements, some amount of uncertainty
is always going to exist. A good heuristic, though, might be to limit
argument size to a percentage (say 25%) of maximum stack size and
validate this inside copy_strings().
Ollie
next prev parent reply other threads:[~2007-06-14 20:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-13 10:03 [patch 0/3] no MAX_ARG_PAGES -v2 Peter Zijlstra
2007-06-13 10:03 ` [patch 1/3] arch: personality independent stack top Peter Zijlstra
2007-06-13 10:03 ` [patch 2/3] audit: rework execve audit Peter Zijlstra
2007-06-26 22:55 ` Andrew Morton
2007-07-03 15:00 ` Peter Zijlstra
2007-06-13 10:03 ` [patch 3/3] mm: variable length argument support Peter Zijlstra
2007-08-07 19:03 ` Olaf Hering
2007-08-07 19:20 ` Andrew Morton
2007-08-07 19:26 ` Peter Zijlstra
2007-08-07 20:10 ` Olaf Hering
2007-08-22 8:48 ` Dan Aloni
2007-08-22 8:54 ` Peter Zijlstra
2007-08-22 9:05 ` Andrew Morton
[not found] ` <20070822090251.GA7038@mail.ustc.edu.cn>
2007-08-22 9:02 ` Fengguang Wu
2007-06-13 23:36 ` [patch 0/3] no MAX_ARG_PAGES -v2 Luck, Tony
2007-06-14 6:23 ` Ollie Wild
2007-06-14 8:38 ` Peter Zijlstra
2007-06-14 18:22 ` Luck, Tony
2007-06-14 18:32 ` Peter Zijlstra
2007-06-14 20:58 ` Ollie Wild [this message]
2007-06-14 21:18 ` Peter Zijlstra
2007-06-15 9:24 ` Peter Zijlstra
2007-06-15 18:07 ` Ollie Wild
2007-06-15 18:49 ` Luck, Tony
2007-06-17 18:32 ` Pavel Machek
2007-06-17 19:07 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65dd6fd50706141358i39bba32aq139766c8a1a3de2b@mail.gmail.com \
--to=aaw@google.com \
--cc=a.p.zijlstra@chello.nl \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).