Appunti completi di Sistemi operativi e reti di calcolatori (SoReCa) - teoria, esercizi

12/08/26, 16:44 appunti SoReCa

Appunti di Sistemi Operativi e Reti di Calcolatori

Corso: SoReCa — Sistemi Operativi e Reti di Calcolatori

Ingegneria Informatica e Automatica — Sapienza Università di Roma

Appunti completi e ragionati sull'intero programma del corso: architettura e funzionamento dei sistemi operativi, concorrenza e sincronizzazione,

gestione della memoria, file system, reti di calcolatori secondo l'approccio top-down, sicurezza informatica, con esercizi svolti e formulari di ripasso.

Presentazione

Questi appunti coprono l'intero programma del corso di Sistemi Operativi e Reti di Calcolatori e sono organizzati per essere usati in tre modi diversi:

1. Come manuale di studio da zero. Ogni argomento parte dal problema che risolve, prosegue con il meccanismo che lo risolve e chiude con le

conseguenze (vantaggi, svantaggi, casi d'uso). Le formule arrivano sempre dopo l'intuizione, mai prima.

2. Come strumento di ripasso. Ogni capitolo termina con una sintesi operativa; in appendice trovi un formulario completo, un glossario delle sigle e

schede di confronto rapido (tabelle "A vs B") sui punti che l'esame confronta più spesso.

3. Come raccolta di esercizi. La Parte IV contiene gli esercizi tipici svolti passo per passo: page fault su matrici, diagrammi di Gantt, page

replacement, laboratorio C con /thread/semafori/memoria condivisa, code M/M/1, numeri di sequenza TCP, risoluzione DNS.

fork

Struttura del documento

Parte Contenuto Capitoli

I Sistemi Operativi: architettura, processi, concorrenza, deadlock, IPC, scheduling, memoria, I/O, file system 1 – 18

II Reti di Calcolatori: introduzione, livello applicativo, livello di trasporto, sicurezza di rete 19 – 22

III Sicurezza informatica: rischio, modelli, container, crittografia, AAA, attacchi e difese 23 – 28

IV Metodo d'esame ed esercizi svolti 29 – 32

App. Formulario, glossario delle sigle, reference delle system call, schede di confronto A – D

Convenzioni tipografiche

I termini tecnici sono in grassetto alla prima occorrenza, con la sigla o il nome inglese fra parentesi.

Il codice, le system call e i nomi di file sono in .

carattere monospaziato

I blocchi Domanda d'esame contengono la formulazione tipica di una domanda e la risposta strutturata come andrebbe scritta al compito.

I blocchi Attenzione segnalano gli errori più frequenti e le "trappole" concettuali (tipicamente coppie di concetti che si confondono fra loro).

★

Il simbolo marca gli argomenti a più alta frequenza d'esame.

Come studiare con questi appunti

L'ordine dei capitoli è quello logico, non quello delle lezioni: ogni capitolo usa solo concetti già introdotti. Il percorso consigliato è sequenziale, con due

eccezioni utili:

se devi preparare in fretta la parte di Reti, la Parte II è autosufficiente (richiede soltanto i concetti di processo e system call del Capitolo 7 e del

Capitolo 5);

gli esercizi della Parte IV vanno affrontati subito dopo il capitolo teorico corrispondente, non alla fine: sono indicati i rimandi.

Indice

Parte I — Sistemi Operativi

1. Introduzione al sistema operativo

2. Tipologie di sistemi di elaborazione

3. Architettura del sistema: dual mode, kernel, microkernel

4. La dinamica del sistema: boot, interrupt, DMA, MMU, timer

5. System call e API POSIX

file:///tmp/crossnote-f-05b58276e1bc48f27759f40e3bd8.html 1/84

12/08/26, 16:44 appunti SoReCa

6. Obiettivi, funzioni e servizi del sistema operativo

7. Processi

8. Thread

9. Concorrenza e sincronizzazione

10. Meccanismi per la mutua esclusione

11. Problemi classici di sincronizzazione

12. Approcci software alla mutua esclusione

13. Deadlock

14. Comunicazione fra processi (IPC)

15. Scheduling

16. Memoria centrale e memoria virtuale

17. Memoria di massa e gestione dell'I/O

18. File system

Parte II — Reti di Calcolatori

19. Introduzione alle reti

20. Livello applicativo

21. Livello di trasporto

22. Sicurezza nelle reti

Parte III — Sicurezza informatica

23. Rischio e risk management

24. Obiettivi della sicurezza: CIA, Bell-LaPadula, Biba

25. Zero Trust Architecture e NIST CSF

26. Minimizzazione, container e modelli cloud

27. Protezione, crittografia applicata e controllo degli accessi

28. Attacchi tipici e meccanismi di difesa

Parte IV — Metodo d'esame ed esercizi svolti

29. Metodo per i quiz a risposta multipla

30. Esercizi svolti di Sistemi Operativi

31. Esercizi svolti di Reti

32. Domande aperte di teoria, svolte

Appendici

A. Formulario completo

B. Glossario delle sigle

C. Reference delle system call POSIX

D. Schede di confronto rapido

Parte I — Sistemi Operativi

1. Introduzione al sistema operativo

1.1 Che cos'è un sistema operativo

Il sistema operativo (SO) è il programma che si interpone fra l'hardware e le applicazioni e che resta sempre in esecuzione dal momento

dell'accensione fino allo spegnimento della macchina. La sua parte residente in memoria centrale, quella che governa l'hardware per conto di tutti gli

altri programmi, si chiama kernel (nucleo).

La differenza rispetto a qualunque altro software è proprio la persistenza: browser, editor e giochi vengono caricati, eseguiti e chiusi; il kernel è la

costante che li rende possibili. Progettare un sistema operativo richiede una conoscenza profonda dell'hardware sottostante, perché il SO deve

nascondere quell'hardware alle applicazioni senza rinunciare a sfruttarlo.

Il sistema operativo persegue due obiettivi generali, in parte in tensione fra loro:

file:///tmp/crossnote-f-05b58276e1bc48f27759f40e3bd8.html 2/84

12/08/26, 16:44 appunti SoReCa

rendere il sistema utilizzabile (user-friendly), nascondendo la complessità dell'elaborazione dietro astrazioni semplici (file, processo, finestra);

gestire le risorse nel modo più efficiente possibile, poiché CPU, memoria e periferiche sono limitate e contese.

1.2 Le categorie di software di un sistema

Oltre al kernel convivono nel sistema tre categorie di programmi:

i programmi di sistema, associati al SO ma non parte del kernel (utility, gestori, strumenti di configurazione);

i programmi applicativi, non correlati al funzionamento del sistema: un'applicazione è un programma il cui scopo è fornire all'utente una o più

funzionalità su richiesta;

il middleware, uno strato intermedio fra applicazioni e SO, indispensabile nei sistemi operativi mobili, che offre servizi comuni (grafica, database,

multimedia) alle app.

1.3 I compiti del sistema operativo

I compiti del SO si dividono in due grandi famiglie, che è utile ricordare come tabella perché costituiscono la mappa mentale dell'intero corso: la colonna

di sinistra risponde alla domanda "come si amministrano le risorse", quella di destra a "come si amministrano gli utenti e i loro programmi".

Gestione delle risorse Gestione di utenti e processi

Gestione della memoria di massa (dischi + file system) Gestione dei processi

Gestione della memoria centrale Gestione della CPU (scheduling)

Gestione dell'I/O Interfaccia utente (shell, GUI)

Gestione della cache Interpretazione dei comandi

Gestione dei file Gestione della sicurezza

Controllo dell'accesso alle risorse

Domanda d'esame — In che senso il sistema operativo è un "gestore di risorse"?

Il SO è l'unico software autorizzato ad allocare le risorse fisiche (CPU, memoria, periferiche) ai programmi. Poiché più programmi competono per le

stesse risorse, il SO deve (a) tenere traccia di chi possiede cosa, (b) decidere chi ottiene cosa e per quanto tempo, (c) revocare e riassegnare le

risorse, (d) garantire che nessun programma possa accedere a risorse non assegnategli. Da questi quattro compiti nascono, rispettivamente, le

strutture dati di controllo (PCB), lo scheduling, la prelazione e i meccanismi di protezione.

2. Tipologie di sistemi di elaborazione

Il modello elementare del calcolatore è quello sequenziale: un processore esegue un'istruzione alla volta e ogni istruzione è una sequenza di

operazioni elementari. La realtà è più articolata e si classifica secondo tre criteri: il numero e l'organizzazione dei processori, la tassonomia di Flynn, lo

scopo d'uso.

2.1 Classificazione per numero e organizzazione dei processori

Sistemi a monoprocessore. Un'unica CPU centrale esegue le istruzioni di natura generale. È affiancata da processori secondari specializzati

(controller di disco, GPU, processori di I/O) che eseguono un insieme ristretto di istruzioni e non eseguono processi utente.

Sistemi multiprocessore. Più processori in stretta comunicazione fra loro: condividono memoria, bus e clock, e comunicano tipicamente attraverso la

memoria condivisa.

Vantaggi: maggiore capacità di elaborazione, economia di scala sulle periferiche (condivise fra i processori), aumento dell'affidabilità.

Problemi che il SO deve risolvere: processi e thread concorrenti, scheduling su più processori, sincronizzazione, organizzazione della memoria,

tolleranza ai guasti.

Si distinguono in:

multiprocessore asimmetrico (AMP): ogni processore è assegnato a uno specifico compito e un processore principale gestisce e organizza gli

altri. Organizzazione gerarchica, tipica dei sistemi di grandi dimensioni;

multiprocessore simmetrico (SMP): ogni processore può eseguire tutte le operazioni, senza gerarchia. Molti processi girano

contemporaneamente e il guasto di un processore non blocca la macchina. Vantaggi: prestazioni (lavoro effettivamente parallelo), disponibilità,

crescita incrementale (si aggiungono processori), scalabilità.

file:///tmp/crossnote-f-05b58276e1bc48f27759f40e3bd8.html 3/84

12/08/26, 16:44 appunti SoReCa

Processori multicore (chip multiprocessor). Combinano due o più core in un singolo pezzo di silicio: ogni core è un processore indipendente completo,

e il chip include cache L2 e talvolta L3 condivise.

2.2 La tassonomia di Flynn

Classifica le architetture in base al numero di flussi di istruzioni e di flussi di dati.

Sigla Istruzioni Dati Significato ed esempi

SISD singolo singolo un processore, un flusso di istruzioni su un flusso di dati: il monoprocessore classico

SIMD singolo multiplo una stessa istruzione applicata simultaneamente a più flussi di dati: elaborazione vettoriale, GPU

MISD multiplo singolo più processori eseguono istruzioni diverse sullo stesso flusso di dati: applicazioni altamente specializzate, raro

più processori eseguono simultaneamente istruzioni diverse su dati differenti: multiprocessore e multicore

MIMD multiplo multiplo moderni

2.3 Sistemi distribuiti, cluster e cloud

Sistemi distribuiti. Il calcolo è distribuito fisicamente fra elaboratori distinti, possibilmente eterogenei e lascamente connessi. Ogni processore ha

memoria locale propria e la comunicazione avviene tramite linee di comunicazione. Vantaggi: condivisione delle risorse, rapidità di calcolo per

distribuzione del carico, affidabilità. Richiedono un'infrastruttura di rete (LAN/WAN).

Cluster. Più computer fortemente connessi, con capacità di elaborazione superiore agli SMP: una stessa applicazione può essere eseguita

contemporaneamente su più macchine, il che richiede programmazione parallela. Possono essere simmetrici o asimmetrici. L'affidabilità è elevata

perché ogni nodo è controllato da almeno un altro nodo, che ne recupera il lavoro in caso di guasto (business continuity).

Cloud computing. Insieme di tecnologie che consentono l'uso di risorse hardware e software distribuite e virtualizzate attraverso la rete. All'utente le

caratteristiche fisiche delle risorse non sono note (da qui la metafora della "nuvola"), e il modello economico è pay-as-you-go: si paga ciò che si

consuma.

2.4 Classificazione per scopo d'uso

Mainframe classico: orientato a lavori non interattivi, con memoria enorme e numerosi nastri. Elaborazione a lotti (batch): i processi simili

vengono raggruppati per ridurre i tempi. Nessun utente interagisce durante l'esecuzione.

Mainframe moderno: grandi server, spesso raffreddati a liquido, con molti utenti contemporanei; sono la base dei grandi server web. Prevedono

multiprogrammazione, multitasking e time-sharing.

Sistemi embedded: dedicati a supportare una sola applicazione (elettrodomestici, carte di credito, centraline). Risorse ridotte, spesso real-time e

multitasking.

Sistemi real-time: caratterizzati dalla risposta agli eventi in tempo reale, con vincoli temporali. Si distinguono in hard real-time (scadenze rigide e

inderogabili) e soft real-time (scadenze elastiche). Scambiano segnali con il mondo esterno tramite sensori e attuatori.

PDA e smartphone: sistemi portatili di dimensioni ridotte, orientati ad attività personali; interattivi, multiprocesso, a basso consumo.

3. Architettura del sistema: dual mode, kernel, microkernel

3.1 Il funzionamento in doppia modalità (dual mode)

Perché un programma scritto male, o scritto con intento ostile, non possa danneggiare il sistema, la protezione è realizzata nell'hardware e non

soltanto nel software. Il processore opera in due modalità distinte:

modalità utente (user mode): vi girano le applicazioni, con poteri limitati; non possono accedere direttamente alla memoria di altri processi né

all'hardware;

modalità kernel (kernel mode): il SO ha accesso completo a ogni risorsa.

La CPU mantiene un mode bit nel registro di stato che indica la modalità corrente (per convenzione kernel = 0, user = 1). Ne conseguono tre garanzie: i

registri sono protetti da accessi erronei o intenzionali, l'accesso completo all'hardware è possibile solo in modalità kernel, e il passaggio da utente a

kernel è controllato (avviene solo tramite interrupt, trap o system call).

Domanda d'esame — Perché serve il dual mode?

Senza una distinzione hardware fra le due modalità, un programma utente potrebbe eseguire istruzioni privilegiate: scrivere direttamente sui settori

del disco, riprogrammare il controller degli interrupt, accedere alla memoria del kernel. Il mode bit fa sì che il tentativo di eseguire un'istruzione

privilegiata in modalità utente generi una trap, che il SO gestisce terminando il processo colpevole. La protezione è quindi inaggirabile via software,

perché è la CPU stessa a rifiutare l'istruzione.

file:///tmp/crossnote-f-05b58276e1bc48f27759f40e3bd8.html 4/84

12/08/26, 16:44 appunti SoReCa

3.2 Kernel monolitico e microkernel

La domanda progettuale è: dove collocare i servizi del SO rispetto alla linea che separa modalità kernel e modalità utente?

Kernel monolitico (Linux classico, Windows). Un unico grande programma contiene tutto: gestione della memoria, scheduling, file system, driver dei

dispositivi.

Vantaggio — prestazioni: tutto risiede nello stesso spazio di indirizzamento (kernel space); se il gestore dei processi deve interrogare il file system

lo fa con una normale chiamata a funzione. È molto veloce.

Svantaggio — fragilità: un bug in un driver, che gira dentro il kernel, può corrompere la memoria di un altro sottosistema e mandare in crash l'intero

sistema (kernel panic, blue screen).

Microkernel (QNX, Minix). Filosofia opposta: in modalità kernel resta solo l'indispensabile, cioè gestione dei processi (scheduling), gestione di base

della memoria e comunicazione fra processi. Tutto il resto (file system, driver, gestione della rete) viene spostato in modalità utente, come normali

processi.

La struttura a strati del microkernel, dal basso verso l'alto, è:

HARDWARE → Primitive Process Management → Virtual Memory → I/O and Device Management → Interprocess Communication → File System → Us

. Il microkernel gestisce la memoria di basso livello (mappa ogni pagina virtuale sulla corrispondente pagina fisica) e la comunicazione avviene per

messaggi: ogni messaggio ha un'intestazione, che identifica mittente e destinatario, e un corpo con dati o informazioni di controllo.

Svantaggio — overhead: per leggere un file, un programma non chiama direttamente il kernel ma invia un messaggio al processo "file system", che

gira in user mode. Ogni operazione comporta scambi di messaggi e continui passaggi utente↔kernel, quindi latenza.

Vantaggi: interfaccia uniforme sulle richieste, estensibilità, flessibilità, portabilità, affidabilità, supporto naturale ai sistemi distribuiti, orientamento

agli oggetti.

Domanda d'esame — Perché il microkernel è preferibile nei sistemi embedded e real-time?

Per due ragioni. Affidabilità: se il driver di un sensore va in crash, va in crash solo quel processo utente; il kernel continua a funzionare e può

riavviare il driver, mentre in un kernel monolitico l'intero sistema si fermerebbe. Determinismo: meno codice nel kernel significa meno percorsi di

esecuzione imprevedibili, quindi è più facile calcolare il tempo massimo di un'operazione critica — requisito essenziale nel real-time, dove ciò che

conta non è la velocità media ma il caso peggiore garantito.

3.3 La macchina virtuale

All'estremo opposto dell'astrazione si colloca la macchina virtuale: un software chiamato hypervisor presenta a un sistema operativo ospite un

hardware apparentemente dedicato, mentre in realtà quel sistema operativo gira come un normale programma sopra un altro sistema. Consente di

eseguire più SO sulla stessa macchina fisica, di isolarli fra loro e di migrare interi ambienti fra macchine diverse. È la tecnologia alla base

dell'infrastruttura cloud (IaaS) e va confrontata con i container, che virtualizzano il sistema operativo invece dell'hardware (Capitolo 26).

4. La dinamica del sistema: boot, interrupt, DMA, MMU, timer

Questo capitolo risponde a una sola domanda: come fa il sistema a partire e a restare reattivo? I meccanismi coinvolti sono il boot, gli interrupt e le

trap, il DMA, la MMU e il timer hardware.

4.1 Il boot

All'accensione la CP