From: Rich Felker <dalias@aerifal.cx>
To: Rob Landley <rob@landley.net>
Cc: musl@lists.openwall.com
Subject: Re: Re: Moving forward with sh2/nommu
Date: Tue, 2 Jun 2015 19:49:43 -0400 [thread overview]
Message-ID: <20150602234943.GK17573@brightrain.aerifal.cx> (raw)
In-Reply-To: <20150602164547.GH17573@brightrain.aerifal.cx>
On Tue, Jun 02, 2015 at 12:45:47PM -0400, Rich Felker wrote:
> > >> Nooooo. 8k. uClinux programs cannot depend on a huge stack, because that
> > >> means each instance needs to kmalloc() a huge block of memory. That is
> > >> bad, but it leads to failure to load because of fragmentation (not being
> > >> able to find contiguous memory blocks for all those stacks).
> > >
> > > My view here was just that the default, which none was specified while
> > > building the program, should be something "safe". Failed execve
> > > ("oops, need to use the right -Wl,-z,stack-size=XXX") is a lot easier
> > > to diagnose than a stack overflow that clobbers the program code with
> > > stack objects. Right now the default is "always fails to load" because
> > > the kernel explicitly rejects any request for a default.
> >
> > I note that Rich was probably saying he wants the default at 128k for
> > ELF, not for FDPIC. That said, I'm not sure you can have a big enough
> > warning sign about vanilla elf being crappy in that case.
>
> This is unrelated to binary format, so no. It's purely a matter of
> making it possible for apps to work when they're built without adding
> extra CFLAGS or running extra commands to set a stack size for the
> binary. My view here is that an application which was not specifically
> written for NOMMU should run (or fail with a meaningful error like
> ENOMEM) after compiling it with ./configure && make or equivalent
> (i.e. without additional custom CFLAGS that would require
> application-specific knowledge). Getting it working optimally (size,
> memory usage, speed, features, etc.) in your particular environment
> might require more work, of course.
>
> Current behavior is that apps with stacksize==0 fail to run at all;
> the kernel gives a mysterious error from execve (ENOEXEC?) and then
> the shell tries to run the binary as a shell script. Once you
> explicitly set a size, it runs with the size you asked for or fails
> with ENOMEM.
>
> Setting a small default would be much worse than the current behavior;
> rather than getting errors from execve as if the binary were an
> unrecognized format, you'd get massive memory corruption likely to end
> with bringing down the kernel -- the stack overwrites data/code as it
> expands down, then whatever got written over top of the code gets
> executed.
Slides 25-27 from the following, which came up on #musl today, are a
good reason why embedded development environments should never provide
a tiny default stack size:
http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf
Rich
next prev parent reply other threads:[~2015-06-02 23:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 15:11 Rich Felker
2015-06-02 6:09 ` Rob Landley
2015-06-02 16:45 ` Rich Felker
2015-06-02 23:49 ` Rich Felker [this message]
2015-06-10 3:30 ` Rich Felker
2015-06-11 4:02 ` Rob Landley
2015-06-11 15:12 ` Rich Felker
2015-06-11 17:22 ` Rich Felker
2015-06-12 4:26 ` Yoshinori Sato
2015-06-12 4:35 ` Rich Felker
2015-06-12 4:49 ` uClinux.org
2015-06-12 6:37 ` Rich Felker
2015-06-12 6:46 ` D. Jeff Dionne
2015-06-12 4:08 ` Yoshinori Sato
2015-06-12 4:28 ` Rich Felker
2015-06-16 6:38 ` Yoshinori Sato
2015-06-16 7:02 ` Rich Felker
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=20150602234943.GK17573@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
--cc=rob@landley.net \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).