* Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) [not found] ` <fnQP.5bE.5@gated-at.bofh.it> @ 2003-07-31 17:35 ` Ben Pfaff 0 siblings, 0 replies; 10+ messages in thread From: Ben Pfaff @ 2003-07-31 17:35 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* TSCs are a no-no on i386 @ 2003-07-30 13:56 Jan-Benedict Glaw 2003-07-30 18:10 ` Adrian Bunk 0 siblings, 1 reply; 10+ messages in thread From: Jan-Benedict Glaw @ 2003-07-30 13:56 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml Hi! This small patch fixes a long-standing problem for bare i386 CPUs. These don't have TSCs and so, a recent 2.4.x kernel will simply halt the machine leaving a text like "This CPU has no TSC feature (ie was compiled for Pentium+) but I do depend on it". Please apply. Worst to say, even Debian seems to start using i486+ features (ie. libstdc++5 is SIGILLed on Am386 because there's no "lock" insn available)... MfG, JBG --- linux-2.4.22-pre9/arch/i386/config.in.orig 2003-07-30 15:00:27.000000000 +0200 +++ linux-2.4.22-pre9/arch/i386/config.in 2003-07-30 15:01:56.000000000 +0200 @@ -56,6 +56,7 @@ define_bool CONFIG_RWSEM_XCHGADD_ALGORITHM n define_bool CONFIG_X86_PPRO_FENCE y define_bool CONFIG_X86_F00F_WORKS_OK n + define_bool CONFIG_X86_HAS_TSC n else define_bool CONFIG_X86_WP_WORKS_OK y define_bool CONFIG_X86_INVLPG y -- 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)); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 13:56 TSCs are a no-no on i386 Jan-Benedict Glaw @ 2003-07-30 18:10 ` Adrian Bunk 2003-07-30 18:30 ` Mike Fedyk 0 siblings, 1 reply; 10+ messages in thread From: Adrian Bunk @ 2003-07-30 18:10 UTC (permalink / raw) To: lkml On Wed, Jul 30, 2003 at 03:56:23PM +0200, Jan-Benedict Glaw wrote: >... > Please apply. Worst to say, even Debian seems to start using i486+ > features (ie. libstdc++5 is SIGILLed on Am386 because there's no > "lock" insn available)... Shouldn't the 486 emulation in the latest 386 kernel images in Debian unstable take care of this? > MfG, JBG >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 18:10 ` Adrian Bunk @ 2003-07-30 18:30 ` Mike Fedyk 2003-07-30 18:45 ` Adrian Bunk 0 siblings, 1 reply; 10+ messages in thread From: Mike Fedyk @ 2003-07-30 18:30 UTC (permalink / raw) To: Adrian Bunk; +Cc: lkml On Wed, Jul 30, 2003 at 08:10:06PM +0200, Adrian Bunk wrote: > On Wed, Jul 30, 2003 at 03:56:23PM +0200, Jan-Benedict Glaw wrote: > >... > > Please apply. Worst to say, even Debian seems to start using i486+ > > features (ie. libstdc++5 is SIGILLed on Am386 because there's no > > "lock" insn available)... > > Shouldn't the 486 emulation in the latest 386 kernel images in Debian > unstable take care of this? What emulation? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 18:30 ` Mike Fedyk @ 2003-07-30 18:45 ` Adrian Bunk 2003-07-30 20:01 ` Alan Cox 0 siblings, 1 reply; 10+ messages in thread From: Adrian Bunk @ 2003-07-30 18:45 UTC (permalink / raw) To: lkml On Wed, Jul 30, 2003 at 11:30:33AM -0700, Mike Fedyk wrote: > On Wed, Jul 30, 2003 at 08:10:06PM +0200, Adrian Bunk wrote: > > On Wed, Jul 30, 2003 at 03:56:23PM +0200, Jan-Benedict Glaw wrote: > > >... > > > Please apply. Worst to say, even Debian seems to start using i486+ > > > features (ie. libstdc++5 is SIGILLed on Am386 because there's no > > > "lock" insn available)... > > > > Shouldn't the 486 emulation in the latest 386 kernel images in Debian > > unstable take care of this? > > What emulation? 486 emulation CONFIG_CPU_EMU486 When used on a 386, Linux can emulate 3 instructions from the 486 set. This allows user space programs compiled for 486 to run on a 386 without crashing with a SIGILL. As any emulation, performance will be very low, but since these instruction are not often used, this might not hurt. The emulated instructions are: - bswap (does the same as htonl()) - cmpxchg (used in multi-threading, mutex locking) - xadd (rarely used) Note that this can also allow Step-A 486's to correctly run multi-thread applications since cmpxchg has a wrong opcode on this early CPU. Don't use this to enable multi-threading on an SMP machine, the lock atomicity can't be guaranted! Although it's highly preferable that you only execute programs targetted for your CPU, it may happen that, consecutively to a hardware replacement, or during rescue of a damaged system, you have to execute such programs on an inadapted processor. In this case, this option will help you get your programs working, even if they will be slower. It is recommended that you say N here in any case, except for the kernels that you will use on your rescue disks. This option should not be left on by default, because it means that you execute a program not targetted for your CPU. You should recompile your applications whenever possible. If you are not sure, say N. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 18:45 ` Adrian Bunk @ 2003-07-30 20:01 ` Alan Cox 2003-07-30 20:33 ` Jan-Benedict Glaw 0 siblings, 1 reply; 10+ messages in thread From: Alan Cox @ 2003-07-30 20:01 UTC (permalink / raw) To: Adrian Bunk; +Cc: lkml On Mer, 2003-07-30 at 19:45, Adrian Bunk wrote: > Note that this can also allow Step-A 486's to correctly run multi-thread > applications since cmpxchg has a wrong opcode on this early CPU. > > Don't use this to enable multi-threading on an SMP machine, the lock > atomicity can't be guaranted! That is of course the other problem with this approach - you can't really get the intended results without some extremely heavyweight code (using an IPI to halt all CPU's, doing the access and then resuming them) The bigger problem (and certainly with some of the cmov emulation hacks I've seen) is getting the security checking right when you need to reprocess the user data - another reason to do it in userspace with a preload 8) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 20:01 ` Alan Cox @ 2003-07-30 20:33 ` Jan-Benedict Glaw 2003-07-31 0:22 ` Adrian Bunk 0 siblings, 1 reply; 10+ messages in thread From: Jan-Benedict Glaw @ 2003-07-30 20:33 UTC (permalink / raw) To: lkml [-- Attachment #1: Type: text/plain, Size: 1640 bytes --] On Wed, 2003-07-30 21:01:00 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote in message <1059595260.10447.6.camel@dhcp22.swansea.linux.org.uk>: > On Mer, 2003-07-30 at 19:45, Adrian Bunk wrote: > > Note that this can also allow Step-A 486's to correctly run multi-thread > > applications since cmpxchg has a wrong opcode on this early CPU. > > > > Don't use this to enable multi-threading on an SMP machine, the lock > > atomicity can't be guaranted! > > The bigger problem (and certainly with some of the cmov emulation hacks > I've seen) is getting the security checking right when you need to > reprocess the user data - another reason to do it in userspace with a > preload 8) Well... For sure, I can write a LD_PRELOAD lib dealing with SIGILL, but how do I enable it for the whole system. That is, I'd need to give LD_PRELOAD=xxx at the kernel's boot prompt to have it as en environment variable for each and every process? That sounds a tad inelegant to me. Really, I'd prefer to see libstdc++ be compiled for i386 ... ...and IFF those new opcodes bring _that_ much performance, then we should think about another Debian distribution for i686-linux. Up to now, I was really proud of having _one_ distribution that's basically capable of running on all and any machines I own... 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-30 20:33 ` Jan-Benedict Glaw @ 2003-07-31 0:22 ` Adrian Bunk 2003-07-31 6:22 ` Jan-Benedict Glaw 0 siblings, 1 reply; 10+ messages in thread From: Adrian Bunk @ 2003-07-31 0:22 UTC (permalink / raw) To: lkml On Wed, Jul 30, 2003 at 10:33:18PM +0200, Jan-Benedict Glaw wrote: >... > That sounds a tad inelegant to me. Really, I'd prefer to see libstdc++ > be compiled for i386 ... > > ...and IFF those new opcodes bring _that_ much performance, then we > should think about another Debian distribution for i686-linux. Up to > now, I was really proud of having _one_ distribution that's basically > capable of running on all and any machines I own... The 486 emlation patch for 386 is the way to still allow 386's to run Debian. To compile libstdc++ for 486 wasn't a performance question - a libstdc++.so.5 compiled for 386 would have meant that C++ binaries compiled on Debian wouldn't run on other Linux distributions and vice versa [1] (it's a bug in libstdc++ that will AFAIR be fixed in gcc 3.4). > MfG, JBG cu Adrian [1] http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01895.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 0:22 ` Adrian Bunk @ 2003-07-31 6:22 ` Jan-Benedict Glaw 2003-07-31 7:17 ` Willy Tarreau 0 siblings, 1 reply; 10+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 6:22 UTC (permalink / raw) To: lkml [-- Attachment #1: Type: text/plain, Size: 1691 bytes --] On Thu, 2003-07-31 02:22:31 +0200, Adrian Bunk <bunk@fs.tum.de> wrote in message <20030731002230.GE22991@fs.tum.de>: > On Wed, Jul 30, 2003 at 10:33:18PM +0200, Jan-Benedict Glaw wrote: > >... > > That sounds a tad inelegant to me. Really, I'd prefer to see libstdc++ > > be compiled for i386 ... > > > > ...and IFF those new opcodes bring _that_ much performance, then we > > should think about another Debian distribution for i686-linux. Up to > > now, I was really proud of having _one_ distribution that's basically > > capable of running on all and any machines I own... > > 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? > To compile libstdc++ for 486 wasn't a performance question - a > libstdc++.so.5 compiled for 386 would have meant that C++ binaries > compiled on Debian wouldn't run on other Linux distributions and vice > versa [1] (it's a bug in libstdc++ that will AFAIR be fixed in gcc 3.4). I've got no idea when this version will come up. What's the (Debian) timeline for a gcc-3.4 based libstdc++ then? I've already tried gcc-snapshot's libstdc++, but that's libstdc++6, which won't link with todays applications... Well, it's not only that. Seen the thread named like "Time loss on i486"? That'll be some fun, too:) Itching my head, 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: TSCs are a no-no on i386 2003-07-31 6:22 ` Jan-Benedict Glaw @ 2003-07-31 7:17 ` Willy Tarreau 2003-07-31 11:38 ` Emulating i486 on i386 (was: TSCs are a no-no on i386) Jan-Benedict Glaw 0 siblings, 1 reply; 10+ messages in thread From: Willy Tarreau @ 2003-07-31 7:17 UTC (permalink / raw) To: lkml 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. But I think that people want to use it the wrong way. I wrote it to allow older machines to *occasionally* run code designed for the wrong architecture. Eg, your machine dies, you unplug the disk and puts it in another one, a smaller one, and cross your fingers for the system to work again. In this case, I think it's easier to compile a kernel with the right options to allow emulation than to reinstall the system with the proper packages. Now it seems to me that people want to use it as an excuse not to respect architectural constraints and processors instructions sets. Of course, it's easy to compile everything for i686 and think "well, if the machine doesn't support this or that, then the kernel will do...". But you quickly end up in even more slowing down small machines. The other problem lies with the lock : When a 486 executes "LOCK ; CMPXCHG", it locks the bus during the whole cmpxchg instruction. If a 386 executes the same code, it will get an exception which will be caught by the emulator. I don't see how we can do such an atomic operation while holding a lock. At best, we would think about a global memory based shared lock during the operation (eg: int bus_lock;), but it's not implemented at the moment, and will only be compatible with processors sharing the same code. Add-on processors, such as co-processors, transputer cards, or DSPs, will know nothing about such a lock emulation. And it would result in even poorer performance of course ! And yes, I've done intensive benchmarks on the code, as did Denis Vladensko. I used it daily on my 386sx firewall, which avoided me to recompile my pppd for this architecture... At this time, I had a wrong gcc+libc combinations and always got BSWAP instructions all over the code. Although pppd did not suffer from emulation, I have seen other programs which didn't like it at all (gzip or bzip2 for example). CPU intensive programs optimized for i686 which use lots of CMOV for example, need about 400 cycles to do a simple CMOV ! this can slow down things to an order of more than 100 when placed in an inner loop. 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. Cheers, Willy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Emulating i486 on i386 (was: TSCs are a no-no on i386) 2003-07-31 7:17 ` Willy Tarreau @ 2003-07-31 11:38 ` Jan-Benedict Glaw 2003-07-31 11:51 ` Alan Cox 0 siblings, 1 reply; 10+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 11:38 UTC (permalink / raw) To: lkml [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) 2003-07-31 11:38 ` Emulating i486 on i386 (was: TSCs are a no-no on i386) Jan-Benedict Glaw @ 2003-07-31 11:51 ` Alan Cox 2003-07-31 12:14 ` Jan-Benedict Glaw 2003-07-31 15:12 ` Jamie Lokier 0 siblings, 2 replies; 10+ messages in thread From: Alan Cox @ 2003-07-31 11:51 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: lkml 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) 2003-07-31 11:51 ` Alan Cox @ 2003-07-31 12:14 ` Jan-Benedict Glaw 2003-07-31 13:01 ` Jan-Benedict Glaw 2003-07-31 15:12 ` Jamie Lokier 1 sibling, 1 reply; 10+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 12:14 UTC (permalink / raw) To: lkml [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) 2003-07-31 12:14 ` Jan-Benedict Glaw @ 2003-07-31 13:01 ` Jan-Benedict Glaw 2003-07-31 15:09 ` Martin Schlemmer 0 siblings, 1 reply; 10+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 13:01 UTC (permalink / raw) To: lkml [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) 2003-07-31 13:01 ` Jan-Benedict Glaw @ 2003-07-31 15:09 ` Martin Schlemmer 2003-07-31 15:33 ` Jan-Benedict Glaw 0 siblings, 1 reply; 10+ messages in thread From: Martin Schlemmer @ 2003-07-31 15:09 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: LKML 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) 2003-07-31 15:09 ` Martin Schlemmer @ 2003-07-31 15:33 ` Jan-Benedict Glaw 2003-08-01 5:37 ` Martin Schlemmer 0 siblings, 1 reply; 10+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 15:33 UTC (permalink / raw) To: LKML [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) 2003-07-31 15:33 ` Jan-Benedict Glaw @ 2003-08-01 5:37 ` Martin Schlemmer 0 siblings, 0 replies; 10+ messages in thread From: Martin Schlemmer @ 2003-08-01 5:37 UTC (permalink / raw) To: Jan-Benedict Glaw; +Cc: LKML 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) 2003-07-31 11:51 ` Alan Cox 2003-07-31 12:14 ` Jan-Benedict Glaw @ 2003-07-31 15:12 ` Jamie Lokier 2003-07-31 15:32 ` Jan-Benedict Glaw 1 sibling, 1 reply; 10+ messages in thread From: Jamie Lokier @ 2003-07-31 15:12 UTC (permalink / raw) To: Alan Cox; +Cc: Jan-Benedict Glaw, lkml 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) 2003-07-31 15:12 ` Jamie Lokier @ 2003-07-31 15:32 ` Jan-Benedict Glaw 0 siblings, 0 replies; 10+ messages in thread From: Jan-Benedict Glaw @ 2003-07-31 15:32 UTC (permalink / raw) To: lkml [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-08-01 5:41 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <f41P.374.9@gated-at.bofh.it> [not found] ` <f4bw.3eu.13@gated-at.bofh.it> [not found] ` <f5Az.4tG.3@gated-at.bofh.it> [not found] ` <f5TZ.4Hq.11@gated-at.bofh.it> [not found] ` <f9uz.Ll.5@gated-at.bofh.it> [not found] ` <ff6X.6qi.3@gated-at.bofh.it> [not found] ` <ffTk.734.15@gated-at.bofh.it> [not found] ` <fk6A.241.7@gated-at.bofh.it> [not found] ` <fkgp.2aL.29@gated-at.bofh.it> [not found] ` <fnnW.4QQ.43@gated-at.bofh.it> [not found] ` <fnQP.5bE.5@gated-at.bofh.it> 2003-07-31 17:35 ` Emulating i486 on i386 (was: TSCs are a no-no on i386) Ben Pfaff 2003-07-30 13:56 TSCs are a no-no on i386 Jan-Benedict Glaw 2003-07-30 18:10 ` Adrian Bunk 2003-07-30 18:30 ` Mike Fedyk 2003-07-30 18:45 ` Adrian Bunk 2003-07-30 20:01 ` Alan Cox 2003-07-30 20:33 ` Jan-Benedict Glaw 2003-07-31 0:22 ` Adrian Bunk 2003-07-31 6:22 ` Jan-Benedict Glaw 2003-07-31 7:17 ` Willy Tarreau 2003-07-31 11:38 ` Emulating i486 on i386 (was: TSCs are a no-no on i386) Jan-Benedict Glaw 2003-07-31 11:51 ` Alan Cox 2003-07-31 12:14 ` Jan-Benedict Glaw 2003-07-31 13:01 ` Jan-Benedict Glaw 2003-07-31 15:09 ` Martin Schlemmer 2003-07-31 15:33 ` Jan-Benedict Glaw 2003-08-01 5:37 ` Martin Schlemmer 2003-07-31 15:12 ` Jamie Lokier 2003-07-31 15:32 ` Jan-Benedict Glaw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).