🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: ch.comp.os.linux
Article #12518

Re: Pruefen von symbolische links

#12518
From: Roberto Nibali
Date: Sat, 14 Jul 2001 12:47
136 lines
6222 bytes
Addendum:

> Das ist wohl richtig so, aber dennoch ist der Compiler nicht im kernel
> space ausser das OS unterstuetzt processor-task affinities. Der compiler
> task ist dann an eine CPU gebunden und laeuft als task uninterruptable.
> main pgm kann schon umgewandelt werden, wenn man einen temporaeren
> TLB pool generiert, der nicht vom qcc ILE compiler aquiriert wird.

Hey, ich glaube, ich habe einen Weg gefunden, wie man doch einen Compiler
im Kernel haben koennte. Also, im Prinzip funktioniert es, wie beim Viren
schreiben unter Linux (nicht sehr bekannt). Das Prinzip liegt das Problem
darin, dass man einen jump ins cr0 (0xC0000000) machen muss, und das ge-
schieht, indem man eine Trap oder Call GATE benutzt und den IDT im Ring-0
selector veraendert, dass er auf alle memory segmente Schreibberrechtigung
hat. Dies kann man gemaess "Intel Architecture Manual" durch das setzen
des WP bits [ich weiss jedoch nicht, was in einem page fault mit der GOT
passiert, aber wenn's Euch interessiert, schaut unter ../linux/arch/i386/\
kernel/head.S nach] erreichen. So, das ist eigentlich schon die halbe
Anleitung, um einen Virus unter Linux zu schreiben. Leider funktioniert
es _nicht_! Ja, ich kenne den code von allen sogennanten Linux "Viren",
aber das sind alles keine richtigen polymorphen Viren, sondern haeufig
nur lokale Infektoren, nicht per-process resident und die cavity infection
ist beschraenkt auf ELF pointer infection und PLT redirection. Das ist
eigentlich der einzig wahre Unterschied, weshalb Viren unter Linux nur
im process space des callers funktionieren [ok, dies kann verheerende
Folgen haben, wenn man NFS faehrt :) ]. 

Bei dem Microschrot OS (DOS, Win *, including XP) kann man vom user space
aus beliebige jumps via trap gate in den cr0 machen und man hat den 
kompletten virtuellen Addressbereich des OS zum Ueberschreiben zur Ver-
fuegung.

Sorry, ich bin ein wenig mit meinen Erklaerungen vom Weg geraten, aber
im Prinzip koennte ein Compiler im Kernel wie ein Virus funktionieren.
Ich habe mich heute Nacht mal im Plan9 kernel source code rumgeschaut
und dort interessante ideen gefunden. Wenn man diese mit dem kernel monte
projekt mixt, dann wuerde das evt. funktionieren, aber hoechstens fuer
UP.

Beispiel (fuer einen syscall/library call 0.Ordnung):

/* 
 * This could be a part of the gcc kernel module 
 * 
 * stupid non-working preprocessing syscall -> int80 baschtel
 *
 * GPLv2 :) 
 * (c) Roberto Nibali, ratz, 2001 
 *
 */

scan_PGI_table() {
  unsigned long PGI_table;
  __asm("
	movl %cr3, %eax
	movl %eax, (PGI_table)
	movl %cr0, %eax
	movl %eax, (r_cr0)	 # Hello Mr. B. Gates, are you unhappy :)
	movl %cr4, %eax
	movl %eax, (r_cr4)
  ");
}

scall_2_pS() {
asm ("
.text
.align  8
.L__scall:
        scall
        hlt
.align  8
");

#define scall_0(n)                      ({      \
  int ret;                                      \
    asm volatile ("                             \
        pushl   %%ebp                           \n\
        movl    %%esp,%%ebp                     \n\
        call    .L__scall                       \n\
        popl    %%ebp"                          \
        : "=a"(ret)                             \
        : "a"(n)                                \
        : "ecx","edx");                         \
    ((unsigned int)ret<=0xfffff000) ? ret :     \
       (__set_errno(-ret), ret=-1);     })
}

