Un sistema operativo inserisce il proprio codice macchina quando si apre un programma?

Sto studiando CPU e so come legge un programma dalla memoria ed eseguo le sue istruzioni. Capisco anche che un sistema operativo separa i programmi nei processi, e quindi si alternano tra loro così velocemente che pensi che siano in esecuzione contemporaneamente, ma in realtà ogni programma funziona da solo nella CPU. Ma, se il sistema operativo è anche un gruppo di codice in esecuzione nella CPU, come può gestire i processi?

Ho pensato e l'unica spiegazione che ho potuto pensare è: quando il sistema operativo carica un programma dalla memoria esterna alla RAM, aggiunge le sue istruzioni nel mezzo delle istruzioni del programma originale, quindi il programma viene eseguito, il programma può chiamare il sistema operativo e fare alcune cose. Credo che ci sia un'istruzione che il sistema operativo aggiungerà al programma, che consentirà alla CPU di tornare al codice del sistema operativo qualche volta. Inoltre, credo che quando il sistema operativo carica un programma, controlla se ci sono alcune istruzioni proibite (che salterebbero a indirizzi proibiti nella memoria) ed elimina quindi.

Sto pensando al rigth? Non sono uno studente CS, ma in realtà uno studente di matematica. Se possibile, vorrei un buon libro su questo, perché non ho trovato nessuno che spieghi come il sistema operativo può gestire un processo se il sistema operativo è anche un gruppo di codice in esecuzione nella CPU e non può funzionare allo stesso orario del programma. I libri dicono solo che il sistema operativo può gestire le cose, ma ora come.

No. Il sistema operativo non scherza con il codice del programma iniettando nuovo codice in esso. Ciò avrebbe una serie di svantaggi.

1. Sarebbe dispendioso in termini di tempo, poiché il sistema operativo dovrebbe eseguire la scansione dell'intero eseguibile apportando le sue modifiche. Normalmente, parte dell'eseguibile viene caricata solo se necessario. Inoltre, l'inserimento è costoso in quanto è necessario spostare un sacco di roba di mezzo.

2. A causa dell'indecidibilità del problema di arresto, è impossibile sapere dove inserire le istruzioni "Torna al sistema operativo". Ad esempio, se il codice include qualcosa del genere while (true) {i++;}, devi sicuramente inserire un hook all'interno di quel loop ma la condizione sul loop ( true, qui) potrebbe essere arbitrariamente complicata, quindi non puoi decidere per quanto tempo deve passare. D'altra parte, sarebbe molto inefficiente inserire hook in ogni loop: ad esempio, tornare indietro al sistema operativo durante for (i=0; i<3; i++) {j=j+i;}rallenterebbe molto il processo. E, per lo stesso motivo, non è possibile rilevare loop brevi per lasciarli soli.

3. A causa dell'indecidibilità del problema di arresto, è impossibile sapere se le iniezioni di codice hanno cambiato il significato del programma. Ad esempio, supponiamo di utilizzare i puntatori a funzione nel programma C. L'iniezione di un nuovo codice sposterebbe le posizioni delle funzioni, quindi, quando ne chiamavi una tramite il puntatore, saltavi nel posto sbagliato. Se il programmatore fosse abbastanza malato da usare i salti calcolati, anche quelli fallirebbero.

4. Giocherebbe un inferno allegro con qualsiasi sistema anti-virus, poiché cambierebbe anche il codice del virus e rovinerebbe tutti i tuoi checksum.

È possibile aggirare il problema del problema di arresto simulando il codice e inserendo hook in qualsiasi ciclo che viene eseguito più di un determinato numero di volte. Tuttavia, ciò richiederebbe una simulazione estremamente costosa dell'intero programma prima che gli fosse permesso di eseguire.

In realtà, se si desidera iniettare codice, il compilatore sarebbe il posto naturale per farlo. In questo modo, dovresti farlo una sola volta, ma non funzionerebbe ancora per il secondo e il terzo motivo indicati sopra. (E qualcuno potrebbe scrivere un compilatore che non ha funzionato insieme.)

Esistono tre modi principali in cui il sistema operativo riprende il controllo dai processi.

1. Nei sistemi cooperativi (o non preventivi), esiste una yieldfunzione che un processo può chiamare per restituire il controllo al sistema operativo. Naturalmente, se questo è il tuo unico meccanismo, fai affidamento sui processi che si comportano bene e un processo che non produce cederà la CPU fino a quando non termina.

