fs/exec.c and binfmt-xxx in 2.4.14

fs/exec.c and binfmt-xxx in 2.4.14

[Heinz-Ado Arnolds]

Hi Linus, Hi Alan, Hi all,

I have a problem with loading modules for binary formats. The
reason for this problem shows up in fs/exec.c search_binary_handler().

Starting with linux-2.1.23 (and up to 2.4.14) there was a change
in the format and offset of printing the magic number for requesting
a handler module. Up to 2.1.22 the statement

    sprintf(modname, "binfmt-%hd", *(unsigned short *)(&bprm->buf[0]));
                              ^^                                 ^^^

was used. Now, and up to 2.4.14, the statement is:

    sprintf(modname, "binfmt-%04x", *(unsigned short *)(&bprm->buf[2]));
                              ^^^                                 ^^^

This leads to a request for loading a module which doesn't exist.
Additionally the request is now done with a hex number but modprobe
expects decimal numbers.

>From modutils-2.4.12/util/alias.h:

    ...
    "binfmt-267 binfmt_aout",
    ...
    "binfmt-332 iBCS",
    ...

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.

Another example: for an old COFF executable with magic number
0x014c0004 the generated request is "binfmt-0004" instead of the
correct value "binfmt-332".

Wouldn't it be appropriate to revert the changes to format "%hd"
and use buffer offset 0 again?

Thanks a lot for your help and many greetings from Cologne, Germany

Ado

-- 
------------------------------------------------------------------------
  Heinz-Ado Arnolds                        Ado.Arnolds@web-systems.net
  Websystems GmbH                              +49 2234 1840-0 (voice)
  Max-Planck-Strasse 2, 50858 Koeln, Germany   +49 2234 1840-40  (fax)

Re: fs/exec.c and binfmt-xxx in 2.4.14

[Martin Dalecki]

Heinz-Ado Arnolds wrote:
> 
> Hi Linus, Hi Alan, Hi all,
> 
> I have a problem with loading modules for binary formats. The
> reason for this problem shows up in fs/exec.c search_binary_handler().
> 
> Starting with linux-2.1.23 (and up to 2.4.14) there was a change
> in the format and offset of printing the magic number for requesting
> a handler module. Up to 2.1.22 the statement

That is a time span of several years during which nobody realized
there was a problem with this. Therefore I would rather
request for removal of the whole binfmt-misc stuff (which is ugly
anyway)
rather then "fixing it" ;-)

Re: fs/exec.c and binfmt-xxx in 2.4.14

[Heinz-Ado Arnolds]

Martin Dalecki wrote:
> 
> Heinz-Ado Arnolds wrote:
> >
> > Hi Linus, Hi Alan, Hi all,
> >
> > I have a problem with loading modules for binary formats. The
> > reason for this problem shows up in fs/exec.c search_binary_handler().
> >
> > Starting with linux-2.1.23 (and up to 2.4.14) there was a change
> > in the format and offset of printing the magic number for requesting
> > a handler module. Up to 2.1.22 the statement
> 
> That is a time span of several years during which nobody realized
> there was a problem with this. Therefore I would rather
> request for removal of the whole binfmt-misc stuff (which is ugly
> anyway)
> rather then "fixing it" ;-)

Not really. I asked for this problem back in 1999 but didn't get any
satisfying response. Since that time me and a lot of my friends are
applying this patch to every new kernel we install. For me and many
other the binfmt interface is a great tool and by far not ugly stuff.

-- 
------------------------------------------------------------------------
  Heinz-Ado Arnolds                        Ado.Arnolds@web-systems.net
  Websystems GmbH                              +49 2234 1840-0 (voice)
  Max-Planck-Strasse 2, 50858 Koeln, Germany   +49 2234 1840-40  (fax)

Re: fs/exec.c and binfmt-xxx in 2.4.14

[Colin Watson]

In article <3BFBDFA5.DDA1CC98@evision-ventures.com>, Martin Dalecki wrote:
>Heinz-Ado Arnolds wrote:
>> I have a problem with loading modules for binary formats. The
>> reason for this problem shows up in fs/exec.c search_binary_handler().
>> 
>> Starting with linux-2.1.23 (and up to 2.4.14) there was a change
>> in the format and offset of printing the magic number for requesting
>> a handler module. Up to 2.1.22 the statement
>
>That is a time span of several years during which nobody realized there
>was a problem with this. Therefore I would rather request for removal
>of the whole binfmt-misc stuff (which is ugly anyway) rather then
>"fixing it" ;-)

This report has nothing to do with binfmt_misc - it's in the main binfmt
code.

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]

Re: fs/exec.c and binfmt-xxx in 2.4.14

[Andreas Ferber]

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?

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net

Re: fs/exec.c and binfmt-xxx in 2.4.14

[Heinz-Ado Arnolds]

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.

I think it would not be a great deal to revert the changes in fs/exec.c

Thanks for your attention

Ado

-- 
------------------------------------------------------------------------
  Heinz-Ado Arnolds                        Ado.Arnolds@web-systems.net
  Websystems GmbH                              +49 2234 1840-0 (voice)
  Max-Planck-Strasse 2, 50858 Koeln, Germany   +49 2234 1840-40  (fax)

Re: fs/exec.c and binfmt-xxx in 2.4.14

[Richard Guenther]

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/

Re: fs/exec.c and binfmt-xxx in 2.4.14

[Andreas Schwab]

Heinz-Ado Arnolds <Ado.Arnolds@dhm-systems.de> writes:

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

Moreover, it is not endian clean.  But that was also true for the old
scheme.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5