Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Ben Pfaff]

Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:

> On Thu, 2003-07-31 16:12:26 +0100, Jamie Lokier <jamie@shareable.org>
> wrote in message <20030731151226.GG6410@mail.jlokier.co.uk>:
> > Alan Cox wrote:
> > > On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> > > > See? It's loaded at the "ls" call, but it seems to be not loaded for
> > > > apt-get.
> > > 
> > > Remember you need to overload signal setting functions like sigaction.
> > > My guess is apt decided to disable your signal and you didnt stop it
> > 
> > An application might install its own SIGILL handler to emulate or trap
> > _other_ instructions.  To do it properly, you have to chain the handlers.
> > 
> > Not sure how to do this, when you get to the stage of two LD_PRELOAD
> > libraries each wanting to overload sigaction.
> 
> That's not (yet) my problem and I think it's not impossible to hook
> them. _But_ before, I need to get called at all _before_ libstdc++5's
> _init(). For now, I haven't managed to do that...

One way to get loaded before anything else is to do ELF binary
loading by hand in userspace.  The kernel exec loads your
program, which sets up trap handlers etc., then loads the actual
target binary by hand.  I did this for an application sandbox.
Writing the loader took less than half a day since I was able to
use a lot of kernel code from binfmt_elf.c directly, just
translating internal kernel calls into open, mmap, etc. system
calls.
-- 
"Note that nobody reads every post in linux-kernel.   In fact, nobody who
 expects to have time left over to  actually do any real kernel work will
 read even half.  Except Alan Cox, but he's actually not human, but about
 a thousand gnomes working in under-ground caves in Swansea." --Linus

Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Martin Schlemmer]

On Thu, 2003-07-31 at 17:33, Jan-Benedict Glaw wrote:
> On Thu, 2003-07-31 17:09:19 +0200, Martin Schlemmer <azarah@gentoo.org>
> wrote in message <1059664158.5031.26.camel@workshop.saharacpt.lan>:
> > On Thu, 2003-07-31 at 15:01, Jan-Benedict Glaw wrote:
> > > On Thu, 2003-07-31 14:14:48 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
> > > wrote in message <20030731121448.GW1873@lug-owl.de>:
> > > > On Thu, 2003-07-31 12:51:09 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk>
> > > > wrote in message <1059652268.16608.8.camel@dhcp22.swansea.linux.org.uk>:
> > > > > On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> > > So there we are. Thanks to someone who pointed me to LD_DEBUG et al., I
> > > see that my _init() is called too late:
> > > 
> > > amtus:~/sigill_catcher# LD_DEBUG=all LD_VERBOSE=1
> > > LD_PRELOAD=./libsigill.so apt-get update 2> ld_infos                                 
> > > Illegal instruction
> > > amtus:~/sigill_catcher# grep 'calling init' ld_infos 
> > > 00691:  calling init: /lib/libc.so.6
> > > 00691:  calling init: /lib/libdl.so.2
> > > 00691:  calling init: /lib/libgcc_s.so.1
> > > 00691:  calling init: /lib/libm.so.6
> > > 00691:  calling init: /usr/lib/libstdc++.so.5
> > > 
> > > As I guessed, libstdc++5's _init() is called before mine (LD_PRELOADed)
> > > _init() function and thus, I cannot intercept this SIGILL, as it
> > > seems...
> > > 
> > 
> > You could do what we do with our path sandbox - basically you
> > use a wrapper that setup the environment (prob not needed in
> > your case), and then spawn bash with our sandbox lib preloaded,
> > which then calls whatever should be 'path sandboxed'.
> 
> Care to send some URL? I haven't found it ad hoc by Google...
> 

http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/src/sandbox-1.1/?cvsroot=gentoo-src


