Che materia stai cercando?

Sistema Operativo NACHOS Appunti scolastici Premium

Appunti di Sistemi Operativi del prof. Mazzeo su NACHOS - Not Another Completely Heuristic Operating System: Introduzione, Compilare ed eseguire Nachos, Struttura del direttorio, Problemi incontrati, Architettura e design, Nachos e simulatore macchina, Threads, Scheduler e Multiprogrammazione, File System, Memoria Virtuale.

Esame di Sistemi operativi docente Prof. A. Mazzeo

Anteprima

ESTRATTO DOCUMENTO

attivato (la macchina di prova è a singolo processore), viene chiamata la

funzione Scheduler::Run, la quale a sua volta inizierà la sequenza di operazioni

necessarie per il cambio di contesto. Scendendo più nei dettagli possiamo notare

come in questa funzione dapprima si salva lo stato del vecchio thread

(Thread::SaveUserState per salvare lo stato dei registri della CPU e

AddrSpace::SaveState per le informazioni riguardo lo spazio degli indirizzi),

poi si disabilitano gli interrupts e successivamente viene chiamata la funzione

assembly di basso livello SWITCH (machine-dependent e definita in switch.s) che

attua il cambio di contesto modificando gli opportuni registri della CPU. Nel

caso in cui il processo non dovesse terminare volontariamente (finire il suo

compito) prima di X unità di tempo, al generarsi della specifica interruzione lo

scheduler lo interromperebbe e metterebbe in una coda, prendendone un altro

dall’inizio della stessa per eseguirlo (Round Robin).

3.3 File System

Secondo le scelte fatte nel Makefile, Nachos è compilato con una differente

implementazione del file system. La definizione FILESYS_STUB forza l’uso di una

classe per questo sottosistema che utilizza syscall UNIX per la gestione dei

file. Non utilizzando la su citata opzione si utilizza l’implementazione Nachos

del file system, che però soffre di limitazioni, anche se molte di facile

risoluzione. Per eseguire le operazioni di lettura e scrittura il file system

comunica, attraverso opportune chiamate del kernel di Nachos, con il simulatore

macchina e, più precisamente, con l’emulazione del disco rigido

(machine/disk.cc). Il disco è astratto a partire da un normale file UNIX

presente nella cartella di lavoro di Nachos, che è trattato alla stregua di un

vero disco: è suddiviso in settori e le operazioni di lettura/scrittura sono

adeguatamente soggette ad errori e ritardi. Le due più grandi limitazioni di cui

soffre questa implementazione del file system è la mancanza di un albero del

direttorio e la grandezza dei file fissa. Lo spazio dei nomi dei file è infatti

completamente piatto, ovvero oltre al direttorio radice non esistono ulteriori

direttori di livelli successivi. Una possibile semplice (ma inefficiente)

5

soluzione a questo problema, sperimentata durante la stesura di questa analisi

del sistema operativo, è stata implementata modificando la classe FileHeader ed

aggiungendo un campo di tipo intero che funge da bitfield contenente gli

attributi del file (e quindi anche se il file è un direttorio o un semplice

file). Si è reso quindi necessario modificare la classe FileSystem (nelle

funzioni Create ed Open) ed adattare la struttura DirectoryEntry (in

6

filesys/directory.h) trasformando il campo InUse in un più efficiente bitfield .

Anche la classe OpenFile ha avuto bisogno di alcune modifiche.

O Nachs File System (non STUB)

S S

Emulatozione Accesso i

Disco Sincrono m

(disk.cc) (syncdisk.cc) u.

UNIX File System

F.3.3.1 File System di Nachos

5 Purtroppo non si è riusciti ad ottenere una versione completamente funzionante per la data di consegna di questa

analisi.

6 Per memorizzare valori booleani è possibile utilizzare 1 solo bit, invece che occupare tutti i bit di una variabile C++

bool. I restanti bit possono essere usati per memorizzare altre opzioni, nel nostro caso se l’header è di un direttorio o di

un file normale.

© 2006 Dexter - dexterp37@gmail.com 7

3.4 Memoria Virtuale

L’uso della memoria virtuale comporta numerosi vantaggi tra cui lo svincolo

della grandezza del programma da quella della memoria fisica e la possibilità di

allocare dati in spazi fisici non continui pure continuando ad utilizzare

indirizzi virtuali contigui. In Nachos sono implementate due tecniche per la

gestione della memoria: paginazione e Translation Lookaside Buffer (TLB).

Contrariamente alla teoria studiata, in questo sistema operativo la TLB non

funge da cache per la tabella delle pagine, ma la sostituisce completamente; se

il sistema TLB è attivo ed una pagina non vi è presente, è generato un PageFault

(anche se la pagina potrebbe già essere in memoria!) ma non si accede alla

tabella delle pagine. La traduzione degli indirizzi avviene come di consueto,

individuando il page frame e l’offset.

Ogni riferimento alla lettura o alla scrittura di valori in memoria è

soddisfatto attraverso le funzioni Machine::ReadMem e Machine::WriteMem. Queste

due funzioni fanno uso della routine Machine::Translate, che è il vero cuore del

7

sistema di traduzione degli indirizzi virtuali in indirizzi fisici. Segue un

estratto di tale funzione, con i relativi commenti.

// calculate the virtual page number, and offset within the page,

// from the virtual address

vpn = (unsigned) virtAddr / PageSize;

offset = (unsigned) virtAddr % PageSize;

if (tlb == NULL) { // => page table => vpn is index into table

if (vpn >= pageTableSize) {

DEBUG(dbgAddr, "Illegal virtual page # " << virtAddr);

return AddressErrorException;

} else if (!pageTable[vpn].valid) {

DEBUG(dbgAddr, "Invalid virtual page # " << virtAddr);

return PageFaultException;

}

entry = &pageTable[vpn];

} else {

for (entry = NULL, i = 0; i < TLBSize; i++)

if (tlb[i].valid && (tlb[i].virtualPage == vpn)) {

entry = &tlb[i]; // FOUND!

break;

}

if (entry == NULL) { // not found

DEBUG(dbgAddr, "Invalid TLB entry for this virtual page!");

return PageFaultException; // really, this is a TLB fault,

// the page may be in memory,

// but not in the TLB

}

}

7 Indirizzi che non corrispondono direttamente ad indirizzi fisici, ma dai quali questi ultimi possono essere agevolmente

ricavati attraverso una preposta funzione y = f(x)

© 2006 Dexter - dexterp37@gmail.com 8

4. Spunti, riflessioni ed approfondimenti

4.1 Microkernel vs Kernel monolitico… vs no Kernel

E’ stupefacente come la mente umana tenda a (ri)classificare le informazioni in

categorie ed innovare, spesso ricalcando la strada tradizionalista, riproponendo

gli stessi schemi con modifiche più o meno sostanziali. Al centro dei numerosi

dibattiti riguardanti i sistemi operativi [4], si pone la spinosa questione

riguardo la struttura e la presenza del kernel, ovvero del cuore di questi

complessi software di gestione delle risorse.

I primi sistemi operativi progettati contemplavano una struttura del kernel

detta monolitica, in quanto operavano una completa astrazione dell’hardware

mediante interfacce di alto livello e realizzando i servizi necessari (gestione

memoria, processi e sincronizzazione) mediante chiamate di sistema o primitive,

8

il tutto in un unico “blocco” eseguito in supervisor mode . Questa tecnica,

riconosciuta obsoleta già dai primi anni ’90, è ancora in uso in molti sistemi

operativi (UNIX, Linux, etc.) in quanto, se implementata bene e priva di bug,

determina un kernel molto efficiente. Tra i principali svantaggi di questa

architettura figurano la grandezza del kernel in memoria, l’eccessiva

integrazione del sistema (che può essere considerata una lama a doppio taglio,

dato che un bug in una componente potrebbe risultare in un crash per tutto il

9

sistema) e la difficoltà di aggiungere nuovi dispositivi hardware.

Una seconda strada percorsa si è concretizzata nel 1985 nel sistema operativo

Mach, uno dei primissimi prototipi dell’università Carnegie Mellon ad

architettura a microkernel. In un sistema del genere il kernel offre una

semplice astrazione sull’hardware e gestisce intimamente operazioni basilari

quali la gestione dei thread, gli spazi di indirizzamento, la comunicazione tra

processi ed i timer, delegando a programmi che non vengono eseguiti in

supervisor mode chiamati servers l’implementazioni di altre funzionalità

(networking, etc.). Tra i principali vantaggi di questo approccio risalta la

stabilità del sistema rispetto ai crash dei singoli server (un crash in un

server, infatti, non produce il blocco della macchina), il facile mantenimento e

sviluppo e la possibilità di personalizzazione del sistema (l’amministratore può

infatti decidere quali server avviare al boot, senza ricompilare il kernel). Il

problema delle prestazioni rappresenta, invece, la palla al piede di questa

tecnologia: le comunicazioni tra server-server e server-kernel necessitano di

sistemi di comunicazioni estremamente veloci ed efficienti. Esistono inoltre

alcune varianti di questo modello, tra cui: microkernel modificato (ovvero un

ibrido tra kernel monolitico e microkernel, che assorbe nel kernel alcuni server

per limitare il numero di chiamate esterne per migliorare le prestazioni) e

esokernel (che non effettua una vera e propria astrazione hardware, lasciando ai

programmi utente la libertà di accedere a tutte le risorse ed aree di memoria).

Gli approcci appena descritti, giustificano la necessità di un’entità centrale

che controlli, gestisca e decida: in poche parole, che garantisca sicurezza. La

maggior parte dei sistemi operativi esistenti segue questa strada, ma esistono

alcuni sistemi operativi che fanno a meno del kernel (Unununium [5], TUNES [6]).

Il principio guida di questi sistemi sta nel fatto che la sicurezza (intesa come

controllo dell’accesso alle aree di memoria) è gestita a livello del linguaggio

di programmazione: i programmi vengono, infatti, eseguiti allo stesso livello

del sistema operativo. Il problema della protezione e separazione della memoria

si presenta solo con i linguaggi (C, C++, Assembly) che permettono l’accesso

arbitrario alla memoria. Nulla, in questi sistemi, è una entità statica e

totalitaria, per la quale i dati sono obbligati a passare; il sistema non è

altro che una collezione di oggetti dinamici e rimpiazzabili che cooperano tra

loro, secondo paradigmi anch’essi variabili. Concetti come desktop, file e file

8 Flag hardware che stabilisce se il software in esecuzione può agire su determinate aree critiche (registri macchina,

tabelle dei descrittori, etc.)

9 Si rende infatti necessario ricompilare il kernel, per aggiungere l’adeguato modulo driver

© 2006 Dexter - dexterp37@gmail.com 9

system sono in questi sistemi abbandonati in favore di nuovi paradigmi (si

rimanda alla sezione Riferimenti per ulteriori approfondimenti).

4.2 File System: crittografia e protezione

Un ruolo di vitale importanza, spesso sottovalutato, per la sicurezza di un

sistema informatico è giocato dal File System. Come già noto il file system è

quel sottosistema logico del sistema operativo che si occupa dell’accesso e

dell’archiviazione dei dati. Per la maggior parte dei sistemi operativi

attualmente in circolazione, esistono software, più o meno di facile uso, che

permettono di ignorare completamente i permessi sui file, permettendo ad un

utente che non ha le dovute credenziali di accedervi. Un possibile approccio,

che vuole essere solo uno spunto per ulteriori approfondite riflessioni, è dato

dalla crittografia a chiave pubblica/privata potenzialmente applicabile dal

kernel. La potenza dei moderni calcolatori unita al supporto per questo tipo di

crittografia realizzata via hardware permetterebbe una tale implementazione.

Quello esposto in seguito è un esempio del possibile funzionamento di tale

sistema.

Supponiamo che, al momento dell’installazione del sistema operativo, il disco

sia preparato (formattato) e nei primi settori sia creata una Tabella Delle Aree

(TDA). Questa tabella, contenente tante righe quanti sono i blocchi del disco,

10

indicherà al sistema operativo il blocco di partenza di ogni area del disco, la

quale è a sua volta associate ad un utente. La tabella potrebbe presentarsi come

segue: Utente

001 Blocco 1000

105 Blocco 5000

110 Blocco 15000

115 Blocco 20000

… Blocco N

… Blocco …

Tab 4.2.1 Tabella Delle Aree

L’utente con il codice 001 è l’utente comunemente noto come root, in altre

parole l’amministratore. Nel nostro caso il nome utente sistema operativo

(sysop) sarebbe più consono. L’utente sysop è l’unico in grado di creare altri

utenti. All’atto di creazione di un nuovo utente, è individuata un’area libera