2. Per evitare questo problema, viene utilizzato un interrupt del timer. Le CPU consentono al sistema operativo di registrare i callback per tutti i diversi tipi di interruzioni implementate dalla CPU. Il sistema operativo utilizza questo meccanismo per registrare un callback per un interrupt timer che viene attivato periodicamente, il che gli consente di eseguire il proprio codice.

3. Ogni volta che un processo tenta di leggere da un file o interagire con l'hardware in qualsiasi altro modo, chiede al sistema operativo di fare un lavoro per esso. Quando viene richiesto al sistema operativo di eseguire qualcosa da un processo, può decidere di mettere in attesa quel processo e iniziare a eseguirne uno diverso. Questo potrebbe sembrare un po 'machiavellico, ma è la cosa giusta da fare: l'I / O del disco è lento, quindi puoi anche far funzionare il processo B mentre il processo A è in attesa che i grumi rotanti di metallo si spostino nel posto giusto. L'I / O di rete è ancora più lento. L'I / O della tastiera è glaciale perché le persone non sono esseri gigahertz.

Mentre la risposta di David Richerby è buona, fa una specie di smalto su come i moderni sistemi operativi fermano i programmi esistenti. La mia risposta dovrebbe essere accurata per l'architettura x86 o x86_64, che è l'unica comunemente utilizzata per desktop e laptop. Altre architetture dovrebbero avere metodi simili per raggiungere questo obiettivo.

All'avvio del sistema operativo, imposta una tabella di interrupt. Ogni voce della tabella punta a un po 'di codice all'interno del sistema operativo. Quando si verificano interruzioni, che è controllato dalla CPU, esamina questa tabella e chiama il codice. Esistono vari interrupt, come la divisione per zero, il codice non valido e alcuni definiti dal sistema operativo.

Questo è il modo in cui il processo utente parla al kernel, come se volesse leggere / scrivere sul disco o qualcos'altro che il kernel del sistema operativo controlla. Un sistema operativo imposterà anche un timer che chiama un interruzione al termine, quindi il codice in esecuzione viene forzatamente modificato dal programma utente al kernel del sistema operativo e il kernel può fare altre cose come mettere in coda altri programmi per l'esecuzione.

Dalla memoria, quando ciò accade, il kernel del sistema operativo deve salvare dove si trovava il codice e quando il kernel ha finito di fare ciò che deve fare ripristina lo stato precedente del programma. Quindi il programma non sa nemmeno che è stato interrotto.

Il processo non può modificare la tabella degli interrupt per due motivi, il primo è che è in esecuzione in un ambiente protetto, quindi se tenta di chiamare un determinato codice assembly protetto, la CPU attiverà un altro interrupt. Il secondo motivo è la memoria virtuale. La posizione della tabella degli interrupt è compresa tra 0x0 e 0x3FF nella memoria reale, ma con i processi utente tale posizione di solito non è mappata e il tentativo di leggere la memoria non mappata attiverà un altro interrupt, quindi senza la funzione protetta e la possibilità di scrivere nella RAM reale , il processo utente non può modificarlo.

Il kernel del sistema operativo ottiene il controllo dal processo in esecuzione a causa del gestore di interruzione del clock della CPU, non iniettando codice nel processo.

Dovresti leggere gli interrupt per ottenere maggiori chiarimenti su come funzionano e su come i kernel del sistema operativo li gestiscono e implementano diverse funzionalità.

V'è un metodo simile a ciò che si descrive: multitasking cooperativo . Il sistema operativo non inserisce istruzioni, ma ogni programma deve essere scritto per chiamare le funzioni del sistema operativo che possono scegliere di eseguire un altro dei processi cooperativi. Questo ha gli svantaggi che descrivi: un arresto anomalo del programma elimina l'intero sistema. Windows fino a 3.0 incluso funzionava così; 3.0 in "modalità protetta" e versioni successive no.

Il multitasking preventivo (il tipo normale in questi giorni) si basa su una fonte esterna di interruzioni. Gli interrupt sovrascrivono il normale flusso di controllo e di solito salvano i registri da qualche parte, quindi la CPU può fare qualcos'altro e quindi riprendere in modo trasparente il programma. Ovviamente, il sistema operativo può modificare il registro "quando lasci gli interrupt riprendi qui", quindi riprende all'interno di un processo diverso.

