From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7865 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Moving forward with sh2/nommu Date: Tue, 2 Jun 2015 19:49:43 -0400 Message-ID: <20150602234943.GK17573@brightrain.aerifal.cx> References: <20150601151107.GA20759@brightrain.aerifal.cx> <20150602164547.GH17573@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1433289018 31647 80.91.229.3 (2 Jun 2015 23:50:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Jun 2015 23:50:18 +0000 (UTC) Cc: musl@lists.openwall.com Bcc: "D. Jeff Dionne" To: Rob Landley Original-X-From: musl-return-7878-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 03 01:50:06 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Yzvwa-00068a-PA for gllmg-musl@m.gmane.org; Wed, 03 Jun 2015 01:50:04 +0200 Original-Received: (qmail 1656 invoked by uid 550); 2 Jun 2015 23:49:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1638 invoked from network); 2 Jun 2015 23:49:57 -0000 Content-Disposition: inline In-Reply-To: <20150602164547.GH17573@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:7865 Archived-At: 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