Cheers,

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop Team
Cape Town, South Africa

Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On Thu, 2003-07-31 17:09:19 +0200, Martin Schlemmer <azarah@gentoo.org>
wrote in message <1059664158.5031.26.camel@workshop.saharacpt.lan>:
> On Thu, 2003-07-31 at 15:01, Jan-Benedict Glaw wrote:
> > On Thu, 2003-07-31 14:14:48 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
> > wrote in message <20030731121448.GW1873@lug-owl.de>:
> > > On Thu, 2003-07-31 12:51:09 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk>
> > > wrote in message <1059652268.16608.8.camel@dhcp22.swansea.linux.org.uk>:
> > > > On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> > So there we are. Thanks to someone who pointed me to LD_DEBUG et al., I
> > see that my _init() is called too late:
> > 
> > amtus:~/sigill_catcher# LD_DEBUG=all LD_VERBOSE=1
> > LD_PRELOAD=./libsigill.so apt-get update 2> ld_infos                                 
> > Illegal instruction
> > amtus:~/sigill_catcher# grep 'calling init' ld_infos 
> > 00691:  calling init: /lib/libc.so.6
> > 00691:  calling init: /lib/libdl.so.2
> > 00691:  calling init: /lib/libgcc_s.so.1
> > 00691:  calling init: /lib/libm.so.6
> > 00691:  calling init: /usr/lib/libstdc++.so.5
> > 
> > As I guessed, libstdc++5's _init() is called before mine (LD_PRELOADed)
> > _init() function and thus, I cannot intercept this SIGILL, as it
> > seems...
> > 
> 
> You could do what we do with our path sandbox - basically you
> use a wrapper that setup the environment (prob not needed in
> your case), and then spawn bash with our sandbox lib preloaded,
> which then calls whatever should be 'path sandboxed'.

Care to send some URL? I haven't found it ad hoc by Google...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

On Thu, 2003-07-31 16:12:26 +0100, Jamie Lokier <jamie@shareable.org>
wrote in message <20030731151226.GG6410@mail.jlokier.co.uk>:
> Alan Cox wrote:
> > On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> > > See? It's loaded at the "ls" call, but it seems to be not loaded for
> > > apt-get.
> > 
> > Remember you need to overload signal setting functions like sigaction.
> > My guess is apt decided to disable your signal and you didnt stop it
> 
> An application might install its own SIGILL handler to emulate or trap
> _other_ instructions.  To do it properly, you have to chain the handlers.
> 
> Not sure how to do this, when you get to the stage of two LD_PRELOAD
> libraries each wanting to overload sigaction.

That's not (yet) my problem and I think it's not impossible to hook
them. _But_ before, I need to get called at all _before_ libstdc++5's
_init(). For now, I haven't managed to do that...

My hack^H^H^H^Hsources are at
http://www.lug-owl.de/~jbglaw/software/catch_sigill/ .

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Jamie Lokier]

Alan Cox wrote:
> On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> > Thanks for that. In the meantime, I've started to give a try to the
> > userspace version (using a LD_PRELOAD lib). My current Problem:
> > 
> > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so ls
> > sigill.c:_init():69: sigill started, sigaction() = 0
> > build.sh  intercept.h  libsigill.so  run.sh  sigill.c  sigill.o
> > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so apt-get update
> > Illegal instruction
> > 
> > See? It's loaded at the "ls" call, but it seems to be not loaded for
> > apt-get.
> 
> Remember you need to overload signal setting functions like sigaction.
> My guess is apt decided to disable your signal and you didnt stop it

An application might install its own SIGILL handler to emulate or trap
_other_ instructions.  To do it properly, you have to chain the handlers.

Not sure how to do this, when you get to the stage of two LD_PRELOAD
libraries each wanting to overload sigaction.

-- Jamie

Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Martin Schlemmer]

