[Approfondimento] Kernel, Darwin, BIOS, EFI e dintorni

[Giorgio_multi]

Kernel

 

Il kernel costituisce il nucleo di un Sistema Operativo (SO). Si tratta di un software (programma) che ha il compito di fornire ai programmi in esecuzione sulla macchina un accesso sicuro e controllato all'hardware. Dato che possono esserne eseguiti simultaneamente più di uno (di programmi), il kernel ha anche il compito di assegnare una porzione di tempo-macchina e di accesso all'hardware a ciascun programma (il cosidetto multitasking).

 

Per chiarezza definiamo che tutto ciò che avviene all'interno del kernel viene definito in "kernel space" mentre tutto quello che avviene al di fuori del kernel viene definito in "user space".

 

 

Il kernel non è strettamente necessario per far funzionare un computer. I programmi possono essere direttamente caricati ed eseguiti sulla macchina, questa era la modalità di funzionamento tipica dei primi elaboratori, che venivano resettati prima di eseguire un nuovo programma.

 

 

L'accesso diretto all'hardware di un PC può essere anche molto complesso, quindi i kernel usualmente usano uno o pi?canismi di astrazione dall'hardware, il cosiddetto: Hardware Abstraction Layer (HAL) (in italiano leggi astrazione come semplificazione quindi in italiano HAL suona più o meno come: Livello di Semplificazione dell'Hardware) che è un insieme di funzioni di Input/Output il più possibile generiche e semplici, il cui compito è di interfacciare i dispositivi fisici diversi (leggi periferiche, schede audio, LAN, Wireless etc) col programma che li userà nascondendogli la vera identità e natura di essi.

 

In base al tipo di HAL si possono trovare 4 tipi di kernel:

 

 

1) Kernel monolitici con una astrazione completa (leggi controllo completo) dell'hardware sottostante.

 

2) Microkernel che forniscono un insieme ristretto e semplice di astrazione dell'hardware e usano software (chiamati device driver o server) per fornire maggiori funzionalità;

 

3) Kernel ibridi

4) Esokernel (esulano dal nostro scopo).

 

 

Kernel Monolitici: Il kernel offre un'astrazione (semplificazione) completa dell'hardware, con un set di primitive o chiamate di sistema (una chiamata di sistema, in inglese system call, è il meccanismo usato da un programma in user space per richiedere al kernel di utilizzare dei servizi del sistema operativo) come: gestione dei processi, multitasking e gestione della memoria, tali servizi di sistema sono organizzati in diversi moduli che girano in kernel space. Anche se ogni modulo che serve queste operazioni è separato dal resto, l'integrazione del codice è molto stretta e difficile da fare in maniera corretta e, siccome tutti i moduli operano nello stesso spazio (kernel space), un bug in uno di essi può bloccare l'intero sistema. Tuttavia, quando la programmazione è completa e sicura, la stretta integrazione interna dei componenti rende un buon kernel monolitico estremamente efficiente e veloce

 

Il più grosso svantaggio dei kernel monolitici è tuttavia che non è possibile aggiungere un nuovo dispositivo hardware senza inserire il relativo modulo nel kernel, operazione che richiede la ricompilazione del kernel. In alternativa è possibile compilare un kernel con tutti i moduli di supporto all'hardware, con lo svantaggio di avere un kernel di enormi dimensioni. Tuttavia i kernel monolitici più moderni come il Kernel Linux e il kernel di FreeBSD possono caricare dei moduli in fase di esecuzione (cioè quando il kernel è già caricato e funzionante), a patto che questi fossero previsti in fase di compilazione, permettendo così l'estensione del kernel quando richiesto (kernel monolitici modulari), mantenendo al contempo le dimensioni del codice nello spazio del kernel al minimo indispensabile.

 

Per esempio il programma che vuol leggere un file, invece di aprire personalmente il file chiederà all'HAL di farlo per lui e l'HAL, appena esaudita la richiesta, gli passerà un riferimento al file per la lettura o un messaggio di errore. Altro esempio parlando di schede grafiche, i programmi non accedono mai alla memoria della scheda grafica quando devono modificare l'immagine mostrata sullo schermo. I programmi comunicano al SO le operazioni da compiere e il SO provvede ad effettuare le modifiche necessarie. Questo consente di modificare l'hardware (scheda grafica) preposto alla visualizzazione senza dover modificare tutti i programmi. Basta modificare lo strato (leggi serie di operazioni Input/Output) che accede all'hardware, questo comunemente viene chiamato driver.

 

