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.