On Thu, 2003-07-31 at 15:01, Jan-Benedict Glaw wrote:
> On Thu, 2003-07-31 14:14:48 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
> wrote in message <20030731121448.GW1873@lug-owl.de>:
> > On Thu, 2003-07-31 12:51:09 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk>
> > wrote in message <1059652268.16608.8.camel@dhcp22.swansea.linux.org.uk>:
> > > On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> > > > Thanks for that. In the meantime, I've started to give a try to the
> > > > userspace version (using a LD_PRELOAD lib). My current Problem:
> > > > 
> > > > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so ls
> > > > sigill.c:_init():69: sigill started, sigaction() = 0
> > > > build.sh  intercept.h  libsigill.so  run.sh  sigill.c  sigill.o
> > > > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so apt-get update
> > > > Illegal instruction
> > > > 
> > > > See? It's loaded at the "ls" call, but it seems to be not loaded for
> > > > apt-get.
> 
> So there we are. Thanks to someone who pointed me to LD_DEBUG et al., I
> see that my _init() is called too late:
> 
> amtus:~/sigill_catcher# LD_DEBUG=all LD_VERBOSE=1
> LD_PRELOAD=./libsigill.so apt-get update 2> ld_infos                                 
> Illegal instruction
> amtus:~/sigill_catcher# grep 'calling init' ld_infos 
> 00691:  calling init: /lib/libc.so.6
> 00691:  calling init: /lib/libdl.so.2
> 00691:  calling init: /lib/libgcc_s.so.1
> 00691:  calling init: /lib/libm.so.6
> 00691:  calling init: /usr/lib/libstdc++.so.5
> 
> As I guessed, libstdc++5's _init() is called before mine (LD_PRELOADed)
> _init() function and thus, I cannot intercept this SIGILL, as it
> seems...
> 

You could do what we do with our path sandbox - basically you
use a wrapper that setup the environment (prob not needed in
your case), and then spawn bash with our sandbox lib preloaded,
which then calls whatever should be 'path sandboxed'.

Should work with what you do as well, as bash/whatever do not use
c++ code, and when it execute the actual program, your lib should
have hooked into whatever that needs be.


Regards,

-- 
Martin Schlemmer

Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]

On Thu, 2003-07-31 14:14:48 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
wrote in message <20030731121448.GW1873@lug-owl.de>:
> On Thu, 2003-07-31 12:51:09 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk>
> wrote in message <1059652268.16608.8.camel@dhcp22.swansea.linux.org.uk>:
> > On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> > > Thanks for that. In the meantime, I've started to give a try to the
> > > userspace version (using a LD_PRELOAD lib). My current Problem:
> > > 
> > > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so ls
> > > sigill.c:_init():69: sigill started, sigaction() = 0
> > > build.sh  intercept.h  libsigill.so  run.sh  sigill.c  sigill.o
> > > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so apt-get update
> > > Illegal instruction
> > > 
> > > See? It's loaded at the "ls" call, but it seems to be not loaded for
> > > apt-get.

So there we are. Thanks to someone who pointed me to LD_DEBUG et al., I
see that my _init() is called too late:

amtus:~/sigill_catcher# LD_DEBUG=all LD_VERBOSE=1
LD_PRELOAD=./libsigill.so apt-get update 2> ld_infos                                 
Illegal instruction
amtus:~/sigill_catcher# grep 'calling init' ld_infos 
00691:  calling init: /lib/libc.so.6
00691:  calling init: /lib/libdl.so.2
00691:  calling init: /lib/libgcc_s.so.1
00691:  calling init: /lib/libm.so.6
00691:  calling init: /usr/lib/libstdc++.so.5

As I guessed, libstdc++5's _init() is called before mine (LD_PRELOADed)
_init() function and thus, I cannot intercept this SIGILL, as it
seems...

Any useful hints from here?

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]

On Thu, 2003-07-31 12:51:09 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk>
wrote in message <1059652268.16608.8.camel@dhcp22.swansea.linux.org.uk>:
> On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> > Thanks for that. In the meantime, I've started to give a try to the
> > userspace version (using a LD_PRELOAD lib). My current Problem:
> > 
> > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so ls
> > sigill.c:_init():69: sigill started, sigaction() = 0
> > build.sh  intercept.h  libsigill.so  run.sh  sigill.c  sigill.o
> > amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so apt-get update
> > Illegal instruction
> > 
> > See? It's loaded at the "ls" call, but it seems to be not loaded for
> > apt-get.
> 
> Remember you need to overload signal setting functions like sigaction.
> My guess is apt decided to disable your signal and you didnt stop it