Architettura di un kernel monolitico

 

 

Microkernel: il kernel offre poche astrazioni (semplificazioni) dell'hardware, giusto quelle che, per poter funzionare, hanno bisogno della modalità privilegiata (kernel space). Tutto il resto — per esempio device driver, filesystem, socket — viene implementato in modalià utente (user space) da speciali processi (tipicamente chiamati server ) a cui si appoggiano le normali applicazioni. Per ritornare all'esempio della lettura di un file con un'architettura a microkernel, invece, il programma comunicherà al server del filesystem la sua intenzione di aprire un file; il server, se necessario, contatterà a sua volta altri server, e, una volta terminato il suo compito, invierà una risposta al programma che l'aveva chiamato senza accedere al kernel space; capirete che con un simile meccanismo un qualsiasi blocco di questa fase non porterà al blocco del sistema, ma del solo server interessato: basrterà riavviare il server per sistemare il problema.

 

Si può intuire quanto sia importante la comunicazione tra i diversi processi che girano sopra ad un microkernel. La IPC (Inter-Process Communication), infatti, è la principale astrazione fornita da un qualsiasi microkernel (insieme a quella di processo, ovviamente, senza la quale non ci sarebbe IPC). Si capisce come essa, molto facilmente, possa diventare il collo di bottiglia di questi sistemi: tornando all'esempio di prima, con un kernel monolitico l'apertura di un file richiede una sola chiamata di sistema, mentre con un microkernel sono necessarie almeno due IPC (quindi almeno due system calls). Tipici microkernel sono il mach kernel e L4 Family kernel.

 

Vennero quindi progettati e scritti microkernel come Mach e Chorus. Il clima, in quel periodo, era di entusiasmo generale: i microkernel sarebbero potuti uscire dal mondo della teoria, e dominare quello della pratica.

 

Architettura di un microkernel

 

 

Purtroppo, i primi confronti di prestazioni furono una vera e propria doccia fredda, e confermarono i timori che alcuni studiosi (tra i quali il giovanissimo studente Linus Torvald) avevano nutrito fin dall'inizio: i microkernel si dimostrarono lenti, troppo lenti per reggere Il confronto con i sistemi tradizionali.

Per superare questo problema, senza rinunciare al design moderno dei microkernel, si pensò di reintrodurre in kernel-mode alcuni servizi critici: si sarebbero così limitati i passaggi da user space a kernel space guadagnando alcuni punti nelle prestazioni: sorsero così i Kernel Ibridi. I kernel ibridi sono essenzialmente dei microkernel che hanno del codice "non essenziale" ( in genere costituito da quelle parti di codice che vengono utilizzate più frequentemente) in kernel space in modo che questo codice possa girare più rapidamente.

 

Esempio di architettura di kernel ibrido

 

Da non confondere (cosa che viene comunemente fatta) i kernel monolitici modulari con il microkernel o i kernel ibridi.

 

Il kernel ibrido deve contenere una parte di entrambe le architetture. La possibilità o meno di caricare dinamicamente dei moduli NON caratterizza il tipo di kernel, lo possono fare sia i kernel monolitici, che i microkernel che gli ibridi. E' l'architettura del kernel ed in particolare come è strutturata la HAL che determina il tipo di kernel.

 

 

