Verifica eseguibile in modalità utente

Question

Verifica eseguibile in modalità utente

#1 da (3 voti)
#2 da (1 voti)

3

Sto postando questo qui anziché su Stack Overflow perché è più concettuale. Penso principalmente a questo un contesto Linux, ma questo può essere esteso ad altri sistemi operativi.

Quando non sapevo quello che so ora sui sistemi operativi, ho pensato che la firma delle applicazioni iOS fosse controllata da altri programmi. Stavo pensando a verifiche di integrità in tempo reale, il tipo che si verifica in qualsiasi momento e ogni volta che si accede a una risorsa. La mia ipotesi era che questi programmi "di sistema" potessero negare l'esecuzione di applicazioni con firme non valide, controllare il loro accesso ai file e negare l'accesso a risorse firmate in modo improprio. Ho immaginato che altri controlli di firma del codice su altri sistemi operativi come Windows funzionassero allo stesso modo.

Da allora ho appreso che questi controlli di integrità sui dispositivi iOS hanno luogo nel kernel. Tutte le idee sull'integrità dei file che ho visto finora per i sistemi operativi come Linux e * BSD sfruttano il kernel per eseguire i controlli. È possibile creare un sistema in cui i processi non del kernel potrebbero eseguire il tipo di controlli di integrità che avevo in mente quando sono stato introdotto per la prima volta su iOS? Richiederebbe un design del sistema operativo radicalmente diverso perché funzioni?

operating-systems kernel

posta Melab 24.09.2016 - 05:05

fonte

2 risposte

Leggi altre domande sui tag operating-systems kernel

In OOP quale oggetto è comune aggiornare lo stato di un oggetto quando si lavora con macchine di stato? Come simulare i servizi REST per il test

score 3 · Answer 1

Domanda interessante. Non sono esperto di sistemi operativi, ma ne so un po ', ed ecco i miei due centesimi.

Il filesystem è il componente di un sistema operativo responsabile dell'esecuzione dei controlli di integrità dei file. Nei sistemi con cui ho familiarità, come ZFS, i file vengono sottoposti a checksum, per rilevare e recuperare da errori hardware o software. Sembra che tu ti stia riferendo alla firma di file con una sorta di sistema di chiavi asimmetriche, che è molto più coinvolto, e non ho familiarità con il funzionamento di iOS. Ma immagino che potrebbe essere fatto in userland, ed è fatto nel kernel solo per problemi di prestazioni.

Possiamo suddividere i sistemi operativi in due categorie: kernel monolitici e microkernel. Come suggeriscono i nomi, i kernel monolitici hanno molte più funzionalità incorporate nel kernel (e che quindi viene eseguito in modalità supervisore), mentre i microkernel mettono la minima quantità di funzionalità nel kernel ed eseguono il resto del sistema operativo come processi di userland . Naturalmente, c'è davvero uno spettro tra questi due estremi, ma la terminologia è comune.

Esempi di funzionalità che devono essere eseguite in modalità kernel, e sono quindi contenute in un microkernel, sono la gestione della memoria, la comunicazione tra processi e la programmazione della CPU (sebbene gli scheduler aggiuntivi possano essere scritti come plugin per programmi utente ). Altre funzionalità comunemente presenti nei kernel monolitici, come driver di periferica e file system, possono essere effettivamente eseguite in userland e vengono eseguite in un microkernel.

Quindi per rispondere alla tua domanda: sì, è quasi certamente possibile; ma mi piacerebbe sapere da qualcuno che sa perché iOS ha scelto di implementare questa funzionalità nel kernel (i miei soldi sono sull'efficienza).

score 1 · Answer 2

Un famoso contro-esempio (dove i controlli di integrità avvengono in userland, non nel kernel) è il git sistema di controllo della versione.

È risaputo (e ho visto diversi video discorsi di Linus Torvalds che spiegano) che git esegue molti controlli di integrità e amp; verifiche. Mantiene una firma hash di qualità crittografica per ogni blob e li controlla regolarmente, perché una delle funzionalità necessarie in git è di rilevare anche malfunzionamenti del disco sui dati del repository (all'interno della directory .git nascosta). Linus voleva davvero che git fosse abbastanza affidabile da non inquinare mai i tuoi file di pagamento, anche in caso di guasto dell'hardware.