Date: Tue, 10 Jun 1997 18:26:28 -0700 (PDT)
Message-Id: <199706110126.SAA21249@adit.ap.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: Nate Eldredge <eldredge AT ap DOT net>
Subject: Re: DJGPP runs bogus binaries
Cc: djgpp AT delorie DOT com
Precedence: bulk

At 11:15  6/10/1997 +0300, Eli Zaretskii wrote:
>
>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.
>

Oh, okay. I didn't look at it all that closely before.

>> 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.

Well, here's one fix that could be made and would solve (IMHO) 90% of these
cases:
direct_exec_tail in dosexec.c is the entry point for things that DOS is
going to exec (function 0x4B). A check could be added here that the program
name ends in ".com" or ".exe". A good place to put this might be around line
190, after the TRUENAME call. Any file not ending in these is probably not a
valid DOS executable. In this case, the call could fail and an appropriate
errno be returned. 

I agree that doing an actual check of COM files is impossible. There aren't
any magic numbers to look for. But checking the extension should solve a lot
of problems. And if someone has bogus COM files, they deserve to lose ;-).
It's rather bad as it is though; even trying to spawn() a text file will
cheerfully crash without warning.
>
>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.

I agree.

>
>> 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.
>
Until a fix comes out, a change should be made to the spawnXX docs, 1st para
under "Description", perhaps. In the list of how it runs things (i.e. ".sh"
-> bash, ".bat" -> command.com, etc), it should be noted that any file not
fitting into the above categories will be run directly by DOS. Perhaps with
a big ***CAUTION!!!*** indicator added :-).

Thanks a lot for the help/suggestions.

Nate Eldredge
eldredge AT ap DOT net