sul disco e generata una coppia di chiavi uniche, una privata per uso

dell’utente proprietario, e una pubblica utilizzata dagli altri utenti, la prima

salvata nell’area dell’utente appena individuata l’altra nell’area in chiaro

solamente

(AIC). Questa area sarà adibita a contenere i file di quell’utente.

L’area del disco dell’utente sysop corrisponde all’area che contiene i file del

sistema operativo.

10 Ogni area è in realtà una partizione del disco delegata all’uso da parte di un solo utente

© 2006 Dexter - dexterp37@gmail.com 10

Ecco come si presentano i dischi, prima e dopo la creazione di un nuovo utente:

TDA TDA

(Blocchi 0-10) (Blocchi 0-10)

AIC AIC

(Blocchi 11-999) (Blocchi 11-999)

sysop 001 sysop 001

(Parte dal (Parte dal

blocco 1000) blocco 1000)

. . .

. . . Pippo 105 (Parte dal

Blocchi non blocco 5000)

Utilizzati

. . . Pluto 110 (Parte dal

blocco 15000)

. . .

Tab 4.2.2 Tab 4.2.3

Disco prima della Disco dopo la creazione

creazione utenti degli utenti Pippo e Pluto

Il primo blocco di ogni area utente contiene la chiave privata, utilizzata per

crittografare in modo automatico, da parte del file system al momento delle

chiamate dell’utente per effettuare I/O su disco. Così facendo, solo l’utente

proprietario dei file nella sua area potrà accedervi. La copia dei file da un

area utente all’altra può invece avvenire in due modi: il primo consiste nel

copiare il file nell’AIC per poi essere spostato, ad opera dell’utente

ricevente, nella sua area di destinazione (ma questo comporterebbe una falla

nella sicurezza, in quanto il file una volta copiato nella AIC sarebbe in

chiaro). La seconda strada consiste nell’usare le chiavi pubbliche disponibili

nell’AIC per crittografare ancora, una volta letto dall’area di partenza, il

file usando la suddetta chiave, in modo che solo il destinatario sia in grado di

decifrarla, e quindi copiarlo nell’AIC.

I principali svantaggi di questo approccio sono la poca flessibilità (è infatti

molto complesso, se non impossibile, ridimensionare le aree una volta create),

l’impossibilità di recuperare i dati in caso di perdita dei dati di accesso e la

possibile lentezza delle operazioni di crittografia; tali svantaggi sono però

ampiamente bilanciati dal margine di sicurezza teorico garantito dal sistema.

4.3 Nachos: sulla strada dei 64 bit

Il sistema operativo Nachos non è stato progettato tenendo conto del passaggio

da sistemi a 32 bit a quelli a 64 bit: per questo motivo risulta inutilizzabile

su architetture di questo tipo a meno di effettuare alcuni cambiamenti.

L’adattamento della versione 3.4 per l’esecuzione su architettura a 64 bit ha

comportato cambiamenti in molte parti del codice, schematizzabili come segue:

- Casting da void* a int: in architetture a 32 bit questo casting è

valido, in quanto l’indirizzo puntato da void* può essere rappresentato

nell’int, la cui dimensione è 4byte (32bit). Il tipo long long è invece

stato utilizzato per memorizzare indirizzi a 64 bit.

- Modifica del codice assembly nel file switch.s per tener conto delle

nuove dimensioni dei tipi

Questa sperimentazione non ha purtroppo portato i risultati sperati (ovvero un

eseguibile per Linux con kernel a 64 bit funzionante), a causa dell’errata

modifica del codice assembler. Probabilmente, avendo avuto più tempo a

disposizione, i risultati sarebbero stati più produttivi. L’esecuzione di Nachos

a 32bit sulla macchina di prova a 64bit è comunque stata possibile mediante

l’uso dell’opzione –m32 del compilatore GNU gcc.

© 2006 Dexter - dexterp37@gmail.com 11


PAGINE

12

PESO

154.45 KB

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2013-2014

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher valeria0186 di informazioni apprese con la frequenza delle lezioni di Sistemi operativi e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Mazzeo Antonino.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Sistemi operativi

Sistemi Operativi
Dispensa
Sistemi Operativi
Dispensa
Sistemi operativi - schema suntivo per la prova pratica
Appunto
Tesine sui sistemi operativi
Appunto