di  -  venerdì 1 luglio 2011

Nel precedente articolo abbiamo parlato del KERNAL, un rudimentale OS di Commodore, ed abbiamo spiegato come esso implementi una forma di astrazione dell’hardware.

Tramite tale astrazione, il software può accedere alle funzioni base della macchina, controllarne le periferiche di I/O e gestirne le risorse, senza tuttavia conoscerne i dettagli implementativi. In termini tecnici, quella che si presenta al programmatore è una Interfaccia.

Studiando attentamente le funzioni del KERNAL ci si accorge facilmente che manca una precisa definizione del concetto di programma.

In poche parole, possiamo collocare dati ed istruzioni in modo sostanzialmente arbitrario. Le uniche funzioni offerte dal KERNAL per caricare i programmi, lavorano su array di byte “grezzi”.

Il programmatore può, quindi, avvalersi del KERNAL per impartire comandi all’hardware, ma è costretto a gestire manualmente la struttura dei suoi programmi, compresa la collocazione in memoria di codice, strutture dati, ecc…

Basta un banale cambiamento nella mappa di memoria, ad esempio portando il programma da un computer all’altro o semplicemente inserendo una espansione di RAM, per infrangere l’illusione di portabilità promessa dall’astrazione del KERNAL.

Il problema può essere parzialmente aggirato tramite la tecnica di rilocazione del codice, ma è una operazione tutt’altro che triviale e resta comunque a carico del programmatore. Esistono degli assemblatori che producono codice rilocabile, ma bisogna comunque produrre un compilato per ogni singola configurazione di memoria che si intende supportare.

Riassumendo in poche parole, abbiamo a disposizione un’interfaccia hardware che, in teoria, dovrebbe consentire lo sviluppo di codice per tutti i computer che implementano il KERNAL. In pratica ciò non è possibile, perché non vi è alcuna interfaccia software che garantisca una struttura standard per il codice e i dati in memoria.

Per superare questo ostacolo bisogna introdurre un nuovo livello di astrazione: il task.

Il task è una entità che definisce un nuovo tipo di interfaccia, cioè una serie di funzioni ed una struttura ben definita per rappresentare i programmi.

Se prima il Sistema Operativo aspettava “passivamente” di essere usato dal codice, con l’introduzione del concetto di task sarà in grado di controllare “attivamente” tale codice.

Quali sono, in concreto, le caratteristiche di un task?

Innanzitutto il task deve contenere le informazioni basilari riguardo la posizione in memoria di dati e codice. Quindi una prima, rudimentale, versione del task potrebbe essere costituita da 4 dati fondamentali: inizio e fine del segmento di codice, inizio e fine del segmento di dati.

Una volta stabilito questo standard, è possibile integrare nell’OS le funzionalità necessarie per rilocare il programma, cioè modificarne i riferimenti agli indirizzi di memoria, in modo da rendere il codice indipendente dalla Memory Map del sistema.

Per fare questo c’è bisogno di un’ulteriore informazione: la lista di tutti i riferimenti da modificare.

Questa viene generata dal compilatore (o dall’assembler), ma vedremo i dettagli di tale tecnica in uno dei prossimi articoli.

Al lettore più attento salterà subito all’occhio un particolare: dal momento che possiamo rilocare il codice per adattarlo a qualsiasi mappa di memoria, non possiamo rilocare tanti task in modo da averne in memoria più di uno contemporaneamente?

La risposta è si ed è effettivamente la base per la multiprogrammazione, cioè l’esecuzione di più task sulla stessa macchina. Il sistema dovrà tenere traccia del numero e della posizione in memoria dei vari task, pertanto saranno necessarie ulteriori informazioni per gestirli.

Ad esempio, sarà necessario assegnare un ID univoco a ciascun task, il quale verrà utilizzato come identificativo per l’assegnazione delle risorse di I/O, files, segmenti di memoria, ecc…

Nel prossimo articolo approfondiremo l’argomento studiando un caso concreto, un classico del mondo accademico: UNIX. Introdurremo i concetti di user e system mode, vedremo cos’è il context di un task e approfondiremo la questione relativa alla gestione della memoria e delle risorse.

