Modifica del numero di telefono del sistema linux

Question

Volevo creare il mio kernel personalizzato con una tabella syscall diversa. (stesse syscalls ma in diverse posizioni/numeri)

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?

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

È 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.