Date:	Tue, 10 Jun 1997 11:15:37 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Nate Eldredge <eldredge AT ap DOT net>
cc:	djgpp AT delorie DOT com
Subject:	Re: DJGPP runs bogus binaries
In-Reply-To:	<199706092327.QAA04931@adit.ap.net>
Message-ID:	<Pine.SUN.3.91.970610111326.3067P-100000@is>
MIME-Version:	1.0

On Mon, 9 Jun 1997, Nate Eldredge wrote:

> I spent hours suspecting a bug in Make before finding a Linux ELF binary in
> the directory of something I was trying to port. Make would try to run it,
> it would be run (!) and of course crash. (As an aside, it *completely*
> wedged the system, requiring cold boot. Isn't protected mode supposed to
> prevent this?)

You are missing the real reason for the crash: it's DOS that generates
the exception, not Make.  DJGPP doesn't do anything special to invoke
what seems to be a non-DJGPP program, it just calls the DOS Exec
function.  It's the responsibility of the OS to decide whether a given
file is an executable and how it should be run, but DOS only knows
about .EXE files with their "MZ" signature, and assumes that
everything else is a .COM-style image.  So it loads your ELF file,
jumps to location 100h and promptly departs to the never-never land.
Since DOS is real-mode code, you don't get any protection.

> I notice a comment in the source (src/libc/dos/process/dosexec.c) indicating
> that this is a known problem. Perhaps some effort should be put into fixing
> it. It doesn't seem that difficult; there are presumably magic numbers and
> such to check for.

It might be a good idea to add more safeguards if they don't bloat the
code too much.  It would be swell if you could write the additional
code and post it.  I don't know anything about magic numbers beyond
what's already in `dosexec' (for those formats that DJGPP supports),
and nobody else seems to be willing to mess with that code.  The
comments there that point to issues which should be fixed are for
those who know how to fix them without rewriting major parts of the
OS; I don't.

Please also note that DJGPP's `spawn' and `system' don't skip any
tests (AFAIK) in this context that other compilers do: all of them
rely on DOS to figure out how the program should be invoked.  A C
library can cover up a basic OS deficiency only up to a point.

> or at *least* if this problem could be documented better.

Could you please review the docs of `system' and `spawnXX' family and
suggest where the docs should be amended?  Thanks.

- Raw text -