>Number:         4939
>Category:       bin
>Synopsis:       mips ELF magic numbers incorrectly assume big-endian host CPU
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb  4 18:35:00 1998
>Last-Modified:
>Originator:     Jonathan Stone
>Organization:
	
>Release:        NetBSD 1.3 (stock)
>Environment:
	
System: NetBSD Reno.DSG.Stanford.EDU 1.3 NetBSD 1.3 (GENERIC) #2: Tue Dec 30 01:16:36 PST 1997 jonathan@Reno.DSG.Stanford.EDU:/reno/compile/GENERIC pmax


>Description:

The file(1) magic-number database contains several byteorder-dependent
encodings for MIPS binaries.  The entries appear correct for running
on a big-endian MIPS cpu -- the source of the entries - but produce
obvbiously incorrect answers on a little-endian MIPS cpu.

Particularly obnoxious is that little-endian MIPS binaries are misreported
by  file(1) running on a little-endian MIPS binary.

This is (understandably) causing woe and confusion to pmax users,
especially first-time users of NetBSD/pmax 1.3.



>How-To-Repeat:

To show the problems with dynamic binary, ,static binary, and a shared
library, running on a pmax:

  file /usr/bin/file; file /bin/date;  file /usr/lib/libc.so.12.20
  /usr/bin/file: ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order, version 1
  /bin/date: ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order, version 1
  /usr/lib/libc.so.12.20: ELF 32-bit LSB shared object, MIPS R3000_BE - invalid byte order, version 1


On an i386, running the i386 file(8) command over pmax binaries gives
the same result.

I'm assuming that /usr/share/misc/magic gives the right results on a
NetBSD/pmax ELF binary when run on a big-endian machine, but I dont
thave one around to verify that.


>Fix:

Correct the byteorder bugs in the mips entries in the
/usr/share/misc/magic stanza for ELF files, so that the mips CPU
entries work properly when run on little-endian machines, as well as
on big-endian.  This may be as simple as permuting the entries, or 

The obvious way to do this is to use byte-by-byte examiniation, to
avoid invalid assumptions about endian-ness of the host CPU doing the
examination.

See also my earlier PR on a similar bug in ECOFF encoding in the magic
database.
>Audit-Trail:
>Unformatted: