Auditing di codice sorgente open-source ai fini della sicurezza

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Auditing di codice sorgente open-source ai fini della sicurezza"

Transcript

1 UNIVERSITÀ DEGLI STUDI DI MILANO-BICOCCA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Informatica Auditing di codice sorgente open-source ai fini della sicurezza Prof. Flavio De Paoli Dott. Claudio Ferretti Relazione della prova finale di: Marco Moioli Matricola: Anno Accademico 2001/2002

2 Indice Indice... I Introduzione Introduzione al problema della sicurezza L'importanza del processo di auditing del codice La difficoltà del processo di auditing Tipi di vulnerabilità rilevabili dal processo di auditing del codice I vantaggi dell'open Source nei riguardi della sicurezza Risorse utilizzate I Buffer Overflow Introduzione al problema Definizione di buffer...12 o Organizzazione della memoria di un processo...12 o Lo stack o La regione dello stack o Esempi di buffer overflow o Sfruttare i buffer overflow o Un caso di codice vulnerabile o Come attaccare un programma o L'exploit o Ottimizzare lo shellcode

3 3 Come difendersi dai Buffer Overflow Evitare i buffer overflow programmazione ottimale Evitare i buffer overflow funzioni sicure Evitare i buffer overflow allocazione dinamica del buffer Evitare i buffer overflow librerie sicure Evitare i buffer overflow ulteriori soluzioni Evitare i buffer overflow considerazioni finali Rsync Cos'è Rsync Perché è stato scelto Rsync per il processo di auditing del codice Strumenti di analisi L algoritmo di Rsync Storia dei bugs di Rsync Discussione della patch Boon Cos è Boon Perchè usare Boon Perchè è stato scelto Boon Risultati dell applicazione di Boon a bof1.c e bof4.c Risultati dell'applicazione di Boon a format.c e format2.c Risultati dell applicazione di Boon a Rsync Esempio di output di Boon Conclusioni su Boon Strumenti alternativi a Boon Conclusioni e Prospettive Conclusioni Prospettive Bibliografia

4 Introduzione Il presente lavoro di tesi ha avuto lo scopo di analizzare il problema della sicurezza dei sistemi informatici. A tal fine è stato fatto un ampio lavoro di conoscenza dei principali metodi per la protezione dei sistemi informatici e delle informazioni in essi contenute. Si è anche svolto un lavoro di conoscenza sulle principali tecniche usate per violare i sistemi informatici e le relative contromisure possibili. Si è inoltre svolto un lavoro di auditing del codice al fine di studiare degli errori noti presenti nel codice di un programma (Rsync) e si è svolta la ricerca di nuovi possibili errori che inficiassero la sicurezza del programma. A tal fine è stato usato uno strumento di navigazione del codice prodotto dal team di sviluppo Doxygen. Infine, è stato studiato ed installato uno strumento sperimentale di rilevazione di possibili errori nel codice sorgente di un programma (strumento Boon prodotto dai laboratori Bell in collaborazione con l università di Berkley) e lo si è provato sul programma Rsync per vederne i risultati. 4

5 5

6 1.1 Introduzione al problema della sicurezza In principio, i sistemi informatici sono stati creati e sviluppati principalmente allo scopo di eseguire calcoli matematici ad una velocità e con un efficienza che la mente umana non è in grado di raggiungere. Ben presto, però, i calcolatori hanno assunto anche la funzione sia di immagazzinatori di dati che di strumenti tramite i quali scambiarsi informazioni. Immensi e dispersivi archivi cartacei sono stati digitalizzati e adesso risiedono in piccoli ed efficienti database elettronici cui è possibile avere l accesso da terminali situati in qualsiasi parte della Terra. Alcune delle informazioni contenute nelle banche dati (c/c bancari, documenti aziendali riservati, segreti militari ecc.) non possono essere disponibili per chiunque. Questo ha portato alla necessità di restringere il campo di coloro che possono accedere a questi dati, soprattutto oggi che i sistemi informatici sono sempre più connessi tra loro tramite reti che permettono la violazione da remoto. Sono varie le tipologie di coloro che attentano alla sicurezza dei sistemi, perché varie sono le motivazioni che li spingono: noia, curiosità, desiderio di rivalsa, ricerca di fama, spionaggio. Al dilà delle varie motivazioni che possono spingere una persona a cercare di accedere a risorse non sue, l aspetto da sottolineare è che i computer e i loro software sono molto vulnerabili a diversi tipi di attacchi volti a violarne la sicurezza. Questo problema è dato dal fatto che solo ora il mondo dell informatica sta prendendo veramente coscienza del problema e solo ora si stanno cominciando ad attuare le opportune contromisure. Molto del software oggi in circolazione è stato scritto con un linguaggio, il C, che ha al suo interno delle funzioni molto usate che possono provocare buffer overflow e permettere ad un attaccante di sfruttare queste vulnerabilità per impadronirsi della macchina. Le soluzioni a questo problema sono date da nuove chiamate di funzione sicure che svolgono lo stesso lavoro delle vecchie non sicure. Oppure la soluzione è data dal programmare con i nuovi linguaggi di programmazione che attuano controlli volti a prevenire la possibilità di buffer overflow (phyton, java, ecc..). 6

7 1.2 L importanza del processo di auditing del codice: Fare l auditing del codice significa esplorare, revisionare, capire del codice già esistente. Perché i programmatori dovrebbero voler esaminare il codice sorgente di un programma? La maggior parte delle volte il motivo è che essi ne traggono un proprio vantaggio: - Hanno trovato un software Open Source utile ai loro propositi e vogliono migliorarlo o modificarlo per adattarlo alle loro specifiche necessità. - A volte invece, il codice sorgente viene controllato solo per assicurarsi che sia in grado di soddisfare alcuni bisogni, anche se non c è nessuna intenzione di modificarlo. Ad esempio le aziende che richiedono elevati livelli di sicurezza, potrebbero svolgere l Audit del codice come parte delle procedure di revisione della sicurezza. Di solito si entra nel merito del codice sorgente quando occorre cambiarvi qualcosa. Sfortunatamente, ciò non significa che se ne ottiene una revisione in chiave sicurezza dagli esperti del settore: la gran parte dei programmatori affrontano i sorgenti per inserirvi nuove funzioni, senza per questo avere competenze specifiche sulla sicurezza. Molti tecnici, ad esempio, conoscono i rischi connessi agli Overflow dei Buffer e le funzioni che vanno evitate. Ma molti di essi non sono abbastanza esperti in materia da evitare i problemi al di là di quelli che sono stati loro segnalati. E quando si passa in aree più rischiose di quelle indotte dai Buffer Overflow, i problemi peggiorano. Ad esempio, mentre l impiego della crittografia è molto comune, può succedere che i programmatori la utilizzino in modo non corretto minando così la sicurezza dell intero sistema. Un altro fenomeno ricorrente è l impiego di metodi di crittografia troppo deboli e facilmente superabili, mentre spesso lo scambio di chiavi tra programmi avviene utilizzando modalità assolutamente poco sicure. 7

8 1.3 La difficoltà del processo di auditing: Controllare la sicurezza del codice sorgente è veramente complesso: perfino i più esperti possono sbagliare. Un buon esempio di ciò è offerto dal famoso Server FTP Open Source wu-ftpd. Negli ultimi due anni,nel suo codice sono stati individuati numerosi problemi di Buffer Overflow, alcuni dei quali quasi impercettibili. La maggior parte di questi problemi erano presenti da anni, malgrado il codice fosse stato analizzato diverse volte sia dagli Hacker che dai revisori della sicurezza. Wu-ftpd è stato usato come piattaforma per lo studio delle tecniche di individuazione delle vulnerabilità. Nessuna di queste tecniche ha segnalato la presenza dei problemi scoperti in seguito. E soprattutto nei sorgenti complessi che è molto difficile identificare dei Bug. Il codice di wu-ftpd è composto da meno di linee, però perfino in un software così piccolo si sono trovati numerosi Bug rimasti a lungo nascosti. 1.4 Tipi di vulnerabilità rilevabili dal processo di auditing del codice: Buffer Overflow: La classe di vulnerabilità che può essere rilevata più facilmente durante il processo di auditing del codice è quella dei buffer overflow. Tale bug ha l obiettivo di provocare il riempimento e la tracimazione di un buffer allocato in maniera finita. Questo può portare a sovra scrivere l indirizzo di ritorno (IP) e a far puntare lo stack ad un area di memoria decisa in modo arbitrario dall attaccante contenente del codice in linguaggio assembly atto a richiedere al computer dei comandi che l attaccante non avrebbe i privilegi per richiedere (tipo una shell remota con privilegi di root). Race Condition: Si definiscono race condition tutte quelle situazioni in cui processi diversi operano su una risorsa comune, ed in cui il risultato viene a dipendere dall'ordine in cui essi effettuano le loro operazioni. Il caso tipico è quello di un'operazione che viene eseguita da un processo in più passi, e può essere compromessa dall'intervento di un altro processo che accede alla stessa risorsa quando ancora non tutti i passi sono stati completati. Dato che in un sistema multitasking ogni processo può essere interrotto in qualunque momento per farne subentrare un'altro in esecuzione, niente può assicurare un preciso 8

9 ordine di esecuzione fra processi diversi o che una sezione di un programma possa essere eseguita senza interruzioni da parte di altri. Queste situazioni comportano pertanto errori estremamente subdoli e difficili da tracciare, in quanto nella maggior parte dei casi tutto funzionerà regolarmente, e solo occasionalmente si avranno degli errori. Per questo occorre essere ben consapevoli di queste problematiche, e del fatto che l'unico modo per evitarle è quello di riconoscerle come tali e prendere gli adeguati provvedimenti per far sì che non si verifichino. Casi tipici di race condition si hanno quando diversi processi accedono allo stesso file, o nell'accesso a meccanismi di intercomunicazione come la memoria condivisa. In questi casi, se non si dispone della possibilità di eseguire atomicamente le operazioni necessarie, occorre che quelle parti di codice in cui si compiono le operazioni sulle risorse condivise (le cosiddette sezioni critiche) del programma, siano opportunamente protette da meccanismi di sincronizzazione. Format String: Durante la seconda metà dell anno 2000, è stata scoperta una nuova classe di vulnerabilità conosciuta come format string vulnerabilities. Questo ha portato all individuazione, in tutti i tipi di programmi, di una miriade di nuovi bug exploitabili. Questo tipo di vulnerabilità interessa tutte le classi di programmi, dalla piccola utilità di sistema alla grande applicazione per i server. La generica classe di format string vulnerability può essere vista come un problema di canale. Questo tipo di vulnerabilità può sussistere se due differenti tipi di chanali di informazione sono combinati tra di loro in un unico canale, e speciali caratteri di escape o sequenze di caratteri sono usate per distinguere quale canale è attivo ad un certo momento. In molti casi un canale è un data channel, il quale è solamente copiato senza essere controllato, questo viene fatto poichè l altro canale è un canale di controllo. Se un attaccante è capace di fornire nel data channel un input capace di essere interpretato dalla macchina al dilà dei controlli dell altro canale, allora questo può risultare pericoloso per la sicurezza del sistema. Per esempio: ho un array chiamato prova[20] di venti byte. Applico una sprintf (prova, s) dove s è una stringa fornita dall utente. 9

10 Se un utente inserisce come stringa %30d questo comando riserverà in memoria spazio per 30 byte provocando un overflow del buffer prova di 10 byte! Se l attaccante è così bravo da trovare il punto dello stack dove viene mantenuto l Istruction Pointer, potrà sovrascriverlo e farlo puntare ad una locazione di memoria (di solito la cima dello stack) dove egli avrà posto del codice arbitrario capace di chiedere servizi che l attaccante non avrebbe il permesso di chiedere. 1.5 I vantaggi dell Open Source nei riguardi della sicurezza: Contrariamente a quanto alcuni possano pensare, i progetti sviluppati con Software Open Source possono risultare molto più sicuri di quelli sviluppati con un sistema Closet Source. I critici del Software Open Source potrebbero dire che fornire il codice sorgente rende più facile il lavoro di coloro che vogliono attaccare i sistemi. Rendendo disponibile solo il codice in formato binario, si eleva il grado di difficoltà così da indurre i meno determinati a guardare altrove. Ma come ci stanno dimostrando i numerosi buchi rilevati nel Software pacchettizzato, coloro i quali vogliono attaccare il sistema possono farlo anche senza codice sorgente; ci vuole solo più tempo. Dal punto di vista della sicurezza, i vantaggi di mettere i sorgenti a disposizione di tutti sono maggiori dei benefici che ne possono ricavare i Cracker. Tra i vantaggi dell Open Source c è anche il fatto che, poiché il codice viene pubblicato, i programmatori pongono maggiore attenzione in ciò che fanno, così da evitare di trovarsi in imbarazzo per aver rilasciato codice di scarsa qualità. In secondo lugo, la disponibilità del codice, permette che la sua analisi e la revisione degli errori vengano svolte da varie persone e gruppi di lavoro. Da parte dell intera comunità degli sviluppatori c è molta attenzione a far sì che del nuovo codice non comprometta la sicurezza di un intera distribuzione di Linux. 1.6 Risorse utilizzate: Il lavoro di conoscenza delle problematiche riguardanti la sicurezza è stato svolto con l ausilio di materiale preso da testi e da siti internet. 10

11 I testi letti hanno nomi altisonanti quali: Hacker l attacco o Hacker proofing. Questi libri hanno dato una panoramica sul problema della sicurezza in generale trattando sia delle problematiche riguardante le vulnerabilità del codice, sia quelle riguardanti i metodi di scansione delle porte di comunicazione o la creazione di virus. Per la parte relativa all auditing del codice, si è provveduto a reperire risorse dalla rete internet. Sono stati trovati tutorial sui buffer overflow, manuali sulle principali chiamate non sicure in C e molto altro ancora. I principali siti visitati sono stati: Security focus: questo sito racchiude notizie sulla scoperta di nuove vulnerabilità e notizie sul mondo della sicurezza in generale. Inoltre possiede un enorme database di tutorial e saggi su ogni aspetto della sicurezza. Possiede svariate mailing lists relative al problema sicurezza. Infine ha al suo interno il famoso database di vulnerabilità bugtraq che ha al suo interno gli avvisi di ogni vulnerabilità (resa nota al mondo) presente in un certo software. Ad ogni avviso di vulnerabilità è associato un identificativo e tutte le informazioni necessarie quali una discussione del problema e le possibili soluzioni. Cert: Il centro di coordinamento Cert è un istituto di esperti di sicurezza di internet situato nell istituto di software engineering, una fondazione di ricerca e sviluppo patrocinata dall università Carnegie Mellon di Pittsburgh. Il sito è simile a quello di Security focus e sono stati trovati molti documenti intressanti. Shields Up!: Sito creato dal famoso esperto di sicurezza Steve Gibson. In questo sito si possono trovare molte informazioni sulle vulnerabilità dei sistemi operativi. E inoltre possibile fare una prova del proprio grado in penetrabilità, usando un servizio che ricerca possibili accessi al pc sfruttabili dagli hackers. Phrack: Questo sito contiene tutti i numeri della rivista Phrack fondata nel lontano Nella rivista in questione vengono trattati tutti gli argomenti relativi alla sicurezza. 2600hertz.net: Sito molto completo che tratta gli aspetti della sicurezza informatica in quasi tutti i suoi aspetti. 11

12 Siti Underground: Sono stati visitati una moltitudine di siti che oltre a parlare delle tecniche di hackeraggio, ne fornivano anche i tool. Alcuni di questi siti sono stati chiusi nel lasso di tempo tra l inizio dello stage e la sua conclusione. Mailing list: A parte le mailing list di bugtraq, ho trovato molto utile la mailing list in italiano di sikurezza.org. 12

13 I Buffer Overflow 2.1 Introduzione al problema: Uno degli aspetti più rilevanti del problema sicurezza riguarda i buffer overflow, tecnica che può essere sfruttata da un attacker per modificare parte dello stato interno di un programma quando il programmatore non abbia posto particolare attenzione all aspetto della sicurezza. Riuscire a modificare la normale esecuzione di un processo significa anche avere la possibilità di eseguire codice arbitrario e, al limite, impadronirsi della macchina da remoto. Per comprendere ed applicare questa tecnica è necessario aver ben chiari i concetti di gestione della memoria e di linguaggio assemby. Gli esempi di seguito riportati sono stati implementati su un architettura Intel Definizione di buffer: Un buffer è un blocco contiguo di memoria che contiene più istanze dello stesso tipo di dato. In C un buffer viene normalmente associato ad un array. L overflow di un buffer consiste nel riempire oltre il limite tale buffer. 2.3 Organizzazione della memoria di un processo: Per capire come funzionano i buffer sullo stack occorre sapere come è organizzato un processo in memoria. I processi sono divisi in tre regioni: testo, dati e stack. La regione testo è fissata e contiene il codice del programma ed è a sola lettura. Qualsiasi tentativo di scrittura in questa regione provoca una violazione di segmento. La regione dati contiene i dati inizializzati e non. Le variabili statiche vengono memorizzate in questa regione. 13

14 Figura Lo stack: Lo stack è un area di memoria contigua in modalità Last in First Out (Lifo). Le due operazioni principali sono push (aggiunge un elemento in cima allo stack) e pop (rimuove un elemento dalla cima dello stack). 2.5 La regione dello stack: Uno stack è un blocco contiguo di memoria contenente dati. Un registro chiamato stack pointer (SP) punta sempre alla cima dello stack. La base dello stack è a un indirizzo fissato. La sua dimensione è adattata dinamicamente dal kernel al momento dell avvio. La CPU implementa le funzioni push e pop. Lo stack consiste di un insieme di segmenti logici (stack frame) che vengono inseriti nello stack quando viene chiamata una funzione ed eliminati quando la funzione ritorna. Uno stack frame contiene i parametri della funzione, le sue variabili locali, i dati necessari per ripristinare il precedente stack frame, incluso l indirizzo dell istruzione successiva alla chiamata (contenuto nell instruction pointer o IP). A seconda dell implementazione, lo stack cresce verso l alto o verso il basso. Nella tecnologia Intel si assume che cresca verso indirizzi bassi. In aggiunta allo stack pointer, che punta alla cima dello stack (indirizzi numericamente più bassi), è spesso conveniente avere un frame pointer (FP), chiamato anche base pointer (BP) che punta ad una fissata locazione in un frame. Principalmente, le variabili locali possono essere riferite specificando il loro offset dall SP, ma non appena viene inserita o 14

15 rimossa una word dallo stack, questi offset cambiano mentre riferendoci al FP tali offset restano fissi per l intera vita della funzione. La prima cosa che una procedura deve fare quando è chiamata è salvare l FP precedente in modo da poter essere ripristinato all uscita dalla procedura stessa. Poi copia l SP nell FP per creare il nuovo FP, e sposta l SP verso indirizzi di memoria più bassi per riservare spazio per le variabili locali. 2.6 Esempi di buffer overflow: Supponiamo venga scritta una funzione come la seguente e consideriamo un architettura semplificata con word di 1 byte: f ( ciao ); void f (char *s) { char buffer [4]; strcpy (buffer, s); } Questo codice non fa altro che copiare la stringa di caratteri ciao nel buffer di 4 caratteri buffer allocato sullo stack. 15

16 Figura 2. All uscita dalla funzione chiamata, vengono recuperati il Frame Pointer (FP) e l Istruction Pointer (IP) dallo stack e ripristinati nei rispettivi registri in modo da far proseguire l esecuzione del programma principale con l istruzione successiva alla chiamata di f. Se si volesse provocare un buffer overflow, basterebbe scrivere: f ( aabcdeeeefff ); void f (char *s) { char buffer [4]; strcpy (buffer, s); } 16

17 Siccome la funzione strcpy non prevede alcun controllo sulla dimensione del parametro passato, la stringa aabcdeeeefff è stata accettata nonostante la sua lunghezza (12 caratteri) fosse maggiore della capacità del buffer (4 caratteri). Questo provoca l overflow e l conseguente sovrascrittura del FP, IP e del puntatore a *s. All uscita dalla funzione quindi, l IP non conterrà più il corretto valore di ritorno ma bensì il valore 0x65 (che è il corrispettivo ASCII della lettere e ). Il flusso di esecuzione del programma verrà quindi deviato verso questo nuovo indirizzo. Una volta che la funzione chiamata termina, il processore tenterà di eseguire l istruzione contenuta all indirizzo indicato dall IP, incorrendo pertanto in uno di questi casi: - Il numero esadecimale finito nell IP rappresenta un indirizzo che va fuori dall intero spazio di memoria dedicato al processo; in tal caso si genera un segmentation fault. - Il numero esadecimale finito nell IP rappresenta un indirizzo valido per il processo in esecuzione; in tal caso si ha un malfunzionamento del programma. 2.7 Sfruttare i buffer overflow: Quello che è possibile fare è quindi la possibilità di riferirsi ad un indirizzo di memoria scelto che permetta di eseguire codice arbitrario voluto dall attacker. In tal modo si riesce ad avere l accesso ed il controllo di una macchina senza essere in possesso di nessuna shell o account sulla stessa, ovvero si ottiene quello che viene chiamato un exploit da remoto. Poiché la sezione testo è a sola lettura, l unico posto dove porre il proprio codice da far eseguire è proprio il buffer stesso, fermo restando che il buffer abbia dimensione sufficiente a contenere il codice. Il vero problema sta nel riuscire ad indirizzare l IP all inizio del buffer perché è proprio a partire da quel punto che l attacker vorrà posizionare il suo programma; bisognerà quindi pensare a realizzare la stringa da copiare nel buffer in modo che contenga nella parte iniziale il codice del programma da exploitare ed in seguito l indirizzo di allocazione del buffer che dovrà andare a sovrascrivere l IP. 2.8 Un caso di codice vulnerabile: 17

18 Consideriamo il seguente programma: Figura 3. Il codice in questione presenta tutte le caratteristiche necessarie per tentare di realizzare un attacco, ovvero contiene una funzione che accetta come parametro una stringa fornita dell utente e la copia nel buffer b, senza controllare che la dimensione di b (80 byte) sia sufficiente a contenerla interamente. Ovviamente, eseguendo il programma passando come parametro una stringa di lunghezza non maggiore di 80 caratteri, si ottiene il risultato previsto di copiare una stringa nell altra e di visualizzare l indirizzo del buffer, ma i limiti di questo programma emergono subito se la stringa passata ha dimensioni maggiori. 18

19 Figura 4. La stringa di 100 caratteri A passata come parametro, fa in modo che il programma riceva un segnale di tipo SIGSGV (Signal Segmentation Violation) e quindi blocchi la sua esecuzione a causa di una violazione di segmento. Questo accade quando un processo tenta di accedere ad un indirizzo di memoria non valido. Questo accade perchè il testo in eccesso viene ugualmente riversato nello stack, anche oltre la fine del buffer, con il risultato che sia il FP che l IP vengono soprascritti entrambi con dei caratteri A (0x41). Nell IP troveremo quindi 0x che non è un indirizzo valido, quindi viene generato il SIGSEGV. 2.9 Come attaccare il programma: Trovato il punto in cui viene memorizzato l IP, bisogna sapere cosa scriverci per fare in modo di dirottare l esecuzione del programma e poter eseguire il codice di attacco. Si deve di conseguenza decidere dove posizionare tale codice. La soluzione più semplice ed immediata è quella di memorizzarlo proprio nel nostro buffer, vista l impossibilità di utilizzare l area di testo a causa della limitazione a sola lettura a cui è sottoposta. 19

20 Supponiamo di voler visualizzare il contenuto della directory corrente (comando /bin/ls ). Per poterlo fare basta mandare in esecuzione il seguente codice: Figura 5. Per eseguirlo è necessario scrivere nell IP l indirizzo che punta all inizio del buffer. Tuttavia non possiamo sapere a priori dove verrà allocato in memoria il nostro buffer al momento dell esecuzione del programma; quindi dobbiamo escogitare un modo per farcelo dire a run-time: per questo motivo ci torna utile visualizzarlo con la printf in bof.c L exploit: Lo strumento che consente di sfruttare la vulnerabilità di bof1.c realizzando l exploit è quindi un programma (exp1.c) tale da permettere di costruire una stringa opportuna da passargli che contenga il giusto indirizzo IP. La stringa, sovradimensionata a 100 byte, viene composta copiando lo shellcode all inizio e un indirizzo fornito dall attacker come parametro all offset calcolato. Nel nostro caso, la funzione f decrementa lo stack di 88 bytes (vedi immagine) perchè 80 sono necessari al buffer, mentre gli altri 8 derivano da un problema di allineamento: visto che lo stack, di default, viene allineato dal compilatore a 4 word, quando vengono inseriti i valori dei registri FP e IP, che occupano 1 word ciascuno, il compilatore aggiunge automaticamente 2 ulteriori word di allineamento per arrivare a 4. 20

21 Figura 6. Figura 7. Per stabilire il parametro da passare basterà eseguire una prima volta exp1 con un indirizzo volutamente non valido in modo da provocare il segmentation fault; bof1 svelerà 21

22 comunque l indirizzo del buffer grazie alla printf. Rieseguendo pertanto exp1 con il parametro ottenuto realizzeremo l exploit. Figura 8. Come si vede dall immagine, si è riuscito ad eseguire la /bin/ls grazie ad un buffer owerflow; tuttavia l attacker non si limiterà a curiosare, ma con la stessa tecnica potrebbe ad esempio eseguire /bin/sh ottenendo quindi una shell ed impadronendosi della macchina. 22

23 Figura Ottimizzare la shellcode: Nel codice fin qui presentato è stato, volutamente, tralasciato un particolare non irrilevante ai fini pratici: quando abbiamo parlato di come trovare l indirizzo della stringa abbiamo fatto l ipotesi di riuscire a deviare l IP all inizio del buffer in modo da arrivare alla JMP che innescherà tutto il resto della shellcode, ma abbiamo anche detto che non sappiamo dove verrà allocato il nostro buffer. Si pone quindi il problema di riuscire a sovrascrivere l IP con l indirizzo della JMP. Ovviamente si potrebbe procedere per tentativi, ma individuare con esattezza un indirizzo preciso costituisce un procedimento non efficiente e probabilmente non efficace. Quello che si fa di solito, è riempire di NOP la parte iniziale del buffer. La NOP è un istruzione che non fa letteralmente niente (NO Operation) se non di sprecare un ciclo di fetch e di passare all istruzione successiva. Supponiamo che dopo una prima NOP ce ne sia un altra; che succede? Ancora una volta nulla, ovvero si passa nuovamente all istruzione successiva e così via. La NOP ha anche il vantaggio di occupare un solo byte. Risulta allora evidente che se abbiamo 100 NOP iniziali, il nostro algoritmo che prevedeva di azzeccare l indirizzo nella 23

24 JMP per attivare la shellcode, vede incrementare la probabilità di riuscirci di un fattore 100, dal momento che basta imbattersi in una qualsiasi NOP per far proseguire l esecuzione via via con tutte le restanti ed arrivare fino alla JMP. Figura 10. Esistono tuttavia dei casi in cui questa soluzione non è praticabile: se il buffer è troppo piccolo per contenere l intero codice di attacco, è necessario indirizzarsi verso un atra zona di memoria come, ad esempio, l heap o l area dati. Metodi di attacco alternativi, comprendono i casi in cui l attacker non miri ad eseguire un codice personale ma a lanciare porzioni di programmi o librerie già presenti in memoria in modo da farli risultare dannosi. 24

25 Come difendersi dai Buffer Overflow 3.1 Evitare i buffer overflow - programmazione ottimale: La soluzione più immediata e sicura consiste nell inserire controlli sulle dimensioni dei parametri inseriti dall utente, in modo da assicurarsi che non si verifichino overflow; i bof infatti sono possibili in quanto non viene effettuato un controllo sulla quantità di bytes inseriti nei buffer stessi; se la quantità di dati eccede la dimensione del buffer e non esiste alcun controllo che lo rilevi, si rende possibile un overflow; quindi una soddisfacente soluzione sarà sicuramente quella di implementare, nel codice stesso del programma, le istruzioni di controllo necessarie. Prendiamo ad esempio il vulnerabile bof1.c considerato in precedenza e cerchiamo di modificarlo ponendo un controllo sulla stringa passata in input: Figura 1. A tal fine modificheremo il main in modo da rifiutare una stringa di dimensioni maggiori del buffer b dove verrà copiata, cioè 80 caratteri; questo si ottiene nel seguente modo:... 25

26 int main (int argc, char **argv) { if (!argv[1]) exit(1); if ((strlen(argv[1])>80)) { printf ( Parametro troppo grande. \n ); printf ( Inserire un parametro inferiore a 80 caratteri. \n ); exit(1); }... Il programma modificato sarà il seguente: Figura 2. 26

27 Se si prova a compilarlo ed eseguirlo con un parametro di dimensioni eccessive, si noterà come previsto che il programma uscirà senza far niente se non visualizzare il relativo messaggio di errore; Figura 3. Bof2.c è quindi ora sicuro! Questo tipo di soluzione è senz altro ciò che ogni attento programmatore dovrebbe fare tutte le volte che si presenta un caso simile con rischio di buffer overflow. 3.2 Evitare i buffer overflow funzioni sicure : Non è comunque sempre necessario inserire dei controlli a basso livello di questo tipo. Esistono infatti delle funzioni che possono sostituire altre che non si preoccupano di verificare le dimensioni dei dati su cui lavorano. Nel codice di esempio bof1.c il problema è dato dal fatto che la funzione strcpy (b,s) non controlla che le dimensioni del buffer b allocato sullo stack siano sufficienti a contenere l intera stringa s ed esegue ugualmente la copia della stringa continuando a scrivere sullo stack fuori dallo spazio allocato. 27

28 Esiste una funzione chiamata strncpy() che oltre ad implementare le funzionalità di strcpy, impone un limite massimo alle dimensioni della stringa. Se la stringa eccede il limite massimo (passato come terzo parametro alla funzione), la stringa verrà troncata e poi copiata nel buffer. Figura 4. Se si prova adesso ad eseguire il codice con un numero di caratteri maggiori del buffer si otterà: 28

29 Figura 5. Possiamo vedere che questa volta non si è verificato un segmentation fault perchè è stata copiata la stringa troncata all ottantesimo carattere, quindi non è stato scritto nulla al di fuori del buffer. Ci sono però dei problemi legati all'utilizzo di funzioni come strncpy() : 1. API non intuitiva, che induce non pochi errori in fase di sviluppo: l'utilizzo di queste funzioni infatti richiede che il programmatore sia particolarmente attento al corretto passaggio di tutti i parametri che possono variare in quantità e posizione rispetto alla funzione primitiva; 2. Uso incoerente del parametro che indica lunghezza/dimensione (per strncpy() si tratta di sizeof(dest) per strncat() di sizeof(dest)-1); 3. Difficolta' nell'accorgersi di un troncamento avvenuto (per strncpy() si deve controllare con strlen(dest), per strncat() bisogna tenere copia del vecchio valore di dest); 4. Strncpy() non termina in ogni caso con NULL la stringa di destinazione (questo avviene se la stringa di origine eccede in lunghezza quella di destinazione; in questo modo saranno copiati solo i bytes specificati dal parametro sulla dimensione senza terminare con NULL), quindi il programmatore si deve preoccupare di 29

30 impostare a NULL l'ultimo byte manualmente nel caso in cui strlen(sorgente) >=sizeof(destinazione); 5. Strncpy() ha performance pessime (dipendentemente dalla CPU, strncpy() e` dalle 3 alle 5 volte piu' lento di strcpy(); questo perche' lo spazio in eccesso viene posto esplicitamente a '\0'). Un' alternativa efficace a queste funzioni è rappresentata da strlcpy() e strlcat() che offrono un' interfaccia più intuitiva: size_t strlcpy (char *dst, const char *src, size_t size); size_t strlcat (char *dst, const char *src, size_t size); Entrambe occupano per intero il buffer di destinazione (non solo per la lunghezza della stringa da copiare come in strncpy()), garantiscono la terminazione della stringa con NULL e restituiscono la lunghezza totale della stringa che è loro intenzione creare, ovvero la dimensione della stringa di destinazione se questa non viene troncata a causa di un buffer non abbastanza grande da contenerla. In questo modo è facile verificare un eventuale troncamento controllando semplicemente il valore restituito (se (valore restituito >= dimensione buffer) troncamento). Inoltre sono performanti poiché nessuna di loro imposta il buffer di destinazione eccedente con NULL all'infuori di quello necessario a terminare la stringa stessa. Un eventuale problema può essere dato dal fatto che strlcpy() e strlcat() non vengono però installate di default in molti sistemi Unix-like, cosa peraltro risolvibile includendole nello stesso programma sorgente data la loro dimensione ridotta. Peccato che tali soluzioni di modifica al codice non siano sempre di facile applicazione: basta infatti pensare che gli attuali programmi sono costituiti da una grossa mole di codice che causa un oneroso lavoro di analisi; d altronde anche il numero di applicazioni correntemente usate è in continua crescita e pertanto il numero di programmi che andrebbero rianalizzati in profondità a partire da zero è sempre maggiore. E' allora comprensibile perché è necessario ricercare altri tipi di soluzione. 3.3 Evitare i buffer overflow allocazione dinamica del buffer: 30

31 Strncpy() e simili sono un esempio di buffer allocato staticamente, ovvero una volta allocato la sua dimensione resta fissa. l'alternativa può essere quella di riallocarlo dinamicamente in modo da ridimensionarlo a seconda delle esigenze. Supponiamo ad esempio di inserire volutamente la solita stringa eccedente: se il buffer è allocato dinamicamente si ottiene il risultato di espanderne le dimensioni in maniera tale da poter memorizzare l'intera stringa, a meno che non si raggiunga la condizione estrema di esaurimento di memoria, evitando così la situazione di overflow. Purtroppo l'allocazione dinamica può provocare un esaurimento di memoria anche in punti nel programma non soggetti a bof, quindi qualsiasi allocazione di memoria può fallire. Anche nel caso in cui non si arrivi subito ad esaurire la memoria questo tipo di allocazione necessita di un numero maggiore di accessi alla memoria virtuale rispetto all'allocazione statica proprio per la minore efficienza nell'allocazione stessa, per cui risulta relativamente facile imbattersi nel cosiddetto fenomeno di "trashing" ovvero una situazione in cui la macchina spreca la maggior parte del tempo a scambiare informazioni tra disco e memoria. 3.4 Evitare i buffer overflow librerie sicure : Le soluzioni di libreria consistono essenzialmente nell'utilizzo di funzioni che facciano un corretto bound-checking ed una riallocazione dinamica di stringhe in analogia con quanto avviene con molti altri linguaggi come Perl o Ada95 che è capace di localizzare e prevenire bof. Arash Baratloo, Timothy Tsai, e Navjot Singh (della Lucent Technologies) hanno sviluppato Libsafe, una semplice libreria caricata dinamicamente che contiene le versioni modificate di funzioni di libreria standard del C vulnerabili (es. strcpy()). Questo è un altro modo per aumentare il nostro grado di protezione, ma bisogna tener conto che il problema non viene risolto definitivamente poiché Libsafe protegge solo un insieme ristretto di funzioni con risaputi problemi di bof e comunque non assicura una protezione nel caso in cui il codice scritto dal programmatore sia affetto da bof. 3.5 Evitare i buffer overflow ulteriori soluzioni: 31

32 Oltre a tutto quanto visto finora si può ovviare al bof in numerosi altri modi. Qui di seguito riportiamo un breve accenno ad altre tecniche tra quelle più usate: - Evitare di lasciare programmi che accettano parametri passati in ingresso con diritto di esecuzione a utenti qualsiasi; tali programmi,se non immunizzati dal bof, permettono un attacco poiché rendono possibile l input della shellcode voluta. - Rendere la sezione dati e stack non eseguibili; questa soluzione è facilmente implementabile a livello di stack poiché non causa perdite di prestazioni e non richiede né cambiamenti né ricompilazione dei programmi (tranne che in alcuni casi particolari). Purtroppo la situazione non è così semplice per la sezione dati visto che marcando tale sezione come non eseguibile si và incontro a problemi di compatibilità e, anche se fosse possibile risolverli, si potrebbe comunque attaccare non più inserendo del codice esterno ma corrompendo solamente i puntatori in modo da eseguire parti di codice pericolose presenti nel programma stesso o nelle librerie. - Introdurre nel compilatore tecniche che permettano controlli "lightweight" sull'integrità dell'indirizzo di ritorno. - Utilizzo di programmi opportuni come StackGuard che rileva e impedisce gli attacchi sullo stack proteggendo l'ip da alterazioni. StackGuard dispone una word di controllo dopo l'ip quando una funzione viene chiamata; se la word suddetta risulta modificata all'uscita dalla funzione significa che é stato tentato un attacco, quindi StackGuard lo segnala in syslog e interrompe l'esecuzione; la maggiore limitazione è che la protezione è però fornita solo per intrusioni nello stack che purtroppo non solo le uniche (ad esempio è possibile attaccare anche l'heap). Oltretutto è stato recentemente dimostrato che nonostante l'uso di questo programma o affini (es. StackShield) lo stack resta comunque passibile di bof. - Introdurre speciali controlli sui valori degli argomenti passati alle system calls. - Uso del DTE (Domain and Type Enforcement): tecnologia di controllo di accesso che associa uno specifico dominio ad ogni processo in esecuzione ed un tipo per ogni oggetto (es. oggetto=file, tipo=txt) in modo che a run-time un sottosistema DTE del kernel prende un dominio del processo e lo confronta con il tipo di ogni file o con il dominio di ogni altro processo nel quale tenta di accedere, dopodiché nega l'operazione se il confronto ha negato l'autorizzazione alla richiesta d'accesso. Lo svantaggio principale del DTE consiste in una profonda modifica al kernel e comunque richiede l'utilizzo di 20 system call aggiuntive. 32

33 3.6 Evitare i buffer overflow considerazioni finali: Da ciò che abbiamo visto si evince facilmente che non esiste purtroppo una soluzione definitiva al problema, se non quella di una programmazione attenta ai minimi particolari che in molti casi non è possibile attuare per la sua difficoltà di applicazione. Di conseguenza il problema necessita, per la sua risoluzione, di scelte oculate prese di caso in caso a seconda delle esigenze, in modo che i relativi svantaggi che introducono non vadano ad alterare il resto delle caratteristiche del programma. 33

34 Rsync 4.1 Cos è Rsync: Rsync è un programma open source, sviluppato per piattaforma Unix, creato per essere un veloce sistema di trasferimento file. Questo programma si basa sull algoritmo rsync il quale provvede ad implementare un metodo veramente veloce per sincronizzare i file remoti. L algoritmo riesce a determinare le differenze esistenti tra due file da sincronizzare, in modo che sia sufficiente trasferire solo le differenze, risparmiando così tempo. Alcune opzioni di rsync sono: - Può aggiornare intere directory e filesystems. - Opzionalmente preserva i link simbolici, gli hard links, i file ownership, i permessi. - Non richiede speciali privilegi per essere installato. - La pipelining interna riduce le latenze nel caso di file multipli. - Possono essere usate per il trasporto ssh, rsh o le direct sockets. - Supporta la funzione anonymous rsync che è ideale per il mirroring. 4.2 Perché è stato scelto Rsync per il processo di auditing del codice: Per l analisi è stato scelto questo software perché: - E un programma open source (e quindi comprensivo di codice sorgente) - E un programma noto usato da un utenza molto vasta e quindi era più probabile che eventuali bug fossero noti in modo da poter essere studiati. - E un programma di dimensioni medie adatto ad essere analizzato nel corso dei tre mesi dello stage. (Analizzare un programma come ad esempio Mozilla non sarebbe stato possibile in un così breve periodo di tempo). - E un programma utilizzato per lo scambio di dati tra computer connessi in rete e quindi si presta ad attacchi di tipo remoto. 4.3 Strumenti di analisi: 34

35 Rsync è stato scritto in linguaggio C standard. Per l analisi del suo codice è stato molto utile uno strumento di navigazione del codice chiamato Doxygen, il quale è un sistema di documentazione per C++, C, Java, IDL e vari tipi di PHP estesi. Esso genera, da un insieme di file sorgenti documentati, una documentazione on-line che può essere esplorata tramite un browser (in HTML) e/o un manuale off-line. Figura L algoritmo di Rsync: Ipotizziamo di avere due computer A e B connessi tramite una connessione con banda di bassa ampiezza e alta latenza. Al momento di iniziare il trasferimento abbiamo un file con ai bytes in A e un file con bi bytes in B. Assumiamo che 0 <= i < n e che ogni file sia lungo n bytes. Lo scopo dell algoritmo è per B quello di ricevere da A una copia del file. La struttura basilare di un algoritmo di aggiornamento remoto sarà: 35

36 - B manda delle informazioni S basate su bi ad A - A compara queste informazioni con ai e manda delle informazioni D a B. - B costruisce il nuovo file usando bi, S e D. Il problema è adesso sapere che cosa deve contenere S, come A può usare S per compararlo con ai e come B può ricostruire ai. Anche con questa semplice schematizzazione appare subito chiaro che l algoritmo richiede delle basi probabilistiche per essere utile. Le informazioni S che B manda a A dovranno essere in quantitativo molto minore del file completo in modo da avere un incremento di velocità di trasferimento significativo. Questo significa che S non può identificare unicamente tutti i possibili files bi il che significa che l algoritmo deve avere una bassa probabilità di fallimento. Un implementazione semplice: Un esempio di una forma veramente semplice dell algoritmo è: - B divide bi in N blocchi di uguale dimensione b j e calcola una firma Sj per ogni blocco. Questa firma è inviata ad A. - A divide ai in N blocchi a k e calcola S k per ogni blocco. - A cerca delle corrispondenze tra Sj e S k per ogni k. - Per ogni k, A manda a B ogni numero di blocco j in Sj che ha una corrispondenza con S k o manda un blocco letterale a k. - B costruisce ai usando i blocchi bi o i blocchi letterali ai. Questo algoritmo è veramente semplice e raggiunge molti degli obbiettivi del nostro algoritmo di aggiornamento remoto, ma non è usabile in pratica. Il problema è che A può trovare solo le corrispondenze che sono ai confini dei blocchi. Se il file in A è lo stesso che in B eccetto che un byte che è stato inserito all inizio del file, allora non si troverà nessuna corrispondenza di blocchi e l intero file verrà trasferito. La soluzione al problema: 36

37 Noi possiamo risolvere questo problema facendo si che A generi una firma non per ogni confine di blocchi ma per ogni byte. Quando A compara la firma ad ogni byte con ogni firma Sj nei blocchi bi sarà capace di trovare le corrispondenze???. Questo permette ai cambiamenti di lunghezza arbitraria di essere rilevati e trattati. Questo funzionerebbe, ma non è praticabile a causa dei costi di computazione di ogni firma per ogni possibile block. Si potrebbe rendere l algoritmo computazionalmente flessibile creando un algoritmo di firma molto veloce da calcolare ma questo è difficile da ottenere senza rendere la firma troppo debole. Una firma debole renderebbe l algoritmo inusabile. Per esempio, la firma potrebbe essere solo i primi 4 byte di ogni blocco. Questo sarebbe molto facile da calcolare ma l algoritmo fallirebbe nel produrre il giusto risultato quando due differenti blocchi avessero i loro primi 4 byte in comune. Due firme: La soluzione (che è poi la chiave dell algoritmo di rsync) è quella non di usare una singola firma per blocco, ma bensì due. La prima firma necessita di essere molto leggera da calcolare per tutti gli offset di byte e la seconda necessita di avere una probabilità di collisione veramente bassa. La seconda costosa firma necessita di essere calcolata da A all offset di byte dove la firma poco costosa ha una corrispondenza con una poco costosa firma di B. Se chiamiamo le due firme R e H l algoritmo diventa: 1. B divide bi in N blocchi di uguale dimensione bj e calcola le firme Rj e Hj per ogni blocco. Le firme sono spedite ad A. 2. Per ogni offset di byte i in ai, A calcola Ri nel blocco partendo da i. 3. A compara Rj per ogni Rj ricevuto da B. 4. Per ogni j dove R j ha una corrispondenza Rj, A calcola H i e lo confronta con Hj. 5. Se H i ha una corrispondenza Hj allora A manda un token a B indicante una corrispondenza fra blocchi e indicante quali blocchi hanno una corrispondenza. Altrimenti A manda un byte letterale a B. 6. B riceve i byte letterali e i token da A e li usa per costruire ai. Perché questo algoritmo sia efficiente abbiamo bisogno delle seguenti condizioni: - La firma R deve essere poco costosa da calcolare ad ogni offset di byte in un file. - La firma H deve avere una probabilità di collisione random veramente piccola. 37

38 - A necessita di effettuare le corrispondenze fra tutte le firme di blocchi ricevute da B in modo efficiente, e questo necessita di essere svolto per ogni offset di byte. 4.5 Storia dei bugs di Rsync: Rsync è giuto oramai alla verione Durante la sua evoluzione ha subito diversi cambiamenti e diversi suoi errori sono stati corretti. Fino ad ora, sono solo due i bug scoperti che potenzialmente potevano minare la sicurezza del sistema. Il primo a cui è stato assegnato il bugtraq id 3958 da Security Focus. Le versioni vulnerabili sono quelle dalla alla Questo bug è stato scoperto da Sebastian Krahmer, ricercatore dell università tedesca Postdam e sviluppatore della distribuzione Linux Suse. In alcune circostanze un valore signed è usato come indice di un array e questo porta alla possibilità di scrivere dei byte NULL in locazioni arbitrarie della memoria. Lo sfruttamento di questa vulnerabilità può condurre alla corruzione dello stack e possibilmente all'esecuzione del codice arbitrario come l'utente root. Nessun exploit è stato fino ad ora pubblicato per sfruttare questa vulnerabilità. La soluzione per questa vulnerabilità è data dall'aggiornamento del tool alla versione o superiore. Allo scopo di studiare i cambiamenti apportati al programma si è provveduto a confrontare due versioni di Rsync: la (vulnerabile) e la (contenente la pach). Chiaramente le differenze tra le due versioni non si limitano alla sola soluzione del problema riscontrato da Sebastian Krahmer, quindi è stato necessario studiare il codice al fine di separare i cambiamenti relativi alla risoluzione della vulnerabilità da quelli relativi a nuove funzionalità del programma. 4.6 Discussione della patch: Una vera e propria patch che risolva il problema riscontrato da Sebastian Krahmer non esiste. 38

39 La soluzione alla falla è stata implementata nelle versioni successive del programma. Quindi si sono dovute cercare i cambiamenti apportati relativi a questo problema tra tutti i cambiamenti e aggiunte effettuate nelle versioni successive di Rsync. Le modifiche relative al problema in esame coinvolgono 7 files del programma. Qui sotto è riportato il codice di una funzione rappresentativa del problema riscontrato e della sua soluzione. Le altre modifiche sono molto simili a quelle applicate per questa funzione. Figura 2 Il cambiamento intressa le due variabili l1 e l2 definite alla riga 470. Nella versione vulnerabile esse vengono definite di tipo int, mentre nella versione non vulnerabile esse vengono dichiarate unsigned int. 39

40 Il motivo per cui è stata apportata questa modifica è che utilizzando numeri molto grandi si potrebbe ingannare l'aritmetica e generare abusi dei buffer. Ad esempio, in condizioni normali, usando numeri da 16 bit il range di numeri va da 0 a 65mila circa. Dichiarando una variabile int si ha che i primi 32 k sono positivi mentre i rimanenti vengono considerati negativi in quanto vanno oltre il dominio. Quindi se io riuscissi ad immettere in l1 e/o l2 di tipo int un numero molto grande, come 65mila per esempio, esso manderebbe in crisi l'aritmetica e verrebbe considerato come circa. Il problema sta sicuramente nel confronto che viene effettuato alla riga 488. Infatti viene fatto un controllo in modo da verificare se l2 è maggiore o uguale a MAXPATHLEN l1. Se il numero in l2 è per errore un numero negativo, sicuramente il confronto darà esito negativo. Security Focus avverte che non esistono exploit conosciuti che sfruttano questa vulnerabilità. Anche ad una prima analisi del codice sembra che l'utente non possa in alcun modo alterare le variabili l1 e l2 in modo da provocare la vulnerabilità di cui abbiamo parlato. Questo quindi sembra essere un caso di vulnerabilità più teorica che pratica. 40

Corso di Sicurezza Informatica

Corso di Sicurezza Informatica Corso di Sicurezza Informatica Sicurezza del Software Ing. Giuseppe D Aquì Sicurezza nell informatica Un computer sicuro è un computer spento (Kevin Mitnick) Attacchi informatici Gli attacchi informatici,

Dettagli

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

Dettagli

Corso di Sicurezza Informatica. Sicurezza del software. Ing. Gianluca Caminiti

Corso di Sicurezza Informatica. Sicurezza del software. Ing. Gianluca Caminiti Corso di Sicurezza Informatica Sicurezza del software Ing. Gianluca Caminiti Software Sicuro Privo di errori (logici) che comportino un comportamento inatteso. Tali bug possono minare la sicurezza dell

Dettagli

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache... Appunti di Calcolatori Elettronici Concetti generali sulla memoria cache Introduzione... 1 Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

Dettagli

Allocazione dinamica della memoria - riepilogo

Allocazione dinamica della memoria - riepilogo Università degli studi di Milano Dipartimento di Scienze dell Informazione Laboratorio di algoritmi e strutture dati Corso di laurea in Informatica In breve Storage duration Allocazione dinamica della

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

Scritto da Administrator Martedì 02 Settembre 2008 06:30 - Ultimo aggiornamento Martedì 10 Maggio 2011 17:15

Scritto da Administrator Martedì 02 Settembre 2008 06:30 - Ultimo aggiornamento Martedì 10 Maggio 2011 17:15 Entrare in un pc è una espressione un po generica...può infatti significare più cose: - Disporre di risorse, quali files o stampanti, condivise, rese fruibili liberamente o tramite password con i ripettivi

Dettagli

Sistemi Operativi. Lez. 16 File System: aspetti implementativi

Sistemi Operativi. Lez. 16 File System: aspetti implementativi Sistemi Operativi Lez. 16 File System: aspetti implementativi Layout disco Tutte le informazioni necessarie al file system per poter operare, sono memorizzate sul disco di boot MBR: settore 0 del disco,

Dettagli

Altri metodi di indicizzazione

Altri metodi di indicizzazione Organizzazione a indici su più livelli Altri metodi di indicizzazione Al crescere della dimensione del file l organizzazione sequenziale a indice diventa inefficiente: in lettura a causa del crescere del

Dettagli

Software. Definizione, tipologie, progettazione

Software. Definizione, tipologie, progettazione Software Definizione, tipologie, progettazione Definizione di software Dopo l hardware analizziamo l altra componente fondamentale di un sistema di elaborazione. La macchina come insieme di componenti

Dettagli

GESTIONE DELLA MEMORIA CENTRALE

GESTIONE DELLA MEMORIA CENTRALE GESTIONE DELLA MEMORIA CENTRALE E MEMORIA VIRTUALE 7.1 Gestione della memoria Segmentazione Segmentazione con paginazione Memoria Virtuale Paginazione su richiesta Sostituzione delle pagine Trashing Esempi:

Dettagli

IMSV 0.8. (In Media Stat Virtus) Manuale Utente

IMSV 0.8. (In Media Stat Virtus) Manuale Utente Introduzione IMSV 0.8 (In Media Stat Virtus) Manuale Utente IMSV è una applicazione che calcola che voti può'prendere uno studente negli esami che gli mancano per ottenere la media che desidera. Importante:

Dettagli

2. Strutture dei Sistemi Operativi

2. Strutture dei Sistemi Operativi 1 2. Strutture dei Sistemi Operativi Quali servizi un generico sistema operativo mette a disposizione degli utenti, e dei programmi che gli utenti vogliono eseguire? interfaccia col sistema operativo stesso

Dettagli

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1)

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Pagina 1 di 10 Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Nel corso della lezione precedente abbiamo analizzato le caratteristiche dell'architettura CGI.

Dettagli

1. Spiegare le differenze fra le seguenti modalità di binding degli indirizzi:

1. Spiegare le differenze fra le seguenti modalità di binding degli indirizzi: 1. Spiegare le differenze fra le seguenti modalità di binding degli indirizzi: compile time, load time, execution time. Quale delle modalità precedenti necessita di un supporto hardware per poter essere

Dettagli

SISTEMI OPERATIVI. Gestione della memoria Domande di verifica. Luca Orrù Centro Multimediale Montiferru 18/06/2007

SISTEMI OPERATIVI. Gestione della memoria Domande di verifica. Luca Orrù Centro Multimediale Montiferru 18/06/2007 2007 SISTEMI OPERATIVI Gestione della memoria Domande di verifica Luca Orrù Centro Multimediale Montiferru 18/06/2007 Gestione della memoria 1. Si descriva il concetto di memoria virtuale (esame del 19-06-2006)

Dettagli

Le operazioni di allocazione e deallocazione sono a carico del sistema.

Le operazioni di allocazione e deallocazione sono a carico del sistema. Allocazione della memoria In C++ è possibile creare (allocare) variabili in maniera statica o dinamica. Nell allocazione statica una variabile esiste ed è utilizzabile dal momento della sua dichiarazione

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Pietro Frasca Lezione 5 Martedì 21-10-2014 Thread Come abbiamo detto, un processo è composto

Dettagli

11 Realizzazione del File System. 11.1.1 Struttura a livelli (fig. 11.1) 11.4 Allocazione dei file

11 Realizzazione del File System. 11.1.1 Struttura a livelli (fig. 11.1) 11.4 Allocazione dei file 11 Realizzazione del File System 1 Metodi di allocazione Allocazione contigua Allocazione concatenata e varianti Allocazione indicizzata e varianti Gestione dello spazio libero 11.1.1 Struttura a livelli

Dettagli

Architettura di un sistema di calcolo

Architettura di un sistema di calcolo Richiami sulla struttura dei sistemi di calcolo Gestione delle Interruzioni Gestione della comunicazione fra processore e dispositivi periferici Gerarchia di memoria Protezione. 2.1 Architettura di un

Dettagli

Breve riepilogo della puntata precedente:

Breve riepilogo della puntata precedente: Breve riepilogo della puntata precedente: 1. In C, il passaggio dei parametri alle funzioni avviene sempre per copia, ovvero il valore del parametro viene copiato all'interno della variabile che rappresenta

Dettagli

Introduzione alla Progettazione per Componenti

Introduzione alla Progettazione per Componenti Introduzione alla Progettazione per Componenti Alessandro Martinelli 6 ottobre 2014 Obiettivo del Corso Il Progetto Software Reale Il Componente Software La Programmazione Ad Oggetti Fondamenti di Informatica

Dettagli

PROGETTAZIONE FISICA

PROGETTAZIONE FISICA PROGETTAZIONE FISICA Memorizzazione su disco, organizzazione di file e tecniche hash 2 Introduzione La collezione di dati che costituisce una BDD deve essere fisicamente organizzata su qualche supporto

Dettagli

La Memoria Virtuale Ottimizzazione della memoria centrale

La Memoria Virtuale Ottimizzazione della memoria centrale La Memoria Virtuale Ottimizzazione della memoria centrale 1) Introduzione- Gerarchia della memoria Da un punto di vista funzionale, ogni dispositivo di memorizzazione elettronica di informazioni presenta

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16 Pietro Frasca Lezione 15 Martedì 24-11-2015 Struttura logica del sottosistema di I/O Processi

Dettagli

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER L architettura CLIENT SERVER è l architettura standard dei sistemi di rete, dove i computer detti SERVER forniscono servizi, e computer detti CLIENT, richiedono

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Lezione 3 Martedì 15-10-2013 1 Struttura ed organizzazione software dei sistemi

Dettagli

2. I THREAD. 2.1 Introduzione

2. I THREAD. 2.1 Introduzione 2. I THREAD 2.1 Introduzione Il tipo di parallelismo che è opportuno avere a disposizione nelle applicazioni varia in base al grado di cooperazione necessaria tra le diverse attività svolte in parallelo:

Dettagli

Corso di Alfabetizzazione Informatica

Corso di Alfabetizzazione Informatica Corso di Alfabetizzazione Informatica Lezione 6 a.a. 2010/2011 Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono: diversi

Dettagli

Sistemi Operativi GESTIONE DELLA MEMORIA CENTRALE. D. Talia - UNICAL. Sistemi Operativi 6.1

Sistemi Operativi GESTIONE DELLA MEMORIA CENTRALE. D. Talia - UNICAL. Sistemi Operativi 6.1 GESTIONE DELLA MEMORIA CENTRALE 6.1 Gestione della Memoria Background Spazio di indirizzi Swapping Allocazione Contigua Paginazione 6.2 Background Per essere eseguito un programma deve trovarsi (almeno

Dettagli

Algoritmo per il rilevamento di targhe

Algoritmo per il rilevamento di targhe Algoritmo per il rilevamento di targhe 19 maggio 2008 Nell affrontare il problema del riconoscimento delle targhe sono stati sviluppati due algoritmi che basano la loro ricerca su criteri differenti. Lo

Dettagli

Appunti del corso di Informatica 1. 6 Introduzione al linguaggio C

Appunti del corso di Informatica 1. 6 Introduzione al linguaggio C Università di Roma Tre Dipartimento di Matematica e Fisica Corso di Laurea in Matematica Appunti del corso di Informatica 1 (IN110 Fondamenti) 6 Introduzione al linguaggio C Marco Liverani (liverani@mat.uniroma3.it)

Dettagli

Strumenti per l Analisi Statica e Dinamica di Eseguibili

Strumenti per l Analisi Statica e Dinamica di Eseguibili Pattern Recognition and Applications Lab Strumenti per l Analisi Statica e Dinamica di Eseguibili Dott. Ing. Davide Maiorca davide.maiorca@diee.unica.it Corso di Sicurezza Informatica A.A. 2014/2015 Dipartimento

Dettagli

Sistemi Operativi. 5 Gestione della memoria

Sistemi Operativi. 5 Gestione della memoria Gestione della memoria Compiti del gestore della memoria: Tenere traccia di quali parti della memoria sono libere e quali occupate. Allocare memoria ai processi che ne hanno bisogno. Deallocare la memoria

Dettagli

Protezione. Sistemi Operativi mod. B 16.1

Protezione. Sistemi Operativi mod. B 16.1 Protezione Scopi della Protezione Dominio di Protezione Matrice d Accesso Implementazione della Matrice d Accesso Revoca dei Diritti d Accesso Sistemi Basati su Abilitazioni Protezione basata sul linguaggio

Dettagli

I Thread. I Thread. I due processi dovrebbero lavorare sullo stesso testo

I Thread. I Thread. I due processi dovrebbero lavorare sullo stesso testo I Thread 1 Consideriamo due processi che devono lavorare sugli stessi dati. Come possono fare, se ogni processo ha la propria area dati (ossia, gli spazi di indirizzamento dei due processi sono separati)?

Dettagli

Infrastrutture Software

Infrastrutture Software Infrastrutture Software I componenti fisici di un sistema informatico sono resi accessibili agli utenti attraverso un complesso di strumenti software finalizzati all utilizzo dell architettura. Si tratta

Dettagli

Appunti del corso di Informatica 1 (IN110 Fondamenti) 6 Introduzione al linguaggio C

Appunti del corso di Informatica 1 (IN110 Fondamenti) 6 Introduzione al linguaggio C Università di Roma Tre Facoltà di Scienze M.F.N. Corso di Laurea in Matematica Appunti del corso di Informatica 1 (IN110 Fondamenti) 6 Introduzione al linguaggio C Marco Liverani (liverani@mat.uniroma3.it)

Dettagli

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Patrizia Scandurra Università degli Studi di Bergamo a.a. 2009-10 Sommario L hardware di I/O Struttura Interazione tra computer e controllori

Dettagli

Architettura di un computer

Architettura di un computer Architettura di un computer Modulo di Informatica Dott.sa Sara Zuppiroli A.A. 2012-2013 Modulo di Informatica () Architettura A.A. 2012-2013 1 / 36 La tecnologia Cerchiamo di capire alcuni concetti su

Dettagli

Linguaggi di programmazione

Linguaggi di programmazione Linguaggi di programmazione Programmazione L attività con cui si predispone l elaboratore ad eseguire un particolare insieme di azioni su particolari dati, allo scopo di risolvere un problema Dati Input

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione.

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione. C6. REALIZZAZIONE DEL FILE SYSTEM Struttura del file system Un file è analizzabile da diversi punti di vista. Dal punto di vista del sistema è un contenitore di dati collegati tra di loro, mentre dal punto

Dettagli

La gestione della memoria

La gestione della memoria La gestione della memoria DOTT. ING. LEONARDO RIGUTINI DIPARTIMENTO INGEGNERIA DELL INFORMAZIONE UNIVERSITÀ DI SIENA VIA ROMA 56 53100 SIENA UFF. 0577234850-7102 RIGUTINI@DII.UNISI.IT HTTP://WWW.DII.UNISI.IT/~RIGUTINI/

Dettagli

Introduzione al Linguaggio C

Introduzione al Linguaggio C Introduzione al Linguaggio C File I/O Daniele Pighin April 2009 Daniele Pighin Introduzione al Linguaggio C 1/15 Outline File e dati Accesso ai file File I/O Daniele Pighin Introduzione al Linguaggio C

Dettagli

ARCHIVI E LORO ORGANIZZAZIONI

ARCHIVI E LORO ORGANIZZAZIONI ARCHIVI E LORO ORGANIZZAZIONI Archivio: - insieme di registrazioni (record), ciascuna costituita da un insieme prefissato di informazioni elementari dette attributi (campi) - insieme di informazioni relative

Dettagli

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. Implementazione del File System. Struttura del File System. Implementazione

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. Implementazione del File System. Struttura del File System. Implementazione IMPLEMENTAZIONE DEL FILE SYSTEM 9.1 Implementazione del File System Struttura del File System Implementazione Implementazione delle Directory Metodi di Allocazione Gestione dello spazio libero Efficienza

Dettagli

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. D. Talia - UNICAL. Sistemi Operativi 9.1

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. D. Talia - UNICAL. Sistemi Operativi 9.1 IMPLEMENTAZIONE DEL FILE SYSTEM 9.1 Implementazione del File System Struttura del File System Implementazione Implementazione delle Directory Metodi di Allocazione Gestione dello spazio libero Efficienza

Dettagli

Sistemi Operativi. Organizzazione logica ed implementazione di un File System

Sistemi Operativi. Organizzazione logica ed implementazione di un File System Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Organizzazione logica ed implementazione di un File

Dettagli

La gestione della memoria

La gestione della memoria La gestione della memoria Nella gestione della memoria il sistema operativo deve perseguire l'obiettivo di allocare il maggior numero di processi in memoria centrale per aumentare la probabilità che ci

Dettagli

SICUREZZA. Sistemi Operativi. Sicurezza

SICUREZZA. Sistemi Operativi. Sicurezza SICUREZZA 14.1 Sicurezza Il Problema della Sicurezza Convalida Pericoli per i Programmi Pericoli per il Sistema Difendere i Sistemi Scoperta di Intrusioni Cifratura Esempio: Windows NT 14.2 Il Problema

Dettagli

Sistemi Operativi SICUREZZA. Sistemi Operativi. D. Talia - UNICAL 14.1

Sistemi Operativi SICUREZZA. Sistemi Operativi. D. Talia - UNICAL 14.1 SICUREZZA 14.1 Sicurezza Il Problema della Sicurezza Convalida Pericoli per i Programmi Pericoli per il Sistema Difendere i Sistemi Scoperta di Intrusioni Cifratura Esempio: Windows NT 14.2 Il Problema

Dettagli

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica www.dis.uniroma1.it/~midlab Sistemi Operativi II Corso di Laurea in Ingegneria Informatica Prof. Roberto Baldoni Complementi: Buffer I/O Gestione dei buffer e I/O scheduling: 1. Richiami sulle tecniche

Dettagli

SISTEMI OPERATIVI 14 settembre 2015 corso A nuovo ordinamento e parte di teoria del vecchio ordinamento indirizzo SR

SISTEMI OPERATIVI 14 settembre 2015 corso A nuovo ordinamento e parte di teoria del vecchio ordinamento indirizzo SR SISTEMI OPERATIVI 14 settembre 2015 corso A nuovo ordinamento e parte di teoria del vecchio ordinamento indirizzo SR Cognome: Nome: Matricola: 1. Ricordate che non potete usare calcolatrici o materiale

Dettagli

Ing. Paolo Domenici PREFAZIONE

Ing. Paolo Domenici PREFAZIONE Ing. Paolo Domenici SISTEMI A MICROPROCESSORE PREFAZIONE Il corso ha lo scopo di fornire i concetti fondamentali dei sistemi a microprocessore in modo semplice e interattivo. È costituito da una parte

Dettagli

Introduzione alla programmazione in C

Introduzione alla programmazione in C Introduzione alla programmazione in C Testi Consigliati: A. Kelley & I. Pohl C didattica e programmazione B.W. Kernighan & D. M. Ritchie Linguaggio C P. Tosoratti Introduzione all informatica Materiale

Dettagli

Capitolo 11 -- Silberschatz

Capitolo 11 -- Silberschatz Implementazione del File System Capitolo 11 -- Silberschatz Implementazione del File System File system: Definizione dell aspetto del sistema agli occhi dell utente Algoritmi e strutture dati che permettono

Dettagli

Elementi del calcolatore: CPU

Elementi del calcolatore: CPU Elementi del calcolatore: CPU Elementi del calcolatore: Memoria Elementi del calcolatore: Memoria Elementi del calcolatore: Hard Disk Antefatto Sistema Operativo Come il computer appare Il calcolatore

Dettagli

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS

File e indici. Tecnologia delle BD: perché studiarla? Le basi di dati sono grandi e persistenti. DataBase Management System DBMS 1 Tecnologia delle BD: perché studiarla? File e indici I DBMS offrono i loro servizi in modo "trasparente": per questo abbiamo potuto finora ignorare molti aspetti realizzativi abbiamo considerato il DBMS

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

Dettagli

Fabio Zanasi. 12 maggio 2010

Fabio Zanasi. 12 maggio 2010 Figura: 1 / 26 12 maggio 2010 Cos è? è un sistema di controllo delle versioni (version control system). è un software open-source per ambienti Unix, Windows, OS-X. è lo strumento ideale per gestire il

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

Sicurezza dei sistemi e delle reti Introduzione

Sicurezza dei sistemi e delle reti Introduzione Sicurezza dei sistemi e delle reti Introduzione Damiano Carra Università degli Studi di Verona Dipartimento di Informatica Riferimenti! Cap. 8 di Reti di calcolatori e Internet. Un approccio topdown, J.

Dettagli

Indice. settembre 2008 Il File System 2

Indice. settembre 2008 Il File System 2 Il File System Indice 4. Il File System 5. Vantaggi del FS 6. Protezione 7. Condivisione 8. I file - 1 9. I file - 2 10. Attributi dei file 11. Directory 12. Livelli di astrazione - 1 13. Livelli di astrazione

Dettagli

INDICE PROGRAMMA CORSO

INDICE PROGRAMMA CORSO INDICE PROGRAMMA CORSO PRIMA LEZIONE: Componenti di un computer: Hardware, Software e caratteristiche delle periferiche. SECONDA LEZIONE: Elementi principali dello schermo di Windows: Desktop, Icone, Mouse,

Dettagli

Esercizi su. Funzioni

Esercizi su. Funzioni Esercizi su Funzioni ๒ Varie Tracce extra Sul sito del corso ๓ Esercizi funz_max.cc funz_fattoriale.cc ๔ Documentazione Il codice va documentato (commentato) Leggibilità Riduzione degli errori Manutenibilità

Dettagli

Lezione n.9. Introduzione al linguaggio macchina

Lezione n.9. Introduzione al linguaggio macchina Lezione n.9 Autore:Luca Orrù 1 Sommario Esecuzione delle istruzioni Architettura interna ed esterna Linguaggio assembler e modi d indirizzamento Consideriamo ora la singola istruzione e la scomponiamo

Dettagli

Definizione di processo. Un processo è un programma (o una parte di una programma) in corso di esecuzione

Definizione di processo. Un processo è un programma (o una parte di una programma) in corso di esecuzione SISTEMI OPERATIVI (parte prima - gestione dei processi) Tra i compiti di un sistema operativo sicuramente troviamo i seguenti: Gestione dei processi Gestione della memoria Gestione del file-system Ci occuperemo

Dettagli

Gestione dei processi. Marco Cesati. Schema della lezione. Blocco di controllo 2. Sezioni e segmenti. Gestione dei processi. Job.

Gestione dei processi. Marco Cesati. Schema della lezione. Blocco di controllo 2. Sezioni e segmenti. Gestione dei processi. Job. Di cosa parliamo in questa lezione? Lezione 4 Cosa è un processo e come viene gestito dal SO 1 e job 2 Il blocco di controllo Sistemi operativi 3 Struttura di un file eseguibile 4 La schedulazione dei

Dettagli

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato SCP: SCHEDULER LAYER a cura di Alberto Boccato PREMESSA: Negli ultimi tre anni la nostra scuola ha portato avanti un progetto al quale ho partecipato chiamato SCP (Scuola di Calcolo Parallelo). Di fatto

Dettagli

Sistemi Operativi. Modulo 2. C. Marrocco. Università degli Studi di Cassino

Sistemi Operativi. Modulo 2. C. Marrocco. Università degli Studi di Cassino Sistemi Operativi Modulo 2 Schema di un Sistema di Calcolo Programmi Dati di Input Calcolatore Dati di output Modello di von Neumann Bus di sistema CPU Memoria Centrale Memoria di Massa Interfaccia Periferica

Dettagli

Realizzato da: Ing. Francesco Cacozza

Realizzato da: Ing. Francesco Cacozza (ITALIANO) Software Gestionale Professionale Specifico per Comuni Realizzato da: Ing. Francesco Cacozza Indice Introduzione e requisiti tecnici 3 Installazione 5 Menu principale 6 Gestione 7 Dati Societari

Dettagli

Introduzione. Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD... 6

Introduzione. Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD... 6 Appunti di Calcolatori Elettronici Esecuzione di istruzioni in parallelo Introduzione... 1 Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD...

Dettagli

Software Applicativo. Hardware. Sistema Operativo Software di Base Traduttori e Linguaggi

Software Applicativo. Hardware. Sistema Operativo Software di Base Traduttori e Linguaggi : di base e applicativo L HardWare (monitor, tastiera, circuiti, stampante, ) è il nucleo fondamentale del calcolatore ma da solo non serve a nulla. Bisogna utilizzare il software per poterlo fare funzionare.

Dettagli

Struttura logica di un programma

Struttura logica di un programma Struttura logica di un programma Tutti i programmi per computer prevedono tre operazioni principali: l input di dati (cioè l inserimento delle informazioni da elaborare) il calcolo dei risultati cercati

Dettagli

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a:

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a: Lab 4.1 Utilizzare FTP (File Tranfer Protocol) LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) In questa lezione imparerete a: Utilizzare altri servizi Internet, Collegarsi al servizio Telnet, Accedere

Dettagli

13 - Gestione della Memoria nella Programmazione Orientata agli Oggetti

13 - Gestione della Memoria nella Programmazione Orientata agli Oggetti 13 - Gestione della Memoria nella Programmazione Orientata agli Oggetti Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/

Dettagli

FORSETI BLOG. Readcast. Aprile 2014 Speciale Heartbleed. http://blog.forseti.it/

FORSETI BLOG. Readcast. Aprile 2014 Speciale Heartbleed. http://blog.forseti.it/ FORSETI BLOG Readcast Aprile 2014 Speciale Heartbleed http://blog.forseti.it/ Indice di 3 Forseti Blog - Aprile 2014 3 di Dottore in Sicurezza dei Sistemi e delle Reti Informatiche, Dottore Magistrale

Dettagli

1) Una periferica di input è: A) il mouse B) il monitor C) la stampante

1) Una periferica di input è: A) il mouse B) il monitor C) la stampante CONOSCENZE DI INFORMATICA 1) Una periferica di input è: A) il mouse B) il monitor C) la stampante 2) Una memoria in sola lettura con la particolarità di essere cancellata in particolari condizioni è detta:

Dettagli

Protezione del Software

Protezione del Software Protezione dalla copia Protezione del Software Alfredo De Santis! Aprile 0! Trovare un metodo contro la pirateria efficiente economico resistente contro i pirati esperti non invasivo Compito impossibile!

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Progetto Febbraio 2013 - Appello 1: Diffusione di tweets sul grafo di Twitter

Progetto Febbraio 2013 - Appello 1: Diffusione di tweets sul grafo di Twitter UNIVERSITÀ DEGLI STUDI DI MILANO, DIPARTIMENTO DI INFORMATICA LAUREA TRIENNALE IN COMUNICAZIONE DIGITALE CORSO DI RETI DI CALCOLATORI ANNO ACCADEMICO 2011/2012 Progetto Febbraio 2013 - Appello 1: Diffusione

Dettagli

Corso di Informatica Modulo T3 B1 Programmazione web

Corso di Informatica Modulo T3 B1 Programmazione web Corso di Informatica Modulo T3 B1 Programmazione web 1 Prerequisiti Architettura client/server Elementi del linguaggio HTML web server SQL server Concetti generali sulle basi di dati 2 1 Introduzione Lo

Dettagli

Il software. la parte contro cui si può solo imprecare. Il software

Il software. la parte contro cui si può solo imprecare. Il software Il software la parte contro cui si può solo imprecare Il software L hardware da solo non è sufficiente per il funzionamento dell elaboratore ma è necessario introdurre il software ovvero un insieme di

Dettagli

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II)

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II) SISTEMI OPERATIVI (MODULO DI INFORMATICA II) Realizzazione del file system Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) Università degli Studi di Bergamo a.a. 2012-13 Sommario Realizzazione

Dettagli

FONDAMENTI di INFORMATICA L. Mezzalira

FONDAMENTI di INFORMATICA L. Mezzalira FONDAMENTI di INFORMATICA L. Mezzalira Possibili domande 1 --- Caratteristiche delle macchine tipiche dell informatica Componenti hardware del modello funzionale di sistema informatico Componenti software

Dettagli

Richiami di informatica e programmazione

Richiami di informatica e programmazione Richiami di informatica e programmazione Il calcolatore E una macchina usata per Analizzare Elaborare Collezionare precisamente e velocemente una grande quantità di informazioni. Non è creativo Occorre

Dettagli

Corso di Esercitazioni di Programmazione

Corso di Esercitazioni di Programmazione Corso di Esercitazioni di Programmazione Introduzione Dott.ssa Sabina Rossi Informazioni Pagina web del corso: News Orari Mailing list Lezioni Esercitazioni Date esami Risultati esami.. http://www.dsi.unive.it/~prog1

Dettagli

Linguaggio C. Fondamenti. Struttura di un programma.

Linguaggio C. Fondamenti. Struttura di un programma. Linguaggio C Fondamenti. Struttura di un programma. 1 La storia del Linguaggio C La nascita del linguaggio C fu dovuta all esigenza di disporre di un Linguaggio ad alto livello adatto alla realizzazione

Dettagli

Corso introduttivo all utilizzo di TQ Tara

Corso introduttivo all utilizzo di TQ Tara Corso introduttivo all utilizzo di TQ Tara Le pagine che seguono introducono l utente all uso delle principali funzionalità di TQ Tara mediante un corso organizzato in otto lezioni. Ogni lezione spiega

Dettagli

Database e reti. Piero Gallo Pasquale Sirsi

Database e reti. Piero Gallo Pasquale Sirsi Database e reti Piero Gallo Pasquale Sirsi Approcci per l interfacciamento Il nostro obiettivo è, ora, quello di individuare i possibili approcci per integrare una base di dati gestita da un in un ambiente

Dettagli

Informatica 3. Informatica 3. LEZIONE 6: Il controllo dell esecuzione. Lezione 6 - Modulo 1. Errori durante l esecuzione. Il controllo dell esecuzione

Informatica 3. Informatica 3. LEZIONE 6: Il controllo dell esecuzione. Lezione 6 - Modulo 1. Errori durante l esecuzione. Il controllo dell esecuzione Informatica 3 Informatica 3 LEZIONE 6: Il controllo dell esecuzione Modulo 1: La gestione delle eccezioni Modulo 2: Programmazione concorrente Lezione 6 - Modulo 1 La gestione delle eccezioni Politecnico

Dettagli

INTERNET EXPLORER Breve manuale d uso

INTERNET EXPLORER Breve manuale d uso INTERNET EXPLORER Breve manuale d uso INDICE INTRODUZIONE... 3 COME IMPOSTARE LA PAGINA INIZIALE... 3 LA WORK AREA... 3 LE VOCI DI MENU... 5 IL MENU FILE... 5 IL MENU MODIFICA... 6 IL MENU VISUALIZZA...

Dettagli

Gli indirizzi dell Internet Protocol. IP Address

Gli indirizzi dell Internet Protocol. IP Address Gli indirizzi dell Internet Protocol IP Address Il protocollo IP Prevalente è ormai diventato nell implementazione di reti di computer la tecnologia sintetizzata nei protocolli TCP- Ip IP è un protocollo

Dettagli

Internet, così come ogni altra rete di calcolatori possiamo vederla suddivisa nei seguenti componenti:

Internet, così come ogni altra rete di calcolatori possiamo vederla suddivisa nei seguenti componenti: Pagina 1 di 8 Struttura di Internet ed il livello rete Indice Struttura delle reti Estremità della rete Il nucleo della rete Reti a commutazione di pacchetto e reti a commutazione di circuito Funzionalità

Dettagli

Protezione. Protezione. Protezione. Obiettivi della protezione

Protezione. Protezione. Protezione. Obiettivi della protezione Protezione Protezione La protezione riguarda i meccanismi per il controllo dell accesso alle risorse in un sistema di calcolo da parte degli utenti e dei processi. Meccanismi di imposizione fissati in

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica CL3 - Biotecnologie Orientarsi nel Web Prof. Mauro Giacomini Dott. Josiane Tcheuko Informatica - 2006-2007 1 Obiettivi Internet e WWW Usare ed impostare il browser Navigare in internet

Dettagli

Gestione della Memoria

Gestione della Memoria Gestione della Memoria Idealmente la memoria dovrebbe essere grande veloce non volatile Gerarchia di memorie Disco: capiente, lento, non volatile ed economico Memoria principale: volatile, mediamente grande,

Dettagli