In che modo un sistema operativo limita le capacità di un programma, se funziona direttamente con la cpu?
Quando un programma viene caricato in memoria e inizia a funzionare, la cpu carica ogni istruzione dal codice ed esegue l'istruzione in base all'opcode e agli argomenti, quindi il programma interrompe per così dire direttamente contro la cpu.
Tuttavia, il sistema operativo (linux / win) non ti consente di fare tutto, quindi devi chiedere il suo permesso per alcune cose - con le chiamate di sistema. Ma mi chiedo come sia possibile che un codice utente non possa fare certe cose che il sistema operativo può fare: che differenza fa per la CPU se il codice del kernel del sistema operativo esegue un comando o se un utente lo fa?
Il sistema operativo esamina il mio codice prima di caricarlo e vede se sto usando alcune istruzioni che non sono autorizzato a usare e in caso affermativo semplicemente non le eseguirà?
Come viene gestito?
Btw considera Assembly come il linguaggio di programmazione, quindi il programmatore può scegliere qualsiasi istruzione da utilizzare nel codice.
Risposte
Le moderne CPU hanno modalità di privilegio utilizzate dal sistema operativo che bloccano determinate istruzioni. Ad esempio in usermodalità le istruzioni che modificano (aumentano) la modalità privilegio o accedono alle risorse di sistema come le tabelle delle pagine attualmente configurate causano eccezioni. Ciò consente al sistema operativo di decidere se interrompere il processo utente o emulare l'operazione.
Il sistema operativo esamina il mio codice prima di caricarlo e vede se sto usando alcune istruzioni che non sono autorizzato a usare e in caso affermativo semplicemente non le eseguirà?
No, non è necessario: il sistema operativo mette il processore in modalità "utente" ogni volta che esegue il codice utente. Ciò attiverà il meccanismo di eccezione dell'hardware se si incontra un'istruzione privilegiata: in modalità utente, l'eccezione si verifica invece di eseguire l'istruzione privilegiata (l'attivazione di un'eccezione è l'esecuzione di quell'istruzione piuttosto che qualsiasi operazione privilegiata).
A proposito, i tipi di istruzioni della chiamata di sistema utilizzati dal codice in modalità utente per richiedere servizi dal sistema operativo attivano anche il meccanismo di eccezione hardware.
Come viene gestito?
Il sistema operativo esegue sempre il codice utente in modalità utente, ovvero privilegio a livello utente, e generalmente esegue il proprio codice con privilegi superiori. Queste modalità informano il processore su come gestire le istruzioni privilegiate. La maggior parte del codice in modalità utente non si preoccupa nemmeno di provare a eseguire istruzioni privilegiate poiché sono inutili, ma se lo fanno, il meccanismo di eccezione hardware interviene e comunica efficacemente al sistema operativo che ciò è accaduto e gli consente di gestire la situazione.
Per eseguire il codice in modalità utente, il sistema operativo potrebbe utilizzare un'istruzione "return from interrupt", per riavviare il codice utente (indipendentemente dal fatto che sia tecnicamente o non sia stato avviato in precedenza non importa). Un ritorno da interrupt è un tipo di istruzione che è un modo per cambiare il livello di privilegio, cambiando anche il flusso di istruzioni (noto anche come branching); tale istruzione stessa è privilegiata, il che significa che il processore non la consentirà in modalità utente.
Quando il processore riceve un interrupt, rileva parte dello stato critico della CPU: lo stato critico della CPU è quello stato che deve necessariamente modificare per servire un interrupt. La manutenzione di un interrupt trasferisce il controllo del feed del flusso di istruzioni nella CPU, modificando il contatore del programma noto anche come puntatore di istruzioni; in caso di interruzione, il processore esegue effettivamente un salto improvviso alla routine del servizio di interruzione. Apporta anche un improvviso cambio di modalità a privilegi più elevati che consente all'ISR di accedere a più istruzioni. Poiché queste due modifiche improvvise sono necessarie per attivare l'ISR, l'hardware registrerà i valori precedenti per il software da utilizzare in seguito quando riprenderà il codice della modalità utente interrotto. Pertanto, l'hardware e il sistema operativo cospirano insieme per eseguire il sistema operativo con privilegi elevati e il codice utente con privilegi bassi.
Quando il programma in modalità utente utilizza un tipo di istruzione syscall (che richiede servizi del sistema operativo, come I / O), lo stesso meccanismo di eccezione hardware trasferisce il controllo all'ISR. Quando il sistema operativo desidera riprendere il processo in modalità utente, a seconda dell'hardware, potrebbe essere necessario far avanzare manualmente il contatore del programma del processo in modalità utente attraverso l'istruzione syscall prima di riprenderlo: è come se, nel processo in modalità utente, il il sistema operativo ha simulato / emulato la chiamata di sistema.
Inoltre, tutte le istruzioni della CPU del programma vengono eseguite nel proprio spazio di memoria virtuale. Questo fondamentalmente disabilita qualsiasi istruzione codificata per accedere o modificare i dati di sistema, altri dati di processi o dati del kernel.
Fondamentalmente, puoi rovinare la tua casa come vuoi, ma non puoi guardare nelle case di nessun altro.
Se vuoi eseguire qualcosa al di fuori del tuo spazio degli indirizzi, non hai altra scelta che chiamare le routine / servizi di sistema che lo fanno per te - e quelli controllano l'autorizzazione / i privilegi del tuo processo.
Rimanendo nella figura sopra, è necessario utilizzare un servizio affidabile se si desidera qualcosa con le case di altre persone: le routine del kernel del sistema operativo.
Questa risposta presuppone che tu stia eseguendo un moderno sistema operativo multi-tasking (Windows, MacOS, Linux, ecc.) Su un processore che ha un supporto hardware specifico per esso (ARM, x86, PowerPC, ecc.). Si basa sulle risposte precedenti di Erik Eidt e Aganju.
Questi sistemi si sono sviluppati negli anni fino a diventare sempre più restrittivi per i normali programmi utente.
Su una macchina del genere, il programma non ha accesso diretto alla memoria fisica. Tutti gli indirizzi di memoria passano attraverso un gestore di memoria virtuale. Se un particolare indirizzo è stato allocato nello spazio degli indirizzi, l'indirizzo viene mappato a un indirizzo di memoria fisica. In caso contrario, l'accesso non riesce e genera una trappola. Il sistema operativo probabilmente terminerà il programma. Il gestore della memoria garantisce che nessun processo possa mai danneggiare la memoria di un altro processo.
I dispositivi hardware sono generalmente mappati in memoria. Anche in questo caso, il gestore della memoria blocca qualsiasi accesso diretto ad essi. Devi chiamare un autista per farlo per te.
Esistono istruzioni speciali del codice macchina utilizzate dal sistema operativo per impostare tutto e anche per implementare i driver di dispositivo. Queste istruzioni hanno diversi livelli di privilegio necessari per eseguirle. Quando il programma viene avviato, verrà contrassegnato dal sistema operativo come programma utente, che dispone del privilegio più basso. Quindi qualsiasi tentativo di utilizzare queste istruzioni per modificare o bypassare la gestione della memoria verrà bloccato. Anche in questo caso, è probabile che il tuo programma venga terminato.