Qual è la differenza tra lo spazio del kernel e lo spazio dell'utente? Spazio del kernel, thread del kernel, processi del kernel e stack del kernel significano la stessa cosa? Inoltre, perché abbiamo bisogno di questa differenziazione?
Qual è la differenza tra lo spazio del kernel e lo spazio dell'utente? Spazio del kernel, thread del kernel, processi del kernel e stack del kernel significano la stessa cosa? Inoltre, perché abbiamo bisogno di questa differenziazione?
Risposte:
La risposta davvero semplificata è che il kernel viene eseguito nello spazio del kernel e che i normali programmi vengono eseguiti nello spazio dell'utente. Lo spazio utente è fondamentalmente una forma di sand-boxing: limita i programmi utente in modo che non possano interferire con la memoria (e altre risorse) di proprietà di altri programmi o del kernel del sistema operativo. Questo limita (ma di solito non elimina del tutto) la loro capacità di fare cose cattive come il crash della macchina.
Il kernel è il nucleo del sistema operativo. Normalmente ha pieno accesso a tutta la memoria e all'hardware della macchina (e tutto il resto sulla macchina). Per mantenere la macchina il più stabile possibile, normalmente si desidera eseguire solo il codice più affidabile e ben testato in modalità kernel / spazio kernel.
Lo stack è solo un'altra parte della memoria, quindi naturalmente è segregato insieme al resto della memoria.
La RAM ( Random Access Memory ) può essere logicamente divisa in due regioni distinte: lo spazio del kernel e lo spazio dell'utente ( gli indirizzi fisici della RAM non sono effettivamente divisi solo gli indirizzi virtuali , tutto ciò implementato dalla MMU )
Il kernel viene eseguito nella parte della memoria ad esso intitolata. Questa parte della memoria non è accessibile direttamente dai processi degli utenti normali, mentre il kernel può accedere a tutte le parti della memoria. Per accedere a una parte del kernel, i processi utente devono utilizzare il sistema predefinito chiamate cioè open
, read
, write
ecc Inoltre, le C
funzioni di libreria come printf
chiamata la chiamata di sistema write
, a sua volta.
Le chiamate di sistema fungono da interfaccia tra i processi utente e i processi del kernel. I diritti di accesso sono collocati nello spazio del kernel per impedire agli utenti di sbagliare con il kernel, inconsapevolmente.
Quindi, quando si verifica una chiamata di sistema, un interrupt software viene inviato al kernel. La CPU può consegnare temporaneamente il controllo alla routine di gestione degli interrupt associata. Il processo del kernel che è stato interrotto dall'interrupt riprende dopo che la routine del gestore di interrupt ha terminato il suo lavoro.
Lo spazio del kernel e lo spazio virtuale sono concetti di memoria virtuale .... non significa che Ram (la tua memoria effettiva) sia divisa in spazio kernel e utente. Ad ogni processo viene data memoria virtuale che è divisa in kernel e spazio utente.
Quindi dicendo "La memoria ad accesso casuale (RAM) può essere divisa in due regioni distinte, ovvero lo spazio del kernel e lo spazio dell'utente". è sbagliato.
e riguardo alla cosa "spazio kernel vs spazio utente"
Quando viene creato un processo e la sua memoria virtuale viene suddivisa in spazio utente e spazio kernel, in cui l'area dello spazio utente contiene dati, codice, stack, heap del processo e spazio kernel contiene elementi come la tabella delle pagine per il processo , strutture di dati del kernel e codice del kernel ecc. Per eseguire il codice dello spazio del kernel, il controllo deve passare alla modalità kernel (utilizzando l'interruzione software 0x80 per le chiamate di sistema) e lo stack del kernel è sostanzialmente condiviso tra tutti i processi attualmente in esecuzione nello spazio del kernel.
Gli anelli CPU sono la distinzione più chiara
In modalità protetta x86, la CPU è sempre in uno dei 4 squilli. Il kernel di Linux utilizza solo 0 e 3:
Questa è la definizione più dura e veloce di kernel vs userland.
Perché Linux non utilizza gli anelli 1 e 2: CPU Privilege Rings: Perché gli anelli 1 e 2 non vengono utilizzati?
Come viene determinato l'anello corrente?
L'anello corrente viene selezionato da una combinazione di:
tabella descrittiva globale: una tabella in memoria delle voci GDT e ogni voce ha un campo Privl
che codifica l'anello.
L'istruzione LGDT imposta l'indirizzo sulla tabella dei descrittori corrente.
Vedi anche: http://wiki.osdev.org/Global_Descriptor_Table
il segmento registra CS, DS, ecc., che indicano l'indice di una voce nel GDT.
Ad esempio, CS = 0
significa che la prima voce del GDT è attualmente attiva per il codice di esecuzione.
Cosa può fare ogni anello?
Il chip della CPU è fisicamente costruito in modo che:
l'anello 0 può fare qualsiasi cosa
l'anello 3 non può eseguire diverse istruzioni e scrivere in più registri, in particolare:
non può cambiare il proprio squillo! Altrimenti, potrebbe impostarsi su ring 0 e gli anelli sarebbero inutili.
In altre parole, non è possibile modificare il descrittore di segmento corrente , che determina l'anello corrente.
impossibile modificare le tabelle delle pagine: come funziona il paging x86?
In altre parole, non è possibile modificare il registro CR3 e il paging stesso impedisce la modifica delle tabelle delle pagine.
Ciò impedisce a un processo di vedere la memoria di altri processi per motivi di sicurezza / facilità di programmazione.
impossibile registrare i gestori di interrupt. Questi sono configurati scrivendo nelle posizioni di memoria, cosa che è impedita anche dal paging.
I gestori funzionano nell'anello 0 e rompono il modello di sicurezza.
In altre parole, non è possibile utilizzare le istruzioni LGDT e LIDT.
non può eseguire istruzioni IO come in
e out
, e quindi avere accessi hardware arbitrari.
Altrimenti, ad esempio, le autorizzazioni sui file sarebbero inutili se un programma potesse leggere direttamente dal disco.
Più precisamente grazie a Michael Petch : è effettivamente possibile per il sistema operativo consentire istruzioni IO sull'anello 3, questo è in realtà controllato dal segmento di stato Task .
Ciò che non è possibile è che l'anello 3 si autorizzi a farlo se non lo avesse in primo luogo.
Linux non lo consente sempre. Vedi anche: Perché Linux non utilizza l'interruttore di contesto hardware tramite TSS?
In che modo programmi e sistemi operativi passano da un anello all'altro?
quando la CPU è accesa, inizia a eseguire il programma iniziale nell'anello 0 (bene, ma è una buona approssimazione). Puoi pensare che questo programma iniziale sia il kernel (ma normalmente è un bootloader che chiama il kernel ancora nell'anello 0 ).
quando un processo userland vuole che il kernel faccia qualcosa per esso come scrivere su un file, usa un'istruzione che genera un interruzione come int 0x80
osyscall
per segnalare il kernel. x86-64 ciao syscall Linux esempio del mondo:
.data
hello_world:
.ascii "hello world\n"
hello_world_len = . - hello_world
.text
.global _start
_start:
/* write */
mov $1, %rax
mov $1, %rdi
mov $hello_world, %rsi
mov $hello_world_len, %rdx
syscall
/* exit */
mov $60, %rax
mov $0, %rdi
syscall
compilare ed eseguire:
as -o hello_world.o hello_world.S
ld -o hello_world.out hello_world.o
./hello_world.out
Quando ciò accade, la CPU chiama un gestore di callback di interrupt che il kernel ha registrato all'avvio. Ecco un esempio concreto di baremetal che registra un gestore e lo utilizza .
Questo gestore viene eseguito nell'anello 0, che decide se il kernel consentirà questa azione, eseguirà l'azione e riavvierà il programma userland nell'anello 3. x86_64
quando exec
viene utilizzata la chiamata di sistema (o quando si avvia/init
il kernel ), il kernel prepara i registri e la memoria del nuovo processo userland, quindi salta al punto di ingresso e commuta la CPU sul ring 3
Se il programma cerca di fare qualcosa di cattivo come scrivere su un registro proibito o un indirizzo di memoria (a causa del paging), la CPU chiama anche un gestore di callback del kernel nell'anello 0.
Ma poiché la zona dell'utente era cattiva, questa volta il kernel potrebbe terminare il processo o dare un avvertimento con un segnale.
Quando il kernel si avvia, imposta un clock hardware con una certa frequenza fissa, che genera periodicamente interruzioni.
Questo orologio hardware genera interruzioni che eseguono l'anello 0 e gli consente di pianificare i processi di utenteland da riattivare.
In questo modo, la pianificazione può avvenire anche se i processi non effettuano chiamate di sistema.
Qual è il punto di avere più anelli?
Ci sono due principali vantaggi nel separare kernel e userland:
Come giocarci?
Ho creato un setup bare metal che dovrebbe essere un buon modo per manipolare direttamente gli anelli: https://github.com/cirosantilli/x86-bare-metal-examples
Purtroppo non ho avuto la pazienza di fare un esempio di userland, ma sono arrivato al punto di impostazione della paginazione, quindi userland dovrebbe essere fattibile. Mi piacerebbe vedere una richiesta pull.
In alternativa, i moduli del kernel Linux vengono eseguiti nell'anello 0, quindi è possibile utilizzarli per provare operazioni privilegiate, ad esempio leggere i registri di controllo: come accedere ai registri di controllo cr0, cr2, cr3 da un programma? Errore di segmentazione
Ecco una comoda configurazione QEMU + Buildroot per provarlo senza uccidere il tuo host.
L'aspetto negativo dei moduli del kernel è che altri kthread sono in esecuzione e potrebbero interferire con i tuoi esperimenti. Ma in teoria puoi assumere tutti i gestori di interrupt con il tuo modulo kernel e possedere il sistema, in realtà sarebbe un progetto interessante.
Anelli negativi
Sebbene gli anelli negativi non siano effettivamente citati nel manuale Intel, in realtà ci sono modalità CPU che hanno ulteriori capacità rispetto allo stesso anello 0, e quindi si adattano bene al nome di "anello negativo".
Un esempio è la modalità hypervisor utilizzata nella virtualizzazione.
Per ulteriori dettagli consultare:
BRACCIO
In ARM, invece, gli anelli sono chiamati Livelli di eccezione, ma le idee principali rimangono le stesse.
Esistono 4 livelli di eccezione in ARMv8, comunemente usati come:
EL0: userland
EL1: kernel ("supervisore" nella terminologia ARM).
Inserito con l' svc
istruzione (SuperVisor Call), precedentemente nota come swi
prima dell'assembly unificato , che è l'istruzione utilizzata per effettuare chiamate di sistema Linux. Ciao esempio mondiale ARMv8:
hello.s
.text
.global _start
_start:
/* write */
mov x0, 1
ldr x1, =msg
ldr x2, =len
mov x8, 64
svc 0
/* exit */
mov x0, 0
mov x8, 93
svc 0
msg:
.ascii "hello syscall v8\n"
len = . - msg
Provalo con QEMU su Ubuntu 16.04:
sudo apt-get install qemu-user gcc-arm-linux-gnueabihf
arm-linux-gnueabihf-as -o hello.o hello.S
arm-linux-gnueabihf-ld -o hello hello.o
qemu-arm hello
Ecco un esempio concreto di baremetal che registra un gestore SVC ed esegue una chiamata SVC .
EL2: hypervisor , ad esempio Xen .
Inserito con l' hvc
istruzione (HyperVisor Call).
Un hypervisor è per un sistema operativo, ciò che un sistema operativo è per l'utente.
Ad esempio, Xen consente di eseguire più sistemi operativi come Linux o Windows sullo stesso sistema allo stesso tempo e isola i sistemi operativi tra loro per sicurezza e facilità di debug, proprio come Linux fa per i programmi utente.
Gli hypervisor sono una parte fondamentale dell'infrastruttura cloud odierna: consentono l'esecuzione di più server su un singolo hardware, mantenendo l'utilizzo dell'hardware sempre vicino al 100% e risparmiando un sacco di soldi.
AWS, ad esempio, ha utilizzato Xen fino al 2017, quando il suo passaggio a KVM ha fatto notizia .
EL3: ancora un altro livello. Esempio TODO.
Inserito con l' smc
istruzione (Secure Mode Call)
Il modello di riferimento dell'architettura ARMv8 DDI 0487C.a - Capitolo D1 - Il modello del programmatore a livello di sistema AArch64 - La figura D1-1 illustra in modo meraviglioso:
La situazione ARM è cambiata un po 'con l'avvento di ARMv8.1 Virtualization Host Extensions (VHE) . Questa estensione consente al kernel di funzionare in modo efficiente in EL2:
VHE è stato creato perché le soluzioni di virtualizzazione nel kernel Linux come KVM hanno guadagnato terreno su Xen (vedi ad esempio il passaggio di AWS a KVM sopra menzionato), perché la maggior parte dei client ha bisogno solo di macchine virtuali Linux, e come puoi immaginare, essendo tutto in un unico progetto, KVM è più semplice e potenzialmente più efficiente di Xen. Quindi ora il kernel Linux host funge da hypervisor in questi casi.
Nota come ARM, forse a causa del vantaggio del senno di poi, ha una convenzione di denominazione migliore per i livelli di privilegio rispetto a x86, senza la necessità di livelli negativi: 0 è il più basso e 3 il più alto. I livelli più alti tendono ad essere creati più spesso di quelli inferiori.
L'attuale EL può essere interrogato con l' MRS
istruzione: qual è l'attuale modalità di esecuzione / livello di eccezione, ecc.?
ARM non richiede la presenza di tutti i livelli di eccezione per consentire implementazioni che non richiedono la funzionalità per salvare l'area del chip. ARMv8 "Livelli di eccezione" dice:
Un'implementazione potrebbe non includere tutti i livelli di eccezione. Tutte le implementazioni devono includere EL0 ed EL1. EL2 ed EL3 sono opzionali.
QEMU, ad esempio, per impostazione predefinita è EL1, ma EL2 e EL3 possono essere abilitati con le opzioni della riga di comando: qemu-system-aarch64 immettendo el1 quando si emula l'accensione di a53
Frammenti di codice testati su Ubuntu 18.10.
Lo spazio del kernel e lo spazio utente è la separazione delle funzioni privilegiate del sistema operativo e delle applicazioni utente riservate. La separazione è necessaria per impedire alle applicazioni degli utenti di saccheggiare il computer. Sarebbe una brutta cosa se qualsiasi vecchio programma utente potesse iniziare a scrivere dati casuali sul disco rigido o leggere memoria dallo spazio di memoria di un altro programma utente.
I programmi dello spazio utente non possono accedere direttamente alle risorse di sistema, quindi l'accesso è gestito per conto del programma dal kernel del sistema operativo. I programmi di spazio utente in genere fanno tali richieste al sistema operativo tramite chiamate di sistema.
I thread del kernel, i processi, lo stack non significano la stessa cosa. Sono analoghi costrutti per lo spazio del kernel come loro controparti nello spazio utente.
Ogni processo ha i suoi 4 GB di memoria virtuale che si associa alla memoria fisica attraverso le tabelle delle pagine. La memoria virtuale è principalmente divisa in due parti: 3 GB per l'uso del processo e 1 GB per l'uso del kernel. La maggior parte delle variabili create si trovano nella prima parte dello spazio degli indirizzi. Quella parte si chiama spazio utente. L'ultima parte è dove risiede il kernel ed è comune per tutti i processi. Questo si chiama spazio del kernel e la maggior parte di questo spazio è mappata nelle posizioni iniziali della memoria fisica in cui l'immagine del kernel viene caricata all'avvio.
La dimensione massima dello spazio degli indirizzi dipende dalla lunghezza del registro degli indirizzi sulla CPU.
Sui sistemi con registri di indirizzi a 32 bit, la dimensione massima dello spazio degli indirizzi è di 2 32 byte o 4 GiB. Analogamente, sui sistemi a 64 bit, è possibile indirizzare 2 64 byte.
Tale spazio di indirizzi è chiamato memoria virtuale o spazio di indirizzi virtuale . In realtà non è correlato alla dimensione della RAM fisica.
Su piattaforme Linux, lo spazio degli indirizzi virtuali è diviso in spazio del kernel e spazio utente.
Una costante specifica dell'architettura denominata limite dimensione attività o TASK_SIZE
indica la posizione in cui si verifica la divisione:
l'intervallo di indirizzi da 0 a TASK_SIZE
-1 viene assegnato allo spazio utente;
il resto da un TASK_SIZE
massimo di 2 32 -1 (o 2 64 -1) è assegnato allo spazio del kernel.
Su un particolare sistema a 32 bit, ad esempio, 3 GiB potrebbero essere occupati per lo spazio utente e 1 GiB per lo spazio del kernel.
Ogni applicazione / programma in un sistema operativo simile a Unix è un processo; ognuno di questi ha un identificatore univoco chiamato Process Identifier (o semplicemente Process ID , cioè PID). Linux fornisce due meccanismi per la creazione di un processo: 1. la fork()
chiamata di sistema o 2. ilexec()
chiamata.
Un thread del kernel è un processo leggero e anche un programma in esecuzione. Un singolo processo può consistere in più thread che condividono gli stessi dati e risorse ma che seguono percorsi diversi attraverso il codice del programma. Linux fornisce una clone()
chiamata di sistema per generare thread.
Esempi di utilizzo dei thread del kernel sono: sincronizzazione dei dati della RAM, aiutando lo scheduler a distribuire i processi tra le CPU, ecc.
In breve: il kernel viene eseguito in Kernel Space, lo spazio del kernel ha pieno accesso a tutta la memoria e le risorse, si può dire che la memoria si divide in due parti, parte per il kernel e parte per il processo dell'utente, (spazio utente) esegue programmi normali, utente lo spazio non può accedere direttamente allo spazio del kernel, quindi richiede al kernel di utilizzare le risorse. per syscall (chiamata di sistema predefinita in glibc)
c'è una dichiarazione che semplifica il diverso "Lo spazio utente è solo un carico di prova per il kernel " ...
Per essere molto chiari: l'architettura del processore consente alla CPU di funzionare in due modalità, la modalità kernel e la modalità utente , le istruzioni hardware consentono di passare da una modalità all'altra.
la memoria può essere contrassegnata come parte dello spazio utente o dello spazio del kernel.
Quando la CPU è in esecuzione in modalità utente, la CPU può accedere solo alla memoria che si trova nello spazio utente, mentre cpu tenta di accedere alla memoria nello spazio del kernel il risultato è una "eccezione hardware", quando la CPU è in esecuzione in modalità kernel, la CPU può accedere direttamente sia nello spazio kernel che nello spazio utente ...
Lo spazio del kernel significa che uno spazio di memoria può essere toccato solo dal kernel. Su Linux a 32 bit è 1G (da 0xC0000000 a 0xffffffff come indirizzo di memoria virtuale). Ogni processo creato dal kernel è anche un thread del kernel, quindi per un processo, ci sono due stack: uno stack nello spazio utente per questo processo e un altro nel kernel spazio per il thread del kernel.
lo stack del kernel ha occupato 2 pagine (8k in Linux a 32 bit), include task_struct (circa 1k) e lo stack reale (circa 7k). Quest'ultimo è usato per memorizzare alcune variabili automatiche o parametri di chiamata di funzione o indirizzo di funzione nelle funzioni del kernel. Ecco il codice (Processor.h (linux \ include \ asm-i386)):
#define THREAD_SIZE (2*PAGE_SIZE)
#define alloc_task_struct() ((struct task_struct *) __get_free_pages(GFP_KERNEL,1))
#define free_task_struct(p) free_pages((unsigned long) (p), 1)
__get_free_pages (GFP_KERNEL, 1)) significa allocare memoria come 2 ^ 1 = 2 pagine.
Ma lo stack di processo è un'altra cosa, il suo indirizzo è solo 0xC0000000 (Linux a 32 bit), la sua dimensione può essere molto più grande, usata per le chiamate di funzione dello spazio utente.
Quindi ecco una domanda per la chiamata di sistema, è in esecuzione nello spazio del kernel ma è stata chiamata dal processo nello spazio dell'utente, come funziona? Linux metterà i suoi parametri e l'indirizzo della funzione nello stack del kernel o nello stack del processo? Soluzione di Linux: tutte le chiamate di sistema sono attivate dall'interruzione del software INT 0x80. Definito in entry.S (linux \ arch \ i386 \ kernel), ecco alcune righe per esempio:
ENTRY(sys_call_table)
.long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system call*/
.long SYMBOL_NAME(sys_exit)
.long SYMBOL_NAME(sys_fork)
.long SYMBOL_NAME(sys_read)
.long SYMBOL_NAME(sys_write)
.long SYMBOL_NAME(sys_open) /* 5 */
.long SYMBOL_NAME(sys_close)
Il kernel Linux fa riferimento a tutto ciò che viene eseguito in modalità kernel ed è composto da diversi livelli distinti. Al livello più basso, il kernel interagisce con l'hardware tramite HAL. A livello centrale, il kernel UNIX è diviso in 4 aree distinte. La prima delle quattro aree gestisce dispositivi a caratteri, TTY crudo e cotto e gestione dei terminali. La seconda area gestisce i driver di dispositivo di rete, i protocolli di routing e i socket. La terza area gestisce i driver di dispositivo disco, le cache di pagina e buffer, il file system, la memoria virtuale, la denominazione e il mapping dei file. La quarta e ultima area gestisce l'invio, la pianificazione, la creazione e la terminazione del processo, nonché la gestione del segnale. Soprattutto abbiamo il livello superiore del kernel che include chiamate di sistema, interruzioni e trap. Questo livello funge da interfaccia per ciascuna delle funzioni di livello inferiore. Un programmatore utilizza le varie chiamate di sistema e gli interrupt per interagire con le funzionalità del sistema operativo.
IN breve lo spazio del kernel è la porzione di memoria in cui viene eseguito il kernel linux (1 GB di spazio virtuale superiore in caso di Linux) e lo spazio utente è la porzione di memoria in cui viene eseguita l'applicazione dell'utente (3 GB di memoria virtuale inferiore in caso di Linux. vuoi saperne di più vedi il link indicato di seguito :)
http://learnlinuxconcepts.blogspot.in/2014/02/kernel-space-and-user-space.html
Prova di dare una spiegazione molto semplificata
La memoria virtuale è divisa in spazio kernel e spazio utente. Lo spazio del kernel è quell'area della memoria virtuale in cui verranno eseguiti i processi del kernel e lo spazio dell'utente è quell'area della memoria virtuale in cui verranno eseguiti i processi dell'utente.
Questa divisione è necessaria per le protezioni dell'accesso alla memoria.
Ogni volta che un bootloader avvia un kernel dopo averlo caricato in una posizione nella RAM, (in genere su un controller basato su ARM), deve assicurarsi che il controller sia in modalità supervisore con FIQ e IRQ disabilitati.
Kernel Space e User Space sono spazi logici.
La maggior parte dei moderni processori è progettata per funzionare in diverse modalità privilegiate. Le macchine x86 possono funzionare in 4 diverse modalità privilegiate.
E una particolare istruzione della macchina può essere eseguita in / sopra una particolare modalità privilegiata.
Grazie a questo design stai offrendo una protezione del sistema o sandboxing l'ambiente di esecuzione.
Il kernel è un pezzo di codice che gestisce l'hardware e fornisce l'astrazione del sistema. Quindi deve avere accesso a tutte le istruzioni della macchina. Ed è il software più affidabile. Quindi dovrei essere eseguito con il massimo privilegio. E Ring level 0 è la modalità più privilegiata. Quindi il Ring Level 0 è anche chiamato Kernel Mode .
Le applicazioni utente sono software che provengono da qualsiasi fornitore di terze parti e non puoi fidarti completamente di loro. Qualcuno con intenzioni dannose può scrivere un codice per arrestare il sistema in modo anomalo se avesse accesso completo a tutte le istruzioni della macchina. Quindi l'applicazione dovrebbe avere accesso a un set limitato di istruzioni. E Ring Level 3 è la modalità meno privilegiata. Quindi tutte le applicazioni vengono eseguite in quella modalità. Quindi quel Ring Level 3 è anche chiamato User Mode .
Nota: non ottengo i livelli di suoneria 1 e 2. Sono sostanzialmente modalità con privilegio intermedio. Quindi potrebbe essere il codice del driver del dispositivo eseguito con questo privilegio. AFAIK, Linux utilizza rispettivamente solo Ring Level 0 e 3 per l'esecuzione del codice kernel e l'applicazione utente.
Quindi qualsiasi operazione che si verifica in modalità kernel può essere considerata come spazio del kernel. E qualsiasi operazione che si verifica in modalità utente può essere considerata come spazio utente.
La risposta corretta è: non esiste spazio del kernel e spazio dell'utente. Il set di istruzioni del processore ha autorizzazioni speciali per impostare cose distruttive come la radice della mappa della tabella delle pagine o accedere alla memoria del dispositivo hardware, ecc.
Il codice kernel ha i privilegi di livello più alto e il codice utente il più basso. Ciò impedisce al codice utente di arrestare il sistema in modo anomalo, modificare altri programmi, ecc.
Generalmente il codice del kernel viene mantenuto in una mappa di memoria diversa rispetto al codice utente (proprio come gli spazi utente vengono mantenuti in mappe di memoria diverse l'una dall'altra). Questo è da dove provengono i termini "spazio del kernel" e "spazio dell'utente". Ma questa non è una regola dura e veloce. Ad esempio, poiché x86 richiede indirettamente la mappatura dei gestori di interrupt / trap in qualsiasi momento, parte (o alcuni sistemi operativi tutti) del kernel deve essere mappato nello spazio utente. Ancora una volta, ciò non significa che tale codice abbia i privilegi dell'utente.
Perché è necessaria la divisione kernel / utente? Alcuni designer non sono d'accordo sul fatto che sia, in effetti, necessario. L'architettura del microkernel si basa sull'idea che le sezioni di codice privilegiate più alte dovrebbero essere le più piccole possibili, con tutte le operazioni significative eseguite nel codice privilegiato dall'utente. Dovresti studiare perché questa potrebbe essere una buona idea, non è un concetto semplice (ed è famosa per avere vantaggi e svantaggi).
Memory get è diviso in due aree distinte:
I processi in esecuzione nello spazio utente hanno accesso solo a una parte limitata della memoria, mentre il kernel ha accesso a tutta la memoria. Anche i processi in esecuzione nello spazio utente non hanno accesso allo spazio del kernel. I processi dello spazio utente possono accedere solo a una piccola parte del kernel tramite un'interfaccia esposta dal kernel - il sistema chiama. Se un processo esegue una chiamata di sistema, viene inviato al kernel un interrupt software, che quindi invia il gestore di interrupt appropriato e continua funziona dopo che il gestore ha terminato.
In Linux ci sono due spazi: 1 è lo spazio utente e un altro è lo spazio kernal. lo spazio utente è costituito solo dall'applicazione utente che si desidera eseguire. come servizio kernal c'è la gestione dei processi, la gestione dei file, la gestione dei segnali, la gestione della memoria, la gestione dei thread e così tanti servizi sono presenti lì. se esegui l'applicazione dallo spazio utente tale applicazione interagisce solo con il servizio kernal. e quel servizio è interagire con il driver del dispositivo che è presente tra hardware e kernal. il principale vantaggio dello spazio kernal e della separazione dello spazio utente è che possiamo ottenere una sicurezza dal virus.bcaz di tutte le applicazioni utente presenti nello spazio utente e il servizio è presente nello spazio kernal. ecco perché Linux non influenza il virus.