Anteprima
Vedrai una selezione di 9 pagine su 38
Sistemi operativi Pag. 1 Sistemi operativi Pag. 2
Anteprima di 9 pagg. su 38.
Scarica il documento per vederlo tutto.
Sistemi operativi Pag. 6
Anteprima di 9 pagg. su 38.
Scarica il documento per vederlo tutto.
Sistemi operativi Pag. 11
Anteprima di 9 pagg. su 38.
Scarica il documento per vederlo tutto.
Sistemi operativi Pag. 16
Anteprima di 9 pagg. su 38.
Scarica il documento per vederlo tutto.
Sistemi operativi Pag. 21
Anteprima di 9 pagg. su 38.
Scarica il documento per vederlo tutto.
Sistemi operativi Pag. 26
Anteprima di 9 pagg. su 38.
Scarica il documento per vederlo tutto.
Sistemi operativi Pag. 31
Anteprima di 9 pagg. su 38.
Scarica il documento per vederlo tutto.
Sistemi operativi Pag. 36
1 su 38
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

BSD:

- Protezione della memoria mediante mapping e proitezione delle pagine

- Modello di sicurezza di UNIX con proprietari, gruppi, permessi, policy, ecc…

- Modello dei processi con PID, utenti proprietari, gruppi proprietari, segnali, ecc..

- Supporto al networking con protocolli TCP/IP, socket, firewall, ecc..

- API POSIX e syscall

- Thread lato utente (pthread) basati sui Match thread

- Virtual file system BSD con filesystem fisici come FAT32

5. Si descrivano le policy di sicurezza per la protezione del kernel iOS.

Per proteggere il kernel iOS adotta le seguenti policy di sicurezza:

- Write XOR Execute: ossia imposta sulle pagine di memoria o il permesso di scrittura oppure quello di

esecuzione, mai entrambi insieme.

- KASLR (Kernel Address Space Layer Randomization), consiste nel caricare il Kernel in posizioni di memoria

differente ad ogni avvio del sistema.

- KPP (Kernel Patch Protection), consiste in un check sia hardware che software del kernel, in caso di

anomalie il sistema entra in kernel panic

- Pointer Autentication, i puntatori critici alla memoria vengono protetti tramite autenticazione crittografica

via hardware

6. Descrivere le caratteristiche principali del pattern MVC in iOS.

Il Pattern MVC in iOS è scomposto da tre componenti:

- Model: contiene i dati dell’app e la logica con cui vengono modellati

- View: rappresenta un rettangolo sullo schermo del device renderizzato ed animato da CoreAnimation

- Controller: intermediario tra model e view, modifica le gerarchie di view a seguito di modifiche ai dati del

model, gestisce le interazioni dell’utente con le view coordinandosi con altri controller per portare a

termine tasks complessi.

Grazie al controller model e view non sono strettamente collegati e questo favorisce il riutilizzo delle view

7. Descrivere le politiche di sicurezza adottate dal kernel iOS

Le politiche di sicurezza adottade da iOS per la protezione del kernel sono:

- Non concedere mai insieme i permessi di scrittura ed esecuzione delle pagine di memoria

- KASLR (Kernel Address Space Layout Randomization) caricare il kernel in posizioni diverse di memoria ad

ogni avvio

- KPP (kernel Patch Protection) check sia hardware che software dekk’integrità del kernel, in caso di

anomalie si va in kernel panic.

- Pointer autentication: Puntatori critici alla memoria sono proteti mediante autenticazione crittografica via

hardware.

8. Si descrivano le peculiarità generali del sistema operativo iOS.

IOS è un SO proprietario di Apple progettato per girare su dispositivi mobile, ossia iPone e nelle varianti

WatchOS e TVOS gira rispettivamente su AppleWatch e AppleTV, è closed source ma con diverse

componenti open source. Come Mac OS è basato su Darwin che è un SO completo open Source con kernel

XNU che è un kernel ibrido con parte monolitica BSD e parte a micro kernel Match. Con SWIFT è possibile

sviluppare app native per iOS.

È un SO layerizzato:

- CocoaTouch

- CoreMedia

- CoreService

- CoreOS

- Kernel XNU e driver

Sicurezza di avvio con secure boot chain a stadi.

Meccanismi di sicurezza per la protezione del kernel, i dati, le app, ecc…

Dati biometrici salvati nel SEP.

Tutto è un app anche l’interfaccia grafica springboard.

La distribuzione dei software è centralizzata (appstore)

9. Apple File System, caratteristiche principali, prestazioni e sicurezza anche in rapporto con altri file

system noti

Il FS proprietario di Apple supporta inode numbers a 64 bit; utilizza il meccanismo del Copy On Write (i file

condivisi vengono ripetuti solo se modificati), e grazie a questo meccanismo crea periodicamente una

snapshot del FS per ripristinarlo in caso di crash; supporta partizioni a dimensione dinamica e protegge

crittograficamente i file con una o più chiavi.

10. Descrivere come iOS attua politiche di sicurezza per i dati e applicazioni

Per quanto riguarda la sicurezza dei dati, iOS sfrutta un co-processore per la crittografia, cifrando usando

una o più chiavi uniche ogni file; inoltre i dati biometrici sono salvati in un sottosistema hardware (SEP,

Secure Enclaver Processor) inaccessibile a qualunque processo, kernel incluso. Mentre per quanto riguarda

la sicurezza delle applicazioni, in iOS è presente il code signing ovvero ogni app dev’essere firmata

crittograficamente da Apple per poter essere lanciate; oltre al sandboxing utilizzato per evitare che ogni app

non acceda a file di altre app o a feature alle quali non ha autorizzazione

11. Descrivere brevemente le caratteristiche del filesystem adottato da iOS.

Il filesystem adottato da Apple è APFS (Apple FIle System) ed offre:

- Inode numbers a 64 bit

- CoW (Copy On Write): quando un file viene copiato, la sua memoria non viene duplicata.

- Snapshots: APFS può fare istantanee dei suoi contenuti, in modo da poter ripristinare file o interi volumi ad

uno stato noto.

Grazie alla CoW, gli snapshot non utilizzano spazio addizionale al momento della loro creazione.

- Supporto a partizioni di dimensione dinamica tramite condivisione di «container» di dimensione fissa.

- Crittografia: cifratura a chiave singola univoca per file, o a chiave multipla per cifrare diverse parti dei file

con una chiave diversa

NuttX/PX4

1. Descrivere i principali algoritmi di scheduling della CPU adottati dai SO real time. Specificare quali fra

essi è impiegato nel SO NuttX. Chiarire in dettaglio le motivazioni della scelta.

I principali algoritmi di CPU scheduling per sistemi real-time sono:

- Round Robin: basato su preemption, viene concesso al processo in esecuzione un quanto di tempo di CPU

(time slice) allo scadere del quale viene sottratta la CPU al processo in esecuzione e viene schedulato un

nuovo processo.

- Schedulazione a priorità: processi con priorità più alta vengono schedulati prima di processi con priorità

più bassa, solitamente i processi con la priorità più alta sono quelli real-time, questo algoritmo può essere

combinato con algoritmi basati su preemption.

- Rate monotonic scheduling: priorità statica per ogni processo calcolata in base alla frequenza di utilizzo

della CPU; alta frequenza di utilizzo → alta priorità; si può applicare la preemption NuttX Schedula i suoi task

con l’algoritmo di scheduling rate monotonic scheduling, questo perché è l’unico algoritmo in grado di

rispettare le deadline imposte da un sistema real time come NuttX, cosa che infatti non è garantita nel

Round Robin e nella schedulazione a priorità

2. Descrivere brevemente l’architettura del flight stack PX4.

L’architettura di PX4 di divide in Flight stack e Middleware.

L’architettura del Flight stack a sua volta si divide in:

- Estimator: riceve in input i dati dai sensori di bordo del device, li combina e li elabora definendo lo stato

attuale del device e fissa un setpoint che invia al controller.

- Controller: riceve in input una stima dello stato del device e il setpoint dall’estimator, in base a questi invia

dati e comandi al device per effettuare delle correzioni cambiandone l’assetto e muovendolo verso la

posizione desiderata.

- Mixer: riceve in input i dati e i comandi dal controller e li traduce in comandi low-level da inviare ai singoli

motori del device assicurandosi che questi ultimi nel rispondere ai comandi rispettino dei limiti strutturali

prestabiliti.

3. Descrivere gli stati previsti dallo scheduling dei task su NuttX. Durante lo scheduling dei task, i task, in

base al loro stato si muovono su diverse liste durante il loro ciclo di vita:

- Inactive_tasks: lista di task non ancora avviati o terminati.

- Ready-to-run: lista dei task inizializzati e pronti ad essere eseguiti, in testa alla lista c’è il task attualmente

in esecuzione e in coda ci sono i tasks in idle.

- Pending_tasks: lista dei tasks pronti a partire ma bloccati perché sul task attualmente in esecuzione non è

applicabile la preemption, oppure perché i task in coda alla lista ready-to-run hanno priorità maggiore.

- Blocked_tasks: in questo stato ci sono due liste di tasks: waitingforsemaphore e waitingforsignal

4. Descrivere il concetto di task in NuttX, chiarendo le eventuali analogie e differenze con processi e

thread di un sistema operativo general purpose.

Un task in NuttX è una sequenza di istruzioni dotata di un opportuno stack. Ogni task è dotato di un taskID e

un Task Control Block che contiene i metadati e le informazioni circa il task, in analogia ai processi di un SO

general purpose che posseggono un PID e un PCB con le stesse funzioni. Un task in NuttX, così come un

processo in un SO general purpose, può istanziare uno o più thread. La gerarchia dei task in NuttX è di tipo

parent/child in cui un child task eredita dal parent task i file stream stdin e stdout; il parent task attende che

il child task termini per essere rimosso. Questo è abbastanza analogo alla gerarchia padre/figlio dei processi

general purpose, solo che in aggiunta al padre che attende la terminazione del figlio per essere rimosso, nei

processi general purpose c’è la possibilità che un processo padre entri in concorrenza con i processi figli per

l’acquisizione delle varie risorse tra cui la CPU, inoltre un processo figlio può non condividere nessuna

risorsa con il processo padre, può condividere un sottoinsieme di risorse del padre, oppure può essere un

esatto duplicato del padre condividendo tutte le risorse. Altra differenza tra i task in NuttX e i processi nei

SO general purpose è il tipo di scheduling, infatti nei SO general purpose ci sono tanti algoritmi di scheduling

possibili tra cui FCFS, SJF, RR tutti combinabili con la preemption o no, in NuttX, per le necessità di un SO real

time, si opta per il rate monotonic scheduling che assegna una priorità statica ad ogni processo in base alla

frequenza di utilizzo della CPU (alta frequenza → alta priorità) abbinabile con la preemption, consente di

rispettare le deadline di un SO real time come NuttX

5. Descrivere i principali meccanismi di IPC di NuttX.

I principali meccanismi di IPC in NuttX sono:

- Signals: ogni task, incluso l’interrupt handler può inviare dei segnali ad altri task, il task che riceve il

segnale viene attivato e deve effettuare una routine di gestione del segnale ricevuto.

- POSIX Message queue: ogni thread è dotato di una cosa il cui main è in attesa di messaggi l’interrupt

handler invia un messaggio alla coda di un thread quando si verifica un evento, questo attiva il task

ricevente che esegue l’elaborazione specifica

6. Descrivere come avviene il caricamento del firmware di PX4 su una piattaforma.

Il firmware di PX4 viene caricato mediante cross-compilazione, ossia il codice del firmware viene compilato

a partire da file sorgenti su una piattaforma con architettura differente

Dettagli
Publisher
A.A. 2022-2023
38 pagine
SSD Scienze matematiche e informatiche INF/01 Informatica

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher elvisa.kurtaj di informazioni apprese con la frequenza delle lezioni di Sistemi operativi e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Politecnico di Bari o del prof Ruta Michele.