All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Huggins-Daines <dhd@linuxcare.com>
To: parisc-linux@thepuffingroup.com
Subject: [parisc-linux] ELF loader is badly broken
Date: 17 Jul 2000 19:31:34 -0400	[thread overview]
Message-ID: <87em4swcyx.fsf@linuxcare.com> (raw)

Hi,

Basically it's pure chance that our ELF binary loader works at all.

The reason I say this is that we do not make sure that we actually map
in pages for the initial stack frame containing argc, argv, and
various ELF info, and, since the stack grows upwards while the frame
grows downwards, we often end up spilling over into unmapped memory in
create_elf_tables() when putting the pointers in argv and envp on the
stack.

The reason it actually works at all is that we *do* map these pages
when copying in the actual argc and argv strings, and therefore, if
there happens to be enough space left on the last page of strings (as
there nearly always is if the environment and argument vectors are
short enough and contain small enough strings), we manage to do okay.

I *think* that the reason the code works on other architectures is
that, since both their stacks and stack frames grow downwards, a page
fault in create_elf_tables() will Do The Right Thing by just
allocating more stack space.  Of course I could be totally wrong about
that...

In any case we probably need a special dispensation in the binary
loader code for our up-growing stacks and down-growing frames.  It
seems to me like we can either:

 1) Make a special #ifdef __hppa__ (yuck) in exec.c (or somewhere - I
    don't suppose there are any hooks for this sort of thing ... or
    for that matter any other supported architectures with up-growing
    stacks) to leave enough room for the argv and envp and associated
    bits that get put there by the binfmt stuff.

 2) Make an exception in the page fault handler (or probably in
    expand_stack(), I tried setting the VM_GROWSDOWN flag on it and
    that clearly wasn't enough) to the stack-growing-up-rule for the
    initial stack frame's VMA, for at least as long as it takes us to
    populate it with pointers.

If (2) actually works, it should be the better solution, I think,
because it means we don't have to second-guess the amount of crap the
binary format loaders are going to put on the stack for us.  Someone
who isn't an idiot like me can maybe comment further :-)

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

                 reply	other threads:[~2000-07-17 23:31 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=87em4swcyx.fsf@linuxcare.com \
    --to=dhd@linuxcare.com \
    --cc=parisc-linux@thepuffingroup.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.