52 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    darkcg
     scrive: 

    Ho smesso di leggere dalla prima riga, quando ho letto KERNAL.
    Si dice KERNEL, che in inglese significa NUCLEO.

  • # 2
    Antonio Barba (Autore del post)
     scrive: 

    se magari clicchi sulla parolina KERNAL (scritto tutto maiuscolo perchè è un acronimo), scopri perchè si chiama KERNAL con la A. ;-)

  • # 3
    darkcg
     scrive: 

    Antonio, KERNAL nel C64 va bene ma è considerato un mispelling dovuto all’acronimo, quindi un gioco di parole. Se mi parli di task, multiprogrammazione, assegnazione di I/O, allora stai parlando di sistemi operativi generici. E’ il termine corretto è KERNEL. Non c’è se e non c’è ma. Ma che scherziamo. Ma per favore.

  • # 4
    Antonio Barba (Autore del post)
     scrive: 

    Continui ad insistere… nel precedente articolo ho parlato del KERNAL di Commodore, perchè mai dovrei scrivere Kernel?

  • # 5
    Antonio Barba (Autore del post)
     scrive: 

    Se ti prendessi la briga di commentare DOPO aver letto, ti accorgeresti che il discorso fila perfettamente: Il Debug Monitor, il KERNAL di Commodore, le funzioni che “mancano” al KERNAL di Commodore e che portano all’introduzione del concetto di “task” dei sistemi operativi più evoluti.

    Il tutto è perfettamente coerente e lineare ;-)

  • # 6
    Monel76
     scrive: 

    Antonio il mondo gira così… Ovunque bimbiminkiasotuttoio che danno aria ai denti senza nemmeno leggere…
    Se ci fosse la possibilità di disabilitare la visione dei commenti la attiverei subito.

  • # 7
    Pluto
     scrive: 

    Da quello che so io quando un sistema è multiprogrammato significa che in memoria risiedono contemporaneamente diversi segmenti di codice di altretanti diversi programmi. Questo però non significa che i programmi sono eseguiti contemporaneamente, potrebbero benissimo essere eseguiti in modo sequenziale.

    E’ una precisazione un po’ troppo accademica. Ma il time-sharing della unità di calcolo è stata aggiunta successivamente da un punto di vista storico.

  • # 8
    Antonio Barba (Autore del post)
     scrive: 

    @Monel76:
    Non penso che darkcg appartenga a quella categoria, tuttavia ritengo che sia meglio leggere e capire, e poi scrivere con cognizione di causa :-)

    Comunque meglio tornare in topic e parlare dei task, e di come questi consentano al Sistema Operativo ti interagire attivamente con il software applicativo.

    Nel prossimo articolo parlerò di user e system mode, e il “kernel” come lo intendiamo negli OS moderni verrà introdotto nel merito del “system mode”, una particolare modalità di funzionamento delle CPU moderne. Senza System Mode non esiste distinzione tra kernel e user space, di conseguenza non esiste un kernel, quindi sarebbe stato del tutto fuori luogo parlare di “kernel” in questo articolo, mentre è molto più utile parlare del KERNAL in quanto costituisce un archetipo di OS sufficientemente adatto agli scopi didattici di questa serie di articoli :-)

  • # 9
    Gendo Ikari
     scrive: 

    [quote]Ho smesso di leggere dalla prima riga, quando ho letto KERNAL.
    Si dice KERNEL, che in inglese significa NUCLEO.[/quote]

    Congrats per la figura di merda.

    Ottimo articolo comunque.

  • # 10
    Antonio Barba (Autore del post)
     scrive: 

    @Pluto: giustissima osservazione. Volendo essere proprio pignolissimi l’esecuzione contemporanea avviene solo con processori multipli, quindi anche il multitasking classico (quello cooperativo) è un “trick” che concettualmente ripropone il meccanismo del timesharing. Il multitasking prelativo si spinge oltre, decidendo di interrompere attivamente il task in esecuzione, ma per evitare di mettere troppa carne al fuoco ho preferito rimanere sul più generico / semplificato possibile e sviluppare i vari punti chiave in più articoli dedicati…

    Chiaramente nello sforzo di semplificare mi può scappare qualche imprecisione. Spero che questo non intralci la comprensione generale dell’argomento :-)

  • # 11
    darkcg
     scrive: 

    Monel76: Non è questione di essere bimbiminkiasotuttoio. Il titolo dell’articolo menziona “i sistemi operativi” e il concetto di task. Il passaggio dal parlare dal KERNAL di C64 al concetto di task dei sistemi operativi generici non è chiaro. Anzi, leggendo quello che c’è scritto pare che i task continuino a essere parte di C64. La visione dei commenti la puoi già disabilitare, basta non usare la rotella del mouse dopo gli “Articoli correlati”.

  • # 12
    3onFire
     scrive: 

    Comunque grazie agli utenti come “darkcg” questa rubrica presenta articoli molto interessanti e commenti esilaranti(pochi, sono più quelli con cognizione!)
    Comunque ottima rubrica, preferisco le “storie” (tipo DOS o Novell) ma anche questi appunti aiutano la conoscenza

  • # 13
    Gendo Ikari
     scrive: 

    Lol, darkcg continui? Hai letto la prima riga, hai pensato di dover insegnare a qualcuno che si dice kernel (davvero??? questa sensazionale scoperta rivoluzionerà la mia vita) e non ti sei minimamente preoccupato del fatto che si parlava del KERNAL, e hai fatto una figuretta. Fine.

  • # 14
    Antonio Barba (Autore del post)
     scrive: 

    @3onFire:

    Comunque ottima rubrica, preferisco le “storie” (tipo DOS o Novell) ma anche questi appunti aiutano la conoscenza

    Grazie! Anch’io sono un appassionato delle “storie informatiche” di Felice Pescatore :-)
    Appunti Digitali è bello perchè ospita tanti stili, dal tecnico al didattico, dallo storico allo speculativo… Poi abbiamo dei lettori superpreparati che aiutano a migliorare gli articoli con i propri contributi costruttivi, e questo secondo me è fondamentale :-)

  • # 15
    Fog76
     scrive: 

    Ottimo articolo, molto interessante. Non vorrei dire fesserie, ma il time sharing e multiprogrammazione non possono essere eseguite anche con processori ad 8 bit? Mi sembra di ricordare che alcuni sistemi con z80 a bordo erano multiutente? O le cose non centrano nulla tra loro?

    @darkcg: complimenti per la figura miserrima…

    Ciao

  • # 16
    Antonio Barba (Autore del post)
     scrive: 

    @Gendo Ikari: dai su, non rimarchiamo gli errori degli altri. Può capitare a tutti una svista, per fretta o disinteresse. Mi piacerebbe leggere da parte di darkcg, se ne ha voglia, una critica (positiva o negativa che sia, purchè costruttiva) sui meriti e i temi specifici dell’articolo.

    Fate come l’utente Pluto, che ha evidenziato (con competenza e precisione) un particolare molto sottile che mi era sfuggito durante la stesura dell’articolo. Sono queste le critiche che apprezzo di più :-)

  • # 17
    Pluto
     scrive: 

    Il time-sharing e la multiprogrammazione si può implementare in tutte le architetture che abbiano un minimo di supporto hardware, tipo un timer. Se poi l’architettura è ad 8 o 64 bit non fa molta differenza dal punto di vista concettuale.
    Anzi la multiprogrammazione può anche essere solo software.

  • # 18
    Antonio Barba (Autore del post)
     scrive: 

    @Fog76: si, il timesharing è possibile anche su questi semplici processori :-)
    Si può anche implementare il multitasking cooperativo senza particolari problemi. Il multitasking prelativo prevede un supporto hardware per generare interruzioni a tempo, un supporto comunque molto facile da implementare tramite un semplice timer, fisso o programmabile, collegato ad una linea fisica di interrupt. Spiegherò i meccanismi più avanti, come sai la materia è molto vasta e complessa, e vorrei evitare di mettere troppa carne al fuoco.

  • # 19
    Antonio Barba (Autore del post)
     scrive: 

    oops… Pluto mi ha anticipato…

  • # 20
    Pluto
     scrive: 

    oops… non ti rubo più la scena :)

  • # 21
    Fog76
     scrive: 

    Grazie per le delucidazioni, quindi ricordavo bene :-)

  • # 22
    Gendo Ikari
     scrive: 

    Ma come è possibile avere un multitasking (preemptive o no) su un processore senza che vi siano istruzioni specifiche per la protezione della memoria?

  • # 23
    Antonio Barba (Autore del post)
     scrive: 

    @Pluto: ho fatto una piccolissima modifica all’articolo

    …multiprogrammazione, cioè l’esecuzione di più task sulla stessa macchina.

    Tolta la parola “contemporaneamente” che causava l’imprecisione che mi hai fatto notare.

  • # 24
    Antonio Barba (Autore del post)
     scrive: 

    @Gendo Ikari:
    La protezione della memoria è “fortemente consigliata” nei sistemi multitasking, ma esistono dei sistemi che non la implementano. AmigaOS è probabilmente l’esempio più famoso.

    Senza la protezione della memoria i vari task potrebbero interferire a vicenda, se contengono dei difetti di programmazione (ad esempio puntatori non inizializzati, oppure array con indici fuori dai limiti), e in genere ciò accade abbastanza spesso. Oggi esistono sistemi multitasking senza protezione della memoria in ambito embedded, dove le CPU sono semplici microcontrollori con sistemi operativi minimali che gestiscono più task, ma non proteggono la memoria. In ambito embedded il problema spesso non sussiste, in quanto il dispositivo funzionerà sempre con gli stessi (pochi) task ed è quindi relativamente semplice eliminare tutti i bug di memoria dal sistema.
    Ovviamente parliamo di sistemi estremamente dedicati, che non sono progettati per far girare codice arbitrario, ma i task sono quelli specifici previsti dal costruttore.

  • # 25
    aeternal
     scrive: 

    Articolo certamente interessante, tuttavia credo lo sia ancora di più il prossimo quindi attendo con impazienza :)

    Per quanto riguarda la guerra KERNAL o KERNEL poco importa, Antonio ha messo il riferimento all’altro post per giustificare l’utilizzo di questo termine, darkcg continua a voler fare il purista. Abbiamo capito la differenza, è proprio necessario continuare? Credo ci sia altro di ben più interessante da poter discutere.

    In ogni caso complimenti Antonio, bell’articolo.

  • # 26
    #H
     scrive: 

    Complimenti per questa serie di articoli davvero interessanti!

    Posso chiederti quali letture consiglieresti a qualcuno che cerca di avvicinarsi al mondo della programmazione di sistema? (letteralmente la progettazione e la scrittura di sistemi operativi :P)

  • # 27
    Antonio Barba (Autore del post)
     scrive: 

    @H:

    Ci sono testi teorici e testi pratici. Come testi teorici puoi dare un’occhiata ai classici di Andrew Tanenbaum, per quanto riguarda i sistemi operativi Unix-like. Poi c’è il Silberschatz (il libro dei dinosauri) che copre abbastanza bene anche sistemi operativi diversi (come Windows, o i sistemi embedded).

    Prima parti con i libri teorici per farti un’infarinatura, poi scegli un OS di riferimento su cui concentrarti e scegli un testo pratico specifico.
    Se ti interessa Unix, ci sono degli ottimi testi sugli internals di FreeBSD che consiglio caldamente per l’elevata qualità della documentazione. Su Linux è stato scritto moltissimo, ma non è adatto a scopo didattico in quanto troppo complesso e per nulla coerente. Studia Linux soltanto se hai una necessità lavorativa (tipo scrivere un driver per un nuovo dispositivo), ma non prenderlo a modello didattico. FreeBSD è sicuramente il miglior sistema per conoscere UNIX.

    Se ti interessano sistemi simili a Unix ma “atipici”, puoi prendere il BeBook (manuale di programmazione di BeOS), che è perfettamente valido anche per il suo clone open source Haiku OS.

    Se ti interessano i sistemi Windows, ci sono delle ottime pubblicazioni Microsoft Press relative agli internals di Windows. E’ utile soprattutto studiarne le versioni “embedded” come Windows CE, perchè Microsoft ne mette a disposizione i sorgenti con licenza Shared Source, quindi puoi studiarli veramente nel dettaglio quasi come se fossero Open Source.

    Se ti interessa Amiga, ci sono i vecchi ma interessanti Rom Kernel Manuals.

  • # 28
    #H
     scrive: 

    Grazie per la risposta immediata :)

    Avrei però un’altra domanda. E se cercassi qualcosa di generico? Cioè, a me interesserebbe imparare cosa serve per realizzare un sistema operativo qualsiasi, mentre da quanto ho capito i testi di cui hai scritto parlano ogniuno in riferimento ad un sistema operativo diverso. Non c’è qualcosa che tratti di tecniche di programmazione in generale?
    Infondo, tutti i sistemi operativi hanno uno scheduler, un kernel, un file system, uno gestore della memoria, un’interfaccia ecc.

  • # 29
    Antonio Barba (Autore del post)
     scrive: 

    Certo, il Silberschatz che ho citato all’inizio è quello che fa per te :-)

  • # 30
    Pluto
     scrive: 

    Forse può interessare anche questo link:

    http://wiki.osdev.org/Main_Page

  • # 31
    Cesare Di Mauro
     scrive: 

    Per classificare un film di Kubrick non serve guardarlo tutto, ma sono sufficienti i primi minuti.

    E’ ben noto, infatti, che “2001: Odissea nello Spazio” è un documentario su alcuni scimmioni primitivi, mentre “Arancia Meccanica” un porno pre-adolescenziale (i protagonisti bevono ancora il latte!).

    Per il resto, ottimo articolo; come sempre. ;)

  • # 32
    #H
     scrive: 

    Perfetto grazie mille.

    @Cesare Di Mauro: Giuro che questa è la smerdata più bella che abbia mai letto xD

  • # 33
    Simon71
     scrive: 

    @DARKCG

    Ma ci sei o ci fai???

    Si chiamava KERNAAALLLLL, con la A….

    Allora mo’ adesso “Thunderbolt” la chiamo LIGHTPEAK!!!
    Se in APPLE la chiamano ThunderBOLT mi riferisco A LEI come THUNDERBOLT!!

    Sai quanti “mispelling” esistono in linguistica?? Molti di loro sono diventati logismi a se stanti?

    Eccheccavolo! Sono concetti così difficili da comprendere?

  • # 34
    jpage89
     scrive: 

    @antonio
    eventuale documentazione su NetBSD, a livello programmativo, esiste o mi devo rifare a FreeBSD?

  • # 35
    Antonio Barba (Autore del post)
     scrive: 

    @jpage89: mi spiace ma non sono molto informato su NetBSD. La documentazione specifica temo sia di minore quantità e qualità comunque, in quanto FreeBSD è portato avanti da un team più grande e c’è dietro un’intera università.

  • # 36
    Pluto
     scrive: 

    Anche Minix dovrebbe essere un buon sistema operativo didattico della famiglia UNIX. Tanenbaum lo ha inventato apposta per le sue lezioni.

  • # 37
    Antonio Barba (Autore del post)
     scrive: 

    @Pluto: come introduzione va bene, ma Minix non supporta il symmetric multiprocessing e non ha nemmeno la memoria virtuale, quindi è ormai obsoleto e non rispecchia più un “Modern Operating System” come il titolo del libro vorrebbe suggerire. Per il resto, anch’io ho studiato da quel libro e lo conosco abbastanza bene da suggerire il più moderno e completo Silberschatz :-)

  • # 38
    Marco
     scrive: 

    “Ma come è possibile avere un multitasking (preemptive o no) su un processore senza che vi siano istruzioni specifiche per la protezione della memoria”

    A rigor di logica, parlando di “massimi sistemi”, si può perfettamente realizzare un sistema multitasking, a prelazione o no, con o senza protezione della memoria, su un qualsiasi calcolatore che sia “Turing completo”.
    Il supporto hardware ovviamente aiuta e soprattutto incrementa esponenzialmente l’efficienza del tutto.

  • # 39
    Marco
     scrive: 

    “e non rispecchia più un “Modern Operating System””

    La modernità di Minix sta nel fatto che si tratta di un microkernel, e in questo senso l’ho apprezzato molto (e ancora, purtroppo, all’avanguardia).

  • # 40
    Antonio Barba (Autore del post)
     scrive: 

    @Marco: Minix implementa un modello secondo me appena sufficiente per uno scopo didattico, non lo considero minimamente indicativo di come dovrebbe essere un sistema operativo moderno, considerando che dentro la parola “moderno” ci stanno concetti come Symmetric Multiprocessing, Memoria Virtuale, Virtualizzazione, Fault Tolerance e molto altro. Manca anche un vero sistema di scheduling e bilanciamento dell’I/O, il che significa che non gestisce in modo ottimale gli storage multipli (RAID ad esempio).

    Insomma, è un sistemino che va bene per giocare un po’, ma non lo consiglierei a chi ha intenzioni di sviluppare OS a livello professionale.

  • # 41
    Marco
     scrive: 

    @Antonio #40
    Si, ma le caratteristiche di un microkernel permettono di implementare caratteristiche che su un kernel monolitico sono al limite della praticabilità: come la fault tolerance da te citata, a causa delle vaste porzioni di codice eseguite con privilegi elevati, e, per gli stessi motivi, sistemi trusted o sicuri degni di tale nome.
    In confronto, perdonami, uno scheduler per i processi o un’implementazione SMP con un giant lock, sono bazzecole: di fatto le trovi in quasi tutte le implementazioni.
    Che Minix sia un giocattolino non v’è dubbio, ma per me la modernità sta più in un QNX o un Plan9, anche se a livello di caratteristiche “di uso generale” impallidiscono nei confronti di un Linux 2.2.

  • # 42
    Antonio Barba (Autore del post)
     scrive: 

    A livello puramente teorico, un microkernel dovrebbe semplificare l’implementazione di alcune caratteristiche. La separazione dei servizi critici in processi separati consente di implementare un reincarnation server in modo triviale (e qui rientra buona parte della fault tolerance).
    Tuttavia le altre caratteristiche, come la sicurezza e le prestazioni, sono totalmente slegate dalla struttura del kernel.

    La quasi totalità degli exploit di sicurezza sfrutta vulnerabilità di applicazioni in user space (tipicamente a livello di network) per eseguire codice arbitrario con privilegi di root, sempre rimanendo in user space comunque. Anche per quanto riguarda le prestazioni, tutti i microkernel moderni hanno reintegrato in kernel space alcune parti critiche del VFS e alcuni device drivers.
    In un sistema a microkernel la procedura sarebbe totalmente analoga. Esistono infatti anche malware per Symbian e Windows CE, che sono due sistemi a microkernel molto più avanzati di Minix.

    I sistemi trusted, poi, vengono implementati a maggior ragione in un ambiente virtualizzato, meglio se con hypervisor e separazione dei domini in hardware (architettura praticamente standard nei POS con Windows CE). Sotto l’hypervisor puoi anche mettere il più scrauso dei sistemi DOS, perchè a quel punto è l’hardware a proteggerti dal sistema esposto alla rete / utente.

    Per le prestazioni non penso ci sia niente da dire, i kernel monolitici (o microkernel ibridi con VFS in kernel-space) vincono a mani basse.
    Inoltre i microkernel, soprattutto quelli che si basano pesantemente sulle message queues come CMU Mach, hanno delle penalità sui sistemi multiprocessore che crescono con il quadrato del numero dei processori. Per ogni messaggio hai potenzialmente N processori che tentano di lockare altri N-1 processori. Questo viene risolto nei sistemi ibridi tramite shared memory, meglio se con architettura NUMA (dove ogni processore ha una sua memoria privata, oltre alla memoria di sistema), in cui è possibile scegliere il livello di località di un messaggio, lockando così soltanto una parte dei processori.
    Con un microkernel i sistemi NUMA diventano invece ingestibili, perchè bisogna replicare dentro ogni regione una copia di ogni service server, oppure bisogna fissare i service servers dentro delle regioni specifiche, trasformando così il sistema in uno di tipo Asymmetric Multi Processing.

    Insomma, non è così banale la superiorità dei microkernels. Negli anni ’90 andavano fortissimo, ma credo che stiano facendo la stessa fine dei processori RISC, cioè finiscono per essere sfruttati in forma pesantemente modificata rispetto al design originale. Con questo intendo dire che, come i processori moderni siano intimamente dei RISC con interfaccia CISC, allo stesso modo i sistemi operativi più evoluti tendono ad avere un microkernel alla base, modificato in modo da racchiudere strutture tipicamente monolitiche (prime fra tutte il VFS e il networking, in alcuni casi anche parte della gestione grafica).

    Penso comunque di affrontare anche questi temi in modo più esaustivo con il procedere degli articoli :-)

  • # 43
    Marco
     scrive: 

    “La quasi totalità degli exploit di sicurezza sfrutta vulnerabilità di applicazioni in user space (tipicamente a livello di network)”

    Ma l’escalation di privilegi alla fine avviene perché c’è del codice insicuro che gira in kernel space :-) C’è una bella differenza a fare auditing su 10.000 righe e su 1 milione: uno dei pochi kernel certificato EAL7 (verificato formalmente) è un microkernel della famiglia L4 ( http://ertos.org/research/sel4/ ).

    D’accordo su tutto quello che dici, ma si tratta di retrofit di caratteristiche su kernel vecchi, tenuti in piedi per motivi di retrocompatibilità. Per questi ad esempio raggiungere livelli di sicurezza ragionevoli è quasi impossibile, od economicamente non conveniente.

    La ricerca sui sistemi operativi, anche non a livello accademico, è ben oltre al concetto di kernel monolitico (Singularity, Midori, Inferno, …), dato che si parlava di scribacchiare un kernel partendo da zero, mi sembrava doveroso fare delle osservazioni.

    “Penso comunque di affrontare anche questi temi in modo più esaustivo con il procedere degli articoli”

    Non mancherò certo di leggerli :-)

  • # 44
    Antonio Barba (Autore del post)
     scrive: 

    @Marco:

    l’escalation dei privilegi avviene perchè inietti un buffer contenente istruzioni macchina, dentro lo stack di un programma con privilegi di root. Nemmeno lo tocchi il kernel space, per cui dietro potrebbe esserci un qualsiasi kernel di qualsiasi tipo e non cambierebbe nulla.

    EAL7 è stato verificato formalmente, ottimo esercizio di stile, ma hai visto quant’è piccolo e quante poche syscalls implementi?
    Non è un kernel adatto a reggere un sistema operativo senza circondarlo di un altro centinaio di service servers. E quelli poi come fai a verificarli formalmente?

    In secondo luogo, ti ho citato i microkernels di SymbianOS e Windows CE come esempi di microkernel moderni. Non sono assolutamente kernel vecchi riadattati.
    Linux è un kernel vecchio riadattato con pezzi in userspace (FUSE ad esempio), XNU (di MacOS X) è un vecchio CMU Mach riadattato (uno dei primi microkernels ad avere un utilizzo commerciale).
    Singularity è un kernel di ricerca, non verrà mai utilizzato su un prodotto commerciale, e quindi si pone allo stesso livello dei kernel accademici.
    Come tali, questi kernel servono da modello semplificato per studiare soluzioni teoriche da applicare successivamente a kernel di produzione.
    Sono, di fatto, dei kernel con caratteristiche “nuove”, ma che risolvono peggio dei problemi già brillantemente risolti in passato con tecniche più efficaci.
    Ripeto, e qui entro nelle mie considerazioni personali, che secondo me i microkernels puri (a la L4 Pistachio, per intenderci) abbiano già avuto il loro momento di gloria negli anni ’90 al pari dei processori RISC, dove si pensava che un’architettura semplice dovesse automaticamente risultare migliore in tutto e per tutto. Oggi invece vediamo RISC e microkernels relegati a sistemi embedded, che necessitano di modeste prestazioni, mentre processori più complessi accompagnati da sistemi operativi mastodontici che servono da colonna portante per impianti di calcolo ben più importanti e prestanti.

  • # 45
    Marco
     scrive: 

    “EAL7 è stato verificato formalmente, ottimo esercizio di stile, ma hai visto quant’è piccolo e quante poche syscalls implementi?”

    EAL, forse non sono stato abbastanza chiaro, non è un kernel, ma un protocollo standard internazionale per valutare la sicurezza di un prodotto IT:

    http://en.wikipedia.org/wiki/Evaluation_Assurance_Level

    “E quelli poi come fai a verificarli formalmente?”

    Non è strettamente necessario, visto che girano in user space ;-)

    “dentro lo stack di un programma con privilegi di root”

    E’ proprio questo il punto, con un kernel monolitico il codice che gira con questi privilegi è molto di più (grafica in testa!): basta che fai una find / -type f \( -perm -4000 -o -perm -2000 \) -print :-)

  • # 46
    Antonio Barba (Autore del post)
     scrive: 

    azz.. ho fatto uno strafalcione sul EAL7 :-)

    chiaramente mi riferivo a L4 che implementa solo 7 syscalls nelle versioni più “pure”.

    Per quanto riguarda i privilegi di root, sono stati risolti tramite il meccanismo delle Capabilities (implementato in Linux con SELinux e AppArmor, e in Windows con UAC). Invece di dare tutti i privilegi di root ad un certo processo, si usa un meccanismo che assegna i privilegi in modo più “fine”.
    Un driver in userspace che richiede, ad esempio, l’accesso alla scheda grafica, non dovrà più girare come root, ma sarà sufficiente applicargli la capability “Uses Graphics”. Se viene “bucato” tale driver, non potrà andare a comandare il filesystem, ma potrà soltanto interferire con la grafica.

    Ancora una volta, tale sistema è stato sperimentato prima con i microkernels in ambito accademico, e successivamente implementato su sistemi commerciali basati su kernel ibridi (appunto Windows Vista / NT 6.0 ne è un esempio).
    I microkernels sono comodi per fare esperimenti, sono semplici da implementare e da studiare. Quando li metti in un sistema di produzione però bisogna valutare anche l’impatto delle prestazioni. Per questo motivo sono relegati ai soli sistemi embedded (QNX appunto, ma anche Windows CE, Symbian e altri).

  • # 47
    Marco
     scrive: 

    Beh, discussioni su questi argomenti ce ne sono stati (e ce ne saranno) a iosa. Preferisco non aggiungere altro se non i complimenti per gli articoli (e non vedo l’ora di leggere le prossime puntate).

  • # 48
    Antonio Barba (Autore del post)
     scrive: 

    Si, in effetti il campo è tanto vasto che la discussione potrebbe continuare per secoli :-)

    Non che la cosa mi dispiaccia, anzi! Però siamo andati velocemente fuori argomento… ti aspetto al prossimo articolo, che porterà sicuramente nuovi spunti di discussione ancora più interessanti :-)

  • # 50
    #H
     scrive: 

    P.S. Il wiki di OSDev è fantastico e sopratutto è scritto in un inglese che riesco a leggere in modo fluido senza problemi.

  • # 51
    ReNeSiS STyLe
     scrive: 

    @ #H

    Ti ringrazio di aver segnalato quei libri, soprattutto il primo che finirà nel mio carrello virtuale :D

  • # 52
    #H
     scrive: 

    @ReNeSiS STyLe
    Non sono troppo sicuro che siano proprio quelli. Esistono svariate edizioni per ogniuno, per questo ho chiesto se fossero giusti :P

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.