I thought about that. Though, strace shows this is straight after ldso
mapped all libs. So apt-get's main() didn't yet start.

amtus:~/sigill_catcher# cat run.sh 
#!/bin/sh

LD_PRELOAD=./libsigill.so apt-get update

amtus:~/sigill_catcher# strace -o xxx -f -ff ./run.sh 
Process 681 attached (waiting for parent)
Process 681 resumed (parent 680 ready)
Process 680 suspended
Process 680 resumed
Process 681 detached
./run.sh: line 3:   681 Illegal instruction LD_PRELOAD=./libsigill.so apt-get update
amtus:~/sigill_catcher# grep -i sig xx* | grep -i ILL
xxx:stat64("/root/sigill_catcher", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
xxx:wait4(-1, [WIFSIGNALED(s) && WTERMSIG(s) == SIGILL], 0, NULL) = 681
xxx.681:open("./libsigill.so", O_RDONLY)        = 3
xxx.681:getcwd("/root/sigill_catcher", 128)     = 21
xxx.681:--- SIGILL (Illegal instruction) @ 0 (0) ---

So my lib gets loaded, but it's _init() function seems to be called too
late (in prior, some parts of libstdc++5 decided to commit suicide).

Looking at the strace, libsigill is the loaded as the very first action.
Then, all the other libs are mapped. It seems that _init()ing them
happens somewhat in reverse order or something like that... I'm a but
hosed in that case:)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Alan Cox]

On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote:
> Thanks for that. In the meantime, I've started to give a try to the
> userspace version (using a LD_PRELOAD lib). My current Problem:
> 
> amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so ls
> sigill.c:_init():69: sigill started, sigaction() = 0
> build.sh  intercept.h  libsigill.so  run.sh  sigill.c  sigill.o
> amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so apt-get update
> Illegal instruction
> 
> See? It's loaded at the "ls" call, but it seems to be not loaded for
> apt-get.

Remember you need to overload signal setting functions like sigaction.
My guess is apt decided to disable your signal and you didnt stop it

Emulating i486 on i386 (was: TSCs are a no-no on i386)

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

On Thu, 2003-07-31 09:17:19 +0200, Willy Tarreau <willy@w.ods.org>
wrote in message <20030731071719.GA26249@alpha.home.local>:
> On Thu, Jul 31, 2003 at 08:22:52AM +0200, Jan-Benedict Glaw wrote:
> > > The 486 emlation patch for 386 is the way to still allow 386's to run 
> > > Debian.
> > 
> > Okay, I'll have a look at it. Where's the 2.6.x version?
> 
> It doesn't exist, but could certainly easily be ported from 2.4.

> So to resume, everything can be done through emulation, but that's probably
> not what we want as a standard for performance reasons. When I have time, I
> may port it to 2.6, but that's not no my priority list.

Thanks for that. In the meantime, I've started to give a try to the
userspace version (using a LD_PRELOAD lib). My current Problem:

amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so ls
sigill.c:_init():69: sigill started, sigaction() = 0
build.sh  intercept.h  libsigill.so  run.sh  sigill.c  sigill.o
amtus:~/sigill_catcher# LD_PRELOAD=./libsigill.so apt-get update
Illegal instruction

See? It's loaded at the "ls" call, but it seems to be not loaded for
apt-get.

I've tried to put the lib's name into /etc/ld.so.preload, but it seems
it's never loaded then (for apt-get, ls is doing fine...):

amtus:~/sigill_catcher# cat /etc/ld.so.preload 
sigill.c:_init():69: sigill started, sigaction() = 0
/root/sigill_catcher/libsigill.so
amtus:~/sigill_catcher# apt-get update
Illegal instruction

Where's the difference? Seems I don't know enough about ld.so...
Any useful hints for me?

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]