Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
vuoi
o PayPal
tutte le volte che vuoi
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