Uscendo un attimo dal seminato capirete il significato del nome del supercomputer di 2001 odissea nello spazio, appunto HAL (e credo che astrazione dall'hardware più riuscita di quella non possa esistere).

 

 

Esempi di kernel ibridi che ci riguardano da vicino sono il kernel di Mac OSX e il kernel di Windows.

 

Come molti kernel moderni il kernel di Mac OSX segue un approccio ibrido, contenendo caratteristiche sia di un microkenel che di un kernel monolitico. Difatti segue un approccio da microkernel per quanto riguarda la gestione dei servizi ma integra nello stesso microkernel ampie porzioni del sistema operativo per ridurre i tempi morti dovuti alla comunicazione interprocesso (il famoso IPC).

 

Il kernel di Mac OSX è un ibrido derivato dal mach kernel 3.0 (un microkernel) e da porzioni di kernel FreeBSD (monolitico). Tale kernel viene denominato XNU.

 

Il nucleo del kernel XNU, Mach, fornisce la gestione dei processi (attività controllate da un programma che si svolge su un processore), il passaggio dei messaggi (utilizzati nella comunicazione interprocesso o IPC), la memoria virtuale (una architettura di sistema capace di simulare uno spazio di memoria centrale maggiore di quello fisicamente presente; questo risultato si raggiunge utilizzando spazio di memoria secondaria su altri dispositivi, di solito le unità disco) e la protezione della memoria (è un sistema che impedisce ad un processo di corrompere la memoria di un altro processo in esecuzione contemporaneamente sullo stesso computer), la gestione dei processi real-time, il supporto al debugging del kernel (è un'attività che consiste nella individuazione della porzione di software affetta da errore (bug) rilevati nei software a seguito dell'utilizzo del programma) e Input/Output da console

 

Le porzioni di codice BSD integrate forniscono le API POSIX( sono un insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per un determinato compito: API = Advanced Programmer Interface) (POSIX è uno standard a cui debbono obbedire le API in ambiente UNIX tradizionale) che sono le BSD system calls, il modello di gestione dei processi, i livelli base di sicurezza e le relative policy, l'user id, la gestione dei permessi, la gestione della rete, il Virtual File System (incluso la strato di journaling), la crittografia, le Unix System V IPC e molte primitive (chiamata di sistema ad una routine del kernel).

 

Un accenno ad una differenza architetturale tra kernel di Windows e kernel di Mac OSX che contribuisce a spiegare le differenze di stabilità tra i due sistemi (a favore di Mac OSX) e di velocità di una stessa scheda grafica (a favore di Windows): il server grafico è implementato in kernel space in Windows ed in user space in Mac OSX. Quindi ogni "richiesta" al sistema da parte di un programma di un servizio grafico richiederà nel caso di Windows 1 solo ciclo IPC mentre mac OSX ne richiederà 2, questo spiega la maggior velocità grafica, a parità di scheda, di windows; se però per un qualsiasi motivo avviene un blocco a livello del server grafico, con windows si bloccherà pure il kernel (schermata azzurra e riavvio del sistema), mentre in Mac OSX basterà riavviare il server in user space. Lo stesso discorso vale per alcuni altri servizi ed è per questo che i kernel panic sono meno frequenti (attenzione non assenti, anche Mac OSX ha un kernel ibrido e quindi alcuni servizi sono in kernel space) che in windows.

 

 

Continuando nella linea che ci porterà a capire qualcosina di più del nostro amatissimo SO parliamo di Darwin.

 

Darwin è un sistema operativo libero che utilizza il kernel XNU. La prima versione venne presentata nel 2000 da Apple Computer e tuttora viene sviluppato dalla società dapprima con la collaborazione degli sviluppatori che aderivano al progetto Opendarwin ormai abbandonato, in seguito in modo solitario pur rilasciando il kernel open source in forma di sorgenti. Darwin è il cuore del sistema operativo Mac OSX e del nostro amato Leopard (come lo era di Tiger etc). Il kernel usato (che è lo XNU) viene identificato da un numero che corrisponde alla versione del SO attuale: ad es Leopard ha il kerne 9, leopard 10.5.1 il kernel 9.1, il 10.5.6 il kernel 9.6 e così via. Nel comune parlare potrete trovare cje qualcuno definisca il kernel di Mac OSX come Darwin kernel, ma è una definizione inesatta.

 

In ambiente Hackintosh troverete anche il termine di Darwin bootloader, che non è altro che un bootloader OpenSource in grado di far partire Mac OSX su hardware non Apple (e quindi senza EFI native ma con BIOS).

 

 

BIOS: o Basic Input-Output System: è un insieme di routine software, generalmente scritte su ROM, FLASH o altra memoria RAM non volatile, che fornisce una serie di funzioni di base per l'accesso all'hardware e alle periferiche integrate nella scheda madre da parte del sistema operativo e dei programmi. Nei computer IBM-compatibili la ROM del BIOS contiene anche il POST (power-on self-test), il primo programma che viene eseguito da un personal computer IBM compatibile dopo l'accensione. Il BIOS è il firmware (sequenza di istruzioni, integrato direttamente in un componente elettronico) del computer, perchè pur essendo costituito da routine software è parte integrante dell'hardware della scheda madre.

 

Vediamo ora cosa succede quando premiamo il tasto Power sul nostro PC: Boot Process o Bootstrap (il termine deriva dalla fascetta di cuoio cucita sul bordo posteriore degli stivali per aiutarsi a calzarli).

 

All'accensione di un PC IBM compatibile, dopo un brevissimo intervallo di tempo che porta alla stabilizzazione delle tensioni della CPU, viengono eseguite una serie di istruzioni contenute nel BIOS:

 

1) Il POST (Power On Self Test), una serie di test diagnostici per verificare il corretto funzionamento dell'hardware della scheda madre: se tutti i dispositivi controllati sono funzionanti emette un "beep" dall'altoparlantino di sistema e prosegue, ma se uno o più dispositivi fra quelli testati non funzionano, l'altoparlante emetterà una serie di bip, lunghi o corti, in numero variabile secondo un codice ben preciso che indica la periferica guasta e il tipo di problema riscontrato

 