(Alcuni sistemi fanno istruzioni di riscrittura in modo limitato sul caricamento del programma, chiamato "thunking", e il processore Transmeta dinamicamente ricompilati per il proprio set di istruzioni)

Il multitasking non richiede nulla di simile all'iniezione di codice. In un sistema operativo come Windows, esiste un componente del codice del sistema operativo chiamato scheduler che si basa su un interrupt di processo attivato da un timer hardware. Questo viene utilizzato dal sistema operativo per passare da un programma all'altro e a se stesso, facendo sembrare che la nostra percezione umana avvenga contemporaneamente.

Fondamentalmente, il sistema operativo programma il timer hardware per spegnersi ogni tanto ... forse 100 volte al secondo. Quando il timer si spegne, genera un interrupt di processo - un segnale che dice alla CPU di interrompere ciò che sta facendo, salvare il suo stato nello stack, cambiare la sua modalità in qualcosa di più privilegiato ed eseguire il codice che troverà in un apposito design posto in memoria. Quel codice sembra essere parte dello scheduler, che decide cosa fare dopo. Potrebbe essere necessario riprendere qualche altro processo, nel qual caso dovrà eseguire ciò che è noto come "interruttore di contesto" - sostituendo l'intero stato attuale (comprese le tabelle di memoria virtuale) con quello dell'altro processo. Nel ritornare a un processo, deve ripristinare tutto il contesto di quel processo,

Il posto "appositamente designato" in memoria non deve essere conosciuto da nient'altro che dal sistema operativo. Le implementazioni variano, ma l'essenziale è che la CPU risponderà a vari interrupt eseguendo una ricerca nella tabella; la posizione della tabella si trova in un punto specifico della memoria (determinato dalla progettazione hardware della CPU), il contenuto della tabella viene impostato dal sistema operativo (generalmente all'avvio) e il "tipo" di interruzione determinerà quale voce nella tabella deve essere utilizzato come "routine di servizio di interruzione".

Niente di tutto ciò comporta "iniezione di codice" ... si basa sul codice contenuto nel sistema operativo in collaborazione con le funzionalità hardware della CPU e i suoi circuiti di supporto.

Penso che l'esempio del mondo reale più vicino a ciò che descrivi sia una delle tecniche utilizzate da VMware , la virtualizzazione completa mediante la traduzione binaria .

VMware agisce come un livello sotto uno o più sistemi operativi contemporaneamente eseguendo sullo stesso hardware.

La maggior parte delle istruzioni eseguite (ad es. In applicazioni ordinarie) può essere virtualizzata utilizzando l'hardware, ma un kernel del sistema operativo stesso utilizza istruzioni che non possono essere virtualizzate, poiché se il codice macchina del sistema operativo di ipotesi fosse eseguito non modificato si "spezzerebbe "del controllo dell'host VMware. Ad esempio, un SO guest dovrebbe essere eseguito nel ring di protezione più privilegiato e impostare la tabella di interrupt. Se fosse stato autorizzato a farlo, VMware avrebbe perso il controllo dell'hardware.

VMware riscrive tali istruzioni nel codice del sistema operativo prima di eseguirlo, sostituendole con salti nel codice VMware che simula l'effetto desiderato.

Quindi questa tecnica è in qualche modo analoga a ciò che descrivi.

Esistono vari casi in cui un sistema operativo potrebbe "iniettare codice" in un programma. Le versioni basate su 68000 del sistema Apple Macintosh creano una tabella di tutti i punti di ingresso del segmento (situati immediatamente prima delle variabili globali statiche, IIRC). All'avvio di un programma, ogni voce nella tabella è composta da un'istruzione trap seguita dal numero del segmento e spostata nel segmento. Se la trap viene eseguita, il sistema esaminerà le parole dopo l'istruzione trap per vedere quale segmento e offset sono richiesti, caricherà il segmento (se non lo è già), aggiungerà l'indirizzo iniziale del segmento all'offset e quindi sostituire la trap con un salto a quell'indirizzo appena calcolato.

Sui vecchi software per PC, sebbene ciò non sia stato tecnicamente eseguito dal "sistema operativo", era comune costruire codice con istruzioni trap anziché istruzioni matematiche del coprocessore. Se non fosse installato alcun coprocessore matematico, il gestore trap lo avrebbe emulato. Se è stato installato un coprocessore, la prima volta che viene presa una trap il gestore sostituirà l'istruzione trap con un'istruzione coprocessore; future esecuzioni dello stesso codice utilizzeranno direttamente l'istruzione coprocessore.