static void cleanup_scall_up (void *info){
   asm volatile ("
        xorl    %%eax,%%eax
        xorl    %%edx,%%edx
        movl    $0x174,%%ecx
        wrmsr
        movl    $0x175,%%ecx
        wrmsr
        movl    $0x176,%%ecx
        wrmsr"
        : : : "eax","ecx","edx"
        );
}

/* [... lots of other functions :)] */

cleanup_module(){
     cleanup_scall_up();
}
init_module(){
     scan_PGI_table();
     preprocessor();
     scall_2_pS();
     compile_LDT_save();
     be_happy();
}

Das laeuft nicht, aber ist so etwas wie eine Denkhilfe. Also, Juerg, Adrian,
so koennte das mit einem Compiler funktionieren. oups, zusaetzlich muesste 
man den kernel_thread noch atomic daemonizen (ich glaube CLONE_VM) und eine
realtime prio queue fuer den kernel_thread geben, sonst ist der scheduler zu
fair und das Programm wird nie fertig mit kompilieren.

Ja, ja, es gibt allerhand, was die Leute so in den Kernel reinbasteln wollen.
Letzthin kam mir einer mit der Idee xml!! also Ausgabeformat fuer das proc-fs
zu machen. Er hat jetzt eine neue email Adresse :)

Sorry fuer das lange posting und dann erst noch aus google heraus, aber ich
kann im Moment meine Mails nicht von tac.ch abrufen, da wir intern mal wieder
die security policy erhoeht haben und am Wochenende arbeite ich selten in
der Firma.

So und nun weg von den Kernel Sourcen und vorbereiten fuer's UG, dort ist
heute naemlich ein alter Kumpel von mir, Richard Dorfmeister und wird
ziemlich geilen ambient, drum'n'bass chillout Sound auflegen. Vielleicht
sieht man sich ja,

Gruss,
Roberto Nibali, ratz
Technical Details
Message-ID: <1a8eeef9.0107140447.78f9c607@posting.google.com>
Path: arc1-ca.pugleaf.net!archiver1.google.com!newsfeed.google.com!postnews1.google.com!not-for-mail
References: <3B441847.381424C4@siemens.ch> <20010705.094055.1139901474.927@fortytwo.ch> <3B441B92.6E4CCE2B@tac.ch> <20010705.103137.1139901474.1150@fortytwo.ch> <3B442EB4.4BCBFA34@siemens.ch> <20010705.125342.2027907669.1150@fortytwo.ch> <3B4449C2.6C21CB27@tac.ch> <3B46A078.BC7CE71A@mails.ch> <3B4AC52B.FD40F294@tac.ch>

Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII-7-bit
X-Google-Thread: f4b73,67e615da96b01c88
X-Google-Attributes: gidf4b73,public
X-Google-ArrivalTime: 2001-07-14 05:48:00 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!newsfeed.google.com!postnews1.google.com!not-for-mail
From: drugphish@yahoo.com (Roberto Nibali)
Newsgroups: ch.comp.os.linux
Subject: Re: Pruefen von symbolische links
Date: 14 Jul 2001 05:47:59 -0700
Organization: http://groups.google.com/
Lines: 136
Message-ID: <1a8eeef9.0107140447.78f9c607@posting.google.com>
References: <3B441847.381424C4@siemens.ch> <20010705.094055.1139901474.927@fortytwo.ch> <3B441B92.6E4CCE2B@tac.ch> <20010705.103137.1139901474.1150@fortytwo.ch> <3B442EB4.4BCBFA34@siemens.ch> <20010705.125342.2027907669.1150@fortytwo.ch> <3B4449C2.6C21CB27@tac.ch> <3B46A078.BC7CE71A@mails.ch> <3B4AC52B.FD40F294@tac.ch>
NNTP-Posting-Host: 212.90.196.233
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 995114879 20135 127.0.0.1 (14 Jul 2001 12:47:59 GMT)
X-Complaints-To: groups-support@google.com
NNTP-Posting-Date: 14 Jul 2001 12:47:59 GMT