2) cerca una scheda video installata, prima di tutto quella che secondo i suoi dati interni dovrebbe essere presente, ed esegue il POST video che si trova nella ROM interna della scheda video

 

3) cerca eventuali ROM di altri dispositivi installati e ne esegue le routine POST

 

4) mostra a video una schermata di presentazione, con alcuni dati sull'hardware di quel particolare computer

 

5) esegue altri test, come il conteggio della memoria e lo stato della tastiera. Se incontra degli errori, non ricorre al codice sonoro dei bip ma (ora può farlo) mostra un messaggio a video

 

6) compila l'inventario completo del tipo di hardware installato e delle capacità riscontrate: registra i timing della memoria, i parametri fisici dei dischi rigidi e i modi di accesso che questi supportano, le porte seriali e parallele e le loro velocità, se hanno una FIFO (First In First Out ) o no, etc.

7) (se il BIOS supporta il Plug and Play) configura automaticamente i dispositivi Plug and Play presenti e mostra un messaggio a video per ciascuno di essi

 

8) si interfaccia con la memoria CMOS, contenente i parametri di configurazione suscettibili di modifica (ora, data, settaggi del BIOS. etc), ed esegue le relative istruzioni dopo averne verificato l'integrità attraverso un algoritmo di checksum.

 

9) finalmente, cerca una unità disco da cui caricare il sistema operativo. Se c'è carica in RAM il primo settore del disco (cilindro 0, testina 0, settore 1), che corrisponde al Master Boot Record (MBR) e l'esecuzione continua da lì;

 

Da questo punto in poi il processo di bootstrap dipende dal particolare sistema operativo installato.

 

Il master boot record (MBR), nell'architettura dei PC IBM, è il settore di avvio che consiste nei primi 512 byte dell'hard disk, che contiene la sequenza di comandi necessaria per l'avvio del sistema operativo.

 

Talvolta il codice nel primo settore di un disco non è quello del sistema operativo ma quello di un particolare programma, detto boot loader, il cui compito è di mostrare a video un menu da cui l'utente può scegliere quale, fra più sistemi operativi installati, far partire: una volta fatta la scelta il boot loader carica il codice del primo settore del sistema operativo scelto, che inizia l'esecuzione come fosse stato lanciato dallo stesso BIOS.

 

Alcuni sistemi operativi possono ricevere dei parametri di boot, il boot loader pu?rmettere di definire questi parametri sia in un file di configurazione che al momento del boot.

 

Il MBR ha una dimensione di 512 byte, di cui i primi 446 sono destinati a contenere il MBP (Master Boot Program), cioè le istruzioni da eseguire quando viene avviato il disco, altri 64 byte costituiscono la master partition table, ovvero le informazioni sul partizionamento del disco, mentre i rimanenti costituiscono il master boot signature, cioè il numero "magico" che decreta la fine e la validitè dell'MBR. In particolare la partition table vera e propria si compone di 4 elementi (entry), di 16 byte l'uno, che descrivono le partizioni primarie (al massimo 4 partizioni primarie, o 3 primarie ed una estesa nella quale possono essere create partizioni logiche dalla a alla z) in cui pu?sere suddiviso il disco.

 

Tabella delle partizioni tipo MBR: Il codice scritto nel MBR effettua uno scan della tabella delle partizioni, costituita dai 4 record da 16 bytes (come accennato precedentemente), e, tramite l'intestazione della tabella delle partizioni, localizza la prima partizione primaria marcata con la flag di partizione avviabile (bootable - codice 80). Appena il codice dell'MBR trova una partizione così marcata, viene letto in memoria il primo settore di tale partizione ed eseguito il codice presente in questo settore che costituisce alla fine il boot sector, cioè il settore di boot vero e proprio, quello che in definitiva provvede ad avviare il Sistema Operativo presente.

 

