2012-11-30 15 views
6

Volevo creare il mio kernel personalizzato con una tabella syscall diversa. (stesse syscalls ma in diverse posizioni/numeri)Modifica del numero di telefono del sistema linux

Stavo lavorando al kernel 3.2.29.

Modifica del kernel era piuttosto facile:

1) cambiando la posizione syscall in arco/86/kernel/syscall_table_32.S

2) cambiando il numero di macro syscall in arch/x86 /include/asm/unistd_32.h

3) la compilazione e l'installazione del nuovo kernel

ho acceso le chiamate di sistema intorno: sys_open preso il posto e il numero di sys_read, e viceversa.

Ho pensato che se ho compilato glibc con le intestazioni kernel modificate, avrei potuto avere un sistema in esecuzione, ma sfortunatamente, non era abbastanza e il mio sistema non si avviava.

Mi manca qualcosa? Cos'altro devo fare per avere un sistema in esecuzione?


I passi che ho preso sono:

1) costruzione e installazione del kernel, come descritto nella mia interrogazione

2) estrarre i nuovi header del kernel usando make headers_install INSTALL_HDR_PATH=[path]

3) costruzione glibc con il parametro --with-headers=[path/include]

4) Ho usato un cd live per accedere esternamente al file system per Installare il nuovo glibc, utilizzando il make install install_root=[the original file system] (in modo che il sistema non si romperà durante l'installazione)

Mi auguro che il nuovo glibc è stato costruito correttamente, ma non sono sicuro.

Dopo di che, quando si avvia il sistema, lo stivale si ferma in (initrafms) schermo shell: Credo che ho bisogno di ricostruire il initrd, ma come posso compilare in base alla nuova tabella chiamata di sistema?

+0

Si prega di non chiudere le domande sul tema, soprattutto quando hanno upvotes e risposte. –

+0

Perché si dovrebbe farlo? –

+0

@JonasWielicki prima che qualcuno lo "aiutasse" a risolvere il problema, è stato spiegato che questa era una sperimentazione successiva a un incarico scolastico per aggiungere un nuovo syscall. Mentre di dubbia utilità, il cambiamento qui contemplato indubbiamente richiama l'attenzione su come funzionano le cose e ci sono molte dipendenze. Hacking su un sistema da cui nessuno dipende può essere un ottimo modo per imparare le cose. –

risposta

0

Scrambling i numeri di chiamata del sistema è davvero andando a male. Dovrai almeno ricostruire tutti i binari collegati staticamente sul tuo sistema e il tuo initrd (se ne usi uno).

+0

e il codice di avvio in applicazioni di compilazione dinamica potrebbe anche fare una o due syscalls (come exit (2)) –

+0

@tmyklebu Pensate 'glibc' può essere compilato per funzionare sul nuovo sistema, senza usare il nuovo sistema per compilarlo? E se sì, quali sono i passi generali da prendere per farlo? – assafmo

+0

@tmyklebu Volevo avere un sistema di lavoro minimo, quindi ricostruirò solo i binari essenziali collegati staticamente, ma puoi darmi qualche vantaggio su chi ricostruire il initrd per il nuovo sistema? – 4x6hw

0

Non hai ancora detto a che punto il boot fallisce, ma anche se il kernel si avvia, è probabile che i programmi critici contenuti nel ramdisk compresso initrd falliscano perché hanno i numeri syscall originali hardcoded. Avrai bisogno di ricostruire e riconfezionare quelli pure.

Si potrebbe considerare prima la sostituzione di init con un tipo di programma statico hello-world per verificare che il proprio kernel possa supportare uno spazio utente; quindi esaminare i dettagli di rendere tutta la complessità di un moderno spazio utente Linux coincide.

+0

ho modificato la domanda per descrivere meglio il processo e quando l'avvio non riesce – 4x6hw

0

hai dovuto imparare a leggere il caos della discarica pansica e mostrarci quale kenrel panico. Senza queste informazioni, le persone difficilmente possono aiutarti o fornire suggerimenti utili.

1

È necessario ricostruire tutto. Anche se tutti i binari sono collegati dinamicamente, è possibile che le vecchie syscall siano state inserite nel binario perché molte delle funzioni C sono solo return syscall(__NR_somecall,...).

È potrebbe farlo manualmente, ma potrebbe essere difficile mantenere le toolchain dritto a meno che non si utilizza una toolchain compilabile croce come buildroot, aborigena o simili. Scegli quello che preferisci (io preferisco quello aborigeno di Rob Landley - http://landley.net/aboriginal/)

Quindi per rendere il tuo initrd basta espandere quello vecchio usando {z, bz, xz} cat oldinit.rd | ​​cpio -id; rm oldinit.rd. Sostituisci i vecchi moduli del kernel, librerie e librerie con il nuovo e cpio e comprimilo indietro (cpio ha bisogno dell'opzione -H newc) ... oppure ora puoi ricostruire il tuo kernel e puntare l'initramfs in quella directory, ma non lo consiglierei che se il tuo initrd può aver bisogno di essere cambiato frequentemente come se, ad esempio, stavi provando una nuova struttura di syscall e dovessi eseguire il debug molto.

Problemi correlati