[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150602234943.GK17573@brightrain.aerifal.cx>
Date: Tue, 2 Jun 2015 19:49:43 -0400
From: Rich Felker <dalias@...ifal.cx>
To: Rob Landley <rob@...dley.net>
Cc: musl@...ts.openwall.com
Subject: Re: Re: Moving forward with sh2/nommu
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
