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 [email protected]
Websystems GmbH +49 2234 1840-0 (voice)
Max-Planck-Strasse 2, 50858 Koeln, Germany +49 2234 1840-40 (fax)
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" ;-)
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 [email protected]
Websystems GmbH +49 2234 1840-0 (voice)
Max-Planck-Strasse 2, 50858 Koeln, Germany +49 2234 1840-40 (fax)
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 - [email protected] - http://www.devcon.net
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 [email protected]
Websystems GmbH +49 2234 1840-0 (voice)
Max-Planck-Strasse 2, 50858 Koeln, Germany +49 2234 1840-40 (fax)
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 <[email protected]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/
In article <[email protected]>, 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 [[email protected]]
Heinz-Ado Arnolds <[email protected]> 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
[email protected] 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