Tabella della partizioni tipo GUID (o GPT): E' parte dello standard Extensible Firmware Interface (EFI). Mentre il MBR inizia con il Master Boot Code, che contiene un file eseguibile che ha lo scopo di identificare e avviare la partizione attiva, il GPT utilizza le potenzialità offerte dall'EFI per realizzare queste funzionalità. Per motivi di protezione e compatibilità il disco inizia con un riferimento MBR, cui segue il GPT stesso con la tabella delle partizioni. Lo scopo principale del MBR all'inizio del disco, è quello di evitare alle applicazioni per dischi MBR, di non riconoscere ed eventualmente sovrascrivere, i dischi GPT. A tale scopo viene indicata una singola partizione, che comprende l'intero disco GPT. Il System ID per la partizione viene fissato al valore 0xEE, indicando che il sistema usa il GPT. L'EFI ignora il MBR. I sistemi operativi a 32-bit che non gestiscono dischi GPT riconoscono questo ID e mostrano all'utente il disco GPT come inaccessibile. I sistemi operativi pi?oleti in generale riconosceranno sul disco una singola partizione di tipo sconosciuto, senza spazio libero; in questo modo vengono generalmente rifiutate le modifiche del disco, a meno che l'utente non richieda esplicitamente e confermi la cancellazione della partizione. In questo modo vengono prevenute cancellazioni accidentali del disco.

 

L'intestazione della tabella delle partizioni definisce quali blocchi del disco sono utilizzabili dall'utente. L'intestazione contiene il GUID (Globally Unique Identifier) del disco. In questa architettura troverete sempre sull'HD una prima partizione di circa 200MB, marcata come EFI partition e che conterrà il flag di boot, con le istruzioni per avviare il o i sistemi operativi presenti. Quindi su una architettura GUID, una partizione primaria viene utilizzata per, diciamo così, la partizioncina EFI e quindi a disposizione dell'utente ne resteranno solo 3 per i sistemi operativi. Tenete presente che Windows Seven compete con questa partizione con Mac OSX, per questo motivo è sconsigliabile installare prima Mac OSX e successivamente Seven (in quanto Mac OSX oltre che da GUID può essere attivato anche tramite un boot sector presente sulla sua stessa partizione), facendo il contrario, Seven non troverà il suo bootloader. Tale problema non sussiste sull'architettura MBR della tabella delle partizioni.

 

Quindi NON confondere il Master Boot Record che è una parte Fisica del Disco Rigido, sempre presente, con la Tabella delle partizioni tipo MBR o tipo GUID.

 

 

EFI: EFI è l'acronimo di Extensible Firmware Interface, una tecnologia annunciata, inizialmente solo da Intel al momento della presentazione della propria architettura IA-64 del processore Itanium, e poi ripresentata in maniera decisamente più consistente insieme a Microsoft a fine 2003.

 

Secondo Intel, quando verrà adottata in maniera consistente, EFI consentirà ai produttori di integrare nel firmware del computer applicazioni e nuove funzionalità, fra cui strumenti per la diagnostica e il ripristino dei dati, servizi di crittografia, e funzionalità per la gestione dei consumi.

 

Altra miglioria promessa da EFI è la capacità di ridurre, anche drasticamente, i tempi di caricamento del sistema operativo e quello di supportare, similmente a quanto succede con i computer palmari, forme di avvio istantaneo. L'EFI ha anche il compito di dotare il firmware del PC di un'interfaccia grafica più amichevole, facile da usare e in grado di supportare le risoluzioni video permesse dalle moderne schede grafiche. In aggiunta a questo, l'EFI fornirà un ambiente per il boot multipiattaforma capace di fornire i servizi base richiesti dai sistemi operativi (vi viene in mente per caso Boot Camp?). In un certo senso, EFI si può considerare un piccolo sistema operativo dedicato a presiedere tutte quelle operazioni che intercorrono fra l'accensione fisica della macchina e l'avvio del sistema operativo vero e proprio, superando però tutte le problematiche emerse negli anni con gli attuali BIOS.

 

A parte la già citata Apple, per il momento sembra che solo MSI abbia concrete intenzioni di proporre a breve schede madri dotate di firmware EFI. Al momento è presente in una prima versione opzionale che si affianca al tradizionale BIOS in alcune schede dotate del chipset Intel P45. Purtroppo tale versione non supporta il file system Mac OSX (Journaled) o HFS+ che dir si voglia.