lkml.org 
[lkml]   [2001]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: fs/exec.c and binfmt-xxx in 2.4.14
On Thu, 22 Nov 2001, Heinz-Ado Arnolds wrote:

> Andreas Ferber wrote:
> >
> > On Wed, Nov 21, 2001 at 05:58:26PM +0100, Heinz-Ado Arnolds wrote:
> > >
> > > When i now try to start an older binary in a.out format, which has a
> > > magic number of 0x010b0064, it is translated with the 'new' code to a
> > > request for "binfmt-0064" instead of "binfmt-267" as expected and
> > > properly handled by modprobe.
> >
> > Then add
> >
> > alias binfmt-0064 binfmt_aout
> >
> > to /etc/modules.conf. Simple, isn't it?
>
> That's a nice idea but I wouldn't rely on the fact that the third
> and the fourth byte of a file are sufficient to identify the type.
> If you look at the magic numbers in /etc/magic, you'll find:
>
> 0x00640107 Linux/i386 impure executable (OMAGIC)
> 0x00640108 Linux/i386 pure executable (NMAGIC)
> 0x0064010b Linux/i386 demand-paged executable (ZMAGIC)
> 0x006400cc Linux/i386 demand-paged executable (QMAGIC)
> =0514 80386 COFF executable
>
> It's standard to count on the first (and eventually following) bytes.
>
> And if you look further on in /etc/magic, you'll see that there are
> other file types having 0x0064 as 3rd and 4th byte.

Note that the 3rd and 4th byte are not used to identify a binary
format, but just to auto-load a possibly available module that can
possibly handle that format. So it doesnt really matter if there are
multiple filetypes causing the load of the same binary handler module.

Richard.

--
Richard Guenther <richard.guenther@uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.076 / U:3.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site