Server Web in modalità kernel: un'ottimizzazione intelligente o un incubo di sicurezza?

Stavo leggendo un thread di Hacker News in cui un utente pubblica un link del 2011 che spiega che IIS è molto più veloce della maggior parte degli altri server (* nix). Un altro utente risponde, spiegando che IIS ottiene questo vantaggio avendo un modulo del kernel chiamato HTTP.sys . Per quanto ne sappia, la maggior parte degli altri server Web popolari nel 2015 non lo fanno.

Non vorrei mai scrivere un server Web in modalità kernel, perché non potrei mai fidarmi di me stesso per renderlo privo di exploit di sicurezza (che sarebbe meno serio in esecuzione in un anello di protezione inferiore).

Dal punto di vista dell'ingegnere del software (al contrario di un cliente per i server Web), l'esecuzione in modalità kernel è una decisione intelligente in termini di prestazioni? È possibile mitigare i problemi di sicurezza nello sviluppo di applicazioni al punto da rendere un server in modalità kernel un utile netto per il consumatore?

— James Mishra
fonte

"Server Fault è un sito di domande e risposte per gli amministratori di sistema e di rete." Gli amministratori di sistema e gli amministratori di rete non scrivono server Web; li installano e li mantengono. Penso che la questione della modalità kernel / modalità utente sia molto più rilevante in fase di sviluppo che in fase di installazione. Non mi dispiace che la domanda venga spostata in un posto più pertinente, ma penso che Server Fault non la troverà nemmeno sull'argomento.

— James Mishra,

Ok, rileggendo di nuovo la domanda, immagino che possa essere interpretata come una domanda generale sull'architettura del software, e non come una domanda sui pro e contro dei server web esistenti, quindi ho ritirato il mio voto ravvicinato. Ma potresti considerare di modificare la tua domanda per evidenziare l'aspetto generale dell'architettura software.

— Doc Brown,

Chiunque pensi che il server Web in modalità kernel possa migliorare le prestazioni in quanto non deve cambiare contesto dovrebbe leggere: I numeri di latenza che ogni programmatore dovrebbe conoscere . Il cambio di contesto completo in Linux costa circa 3000 ns ( sorgente ), ma molte syscall in realtà non necessitano di un cambio di contesto completo e possono arrivare a soli 50 ns, non ho numeri per Windows. Questo è da qualche parte lungo la seconda / terza colonna. Conclusione: minimizzare la richiesta di rete e il disco, non preoccuparsi dei cambi di contesto.

— Sdraiati Ryan il

Risposte:

Http.sys non è tanto un server web quanto un proxy-forwarder. È progettato per consentire la coesistenza di molti server Web su una finestra di Windows, pertanto è possibile avere IIS in esecuzione su un sito Web, ma anche diversi servizi WCF in esecuzione con interfacce HTTP / REST o SOAP, tutti sulla porta standard 80. (Ecco perché non è possibile eseguire Apache su Windows senza un po 'di jiggling, Apache non è stato modificato per funzionare con questo sistema di registrazione, peccato che non sia stato reso più trasparente per le applicazioni e richiede alcune modifiche piuttosto complesse per agganciarlo).

Il modo in cui funziona è che si registra un URL con esso e l'applicazione corrispondente, e quando viene effettuata una richiesta http sulla porta 80, http.sys lo accetta ma quindi passa la richiesta a qualunque applicazione sia registrata per gestire quel target URL.

Dubito che un server web in modalità kernel abbia un senso - anche se le prestazioni del socket possono essere migliorate in questo modo, al fine di eseguire qualsiasi lavoro utile, la logica dell'applicazione verrà comunque eseguita nello spazio utente, quindi c'è sempre una transizione - tu ' l'ho appena spostato un po 'lungo il callstack.

— gbjbaanb
fonte

Il vantaggio principale di un server completo in modalità kernel è nel servire file statici: questo può essere fatto senza passare alla modalità utente. La cache è anche possibile.

— Jules il

Penso che HTTP.sys provenga da un momento in cui i cicli della CPU erano molto più scarsi ... Anche quando si servono piccoli file statici (che è il caso più vantaggioso per HTTP.sys) un server HTTP in modalità completamente utente probabilmente massimizzerebbe la maggior parte delle reti .

— usr

@usr Http.sys è una cosa relativamente nuova, introdotta in Windows Server 2003. Sono abbastanza sicuro che sia lì, quindi puoi eseguire molti servizi API Web ascoltando contemporaneamente sulla porta 80.

— gbjbaanb,

@gbjbaanb un server in modalità utente potrebbe consentire anche quello. Windows ha la capacità di condividere la memoria (per i buffer) e di passare un handle di socket a un processo diverso.

— usr

@JamesMishra Nella mia mente, sì. Allora le CPU probabilmente erano> 10 volte meno potenti. Inoltre, la mentalità di sicurezza non era davvero lì. Oggi è solo una brutta telefonata.

— usr

Http.sys non è l'unico web server in modalità kernel disponibile: sotto Linux c'è anche tux . Come hai correttamente identificato, la sicurezza è un problema con questo tipo di server, che ha portato a non includere tux nel kernel principale di Linux (e credo che non sia aggiornato per le versioni più recenti del kernel).

Una soluzione migliore sarebbe l'uso di un sistema operativo che non si basa sulla protezione dell'hardware per rafforzare la sicurezza dei processi, ad esempio la singolarità di Microsoft: un tale sistema consentirebbe guadagni di efficienza di un server in modalità kernel senza i rischi per la sicurezza. Sfortunatamente, dal 2015 non sono disponibili sistemi operativi pronti per la produzione basati su questo principio e nessuno dei due AFAIK ne sta lavorando seriamente (il progetto Singularity è stato annullato).

— Jules
fonte

Il grosso problema con l'approccio della Singolarità è che significa che un jITter può facilmente portare all'escalation dei privilegi.

— Codici A Caos il

L'articolo di Tux Wikipedia è una lettura interessante. Tux può inoltrare richieste HTTP per contenuti non statici a un server Web "reale" come Apache, che suona come quello per cui viene utilizzato Http.sys. Non so dire se Tux sia stato performante come Http.sys, ma basandomi su quel poco che leggo, sembra che gli sviluppatori del kernel Linux non sarebbero d'accordo con la decisione di Microsoft.

— James Mishra,

Http.sys è a basso rischio, in quanto non può eseguire alcuna copia fornita da una terza parte.

Http.sys svolge alcune attività.

Funziona come proxy-forwarder, consentendo così a più processi di rispondere alla richiesta a diverse parti dello spazio dei nomi HTTP. La risposta di gbjbaanb copre bene questo.
Serve file statici, direttamente dalla cache dei file di Windows. Ciò fornisce una grande velocità per i file statici di file di piccole dimensioni, in quanto non esistono switch di contesto.
Memorizzerà l'output da qualsiasi applicazione a cui inoltra una richiesta HTTP e restituirà il risultato incassato. L'applicazione ha il controllo completo sulla durata (se presente) della cache.

Http.sys è progettato per eseguire le semplici operazioni MOLTO velocemente, mentre passa tutto il resto a un processo nello spazio utente.

In risposta al commento

"a basso rischio, in quanto non può eseguire alcun codice fornito da una terza parte" - Questo è quello che dicono sempre, e non è quasi mai vero.

Il problema è che devi fidarti di Microsoft per scrivere un codice kernel complesso per porre questa domanda, altrimenti decidi di non utilizzare affatto Windows per il web hosting . Http.sys aggiunge pochissimo al rischio di bug del kernel, dato comunque quanto sia complesso il kernel.

Semmai Http.sys riduce il rischio, poiché esiste una separazione così netta al di sotto del servizio web e del codice dell'applicazione "di basso livello".

In una configurazione ben progettata, la macchina (o il server virtuale) che esegue il server Web ha un accesso molto limitato al resto della rete, poiché è un obiettivo ad alto rischio. È molto diverso se il kernel o un server Web in modalità utente viene violato, poiché il server non dovrebbe avere più "diritti" sulla rete, quindi il processo in modalità utente del server Web deve fare il suo lavoro.

— Ian
fonte

Le applicazioni Usermode sono spesso scritte in linguaggi typesafe che escludono la maggior parte dei bug basati sulla corruzione della memoria (questi sono in genere quelli che portano all'esecuzione di codice in modalità remota).

— Codici A Caos il

Non sono sicuro se compro l'argomento secondo cui se mi fido di Microsoft a scrivere il codice del kernel, è un piccolo salto fidarmi di loro per scrivere il codice del server Web in modalità kernel. Sono abbastanza ingenuo dal punto di vista della sicurezza delle informazioni, ma immagino che sarebbe molto più facile armare un overflow del buffer in Http.sys che in un driver di dispositivo o in qualche altra parte del kernel più lontano da Internet.

— James Mishra,