[Archivio newsletter ^] [< Volume 1, Numero 1] [Volume 1, Numero 3 >]
Newsletter Systems Internals Volume 1, Numero 2
15 maggio 1999 - In questo numero:
NOVITÀ DI SYSTEMS INTERNALS
- SDelete
- Aggiornamento Win2K dello screen saver BlueScreen
- "Linux and the Enterprise"
- "Inside NT Utilities"
- La mia rubrica su Windows NT Magazine di maggio
- Notizie quasi recenti
NOVITÀ DI INTERNALS
- Le brutte maniere del Dr. GUI
- WinDev '99 East
- Rilascio imminente di Numega DriverWorks
- DDK Beta 3 rilasciato
- Spinlock in coda Win2K
SVILUPPI FUTURI
- System File Protector (SFP) Win2K
SPONSOR: WINTERNALS SOFTWARE
La newsletter Systems Internals è sponsorizzata da Winternals Software, presente sul Web all'indirizzo http://www.winternals.com. Winternals Software è il principale sviluppatore e provider di strumenti avanzati di sistemi per Windows NT/2K. I prodotti Winternals Software includono FAT32 per Windows NT 4.0, ERD Commander (funzionalità del disco di avvio per Windows NT) e NTRecover.
Ciao a tutti.
Benvenuti alla seconda edizione della newsletter Systems Internals. La newsletter conta attualmente 2700 iscritti, e le iscrizioni continuano ad andare a gonfie vele.
Dall'ultima newsletter Microsoft ha ufficialmente rilasciato Windows 2000 Beta 3. Il numero di build del kernel Beta 3 è 2031, mentre quello del kernel della versione iniziale di NT 4.0 era 1381 e NT 3.51 aveva un numero di build di 1025. . Ciò che trovo strano (e un po' fastidioso), è che Microsoft incrementa il numero di build ogni volta che crea una build completa del sistema operativo (ogni giorno lavorativo), ma il numero di build del kernel riflette quello della versione pubblica iniziale. Ad esempio, anche se il numero di build effettivo del kernel di NT 4.0 Service Pack 5 è molto superiore a 1381, il kernel indica ancora 1381 come numero di build.
Il rilascio della Beta 3 di Windows 2000 vuole dare la sveglia alla comunità degli sviluppatori. Microsoft ha annunciato che renderà disponibile Windows 2000 a ottobre e che Beta 3 rappresenta la versione completa di ciò che verrà distribuito, quindi gli sviluppatori possano iniziare a scrivere nuovi prodotti senza temere che le cose cambino da un momento all'altro.
Windows 2000 è dotato di nuove API, servizi a più livelli e miglioramenti del kernel. Una modifica che balzerà agli occhi degli sviluppatori di driver per dispositivi è che la schermata blu della morte (BSOD) è cambiata. Nelle versioni precedenti di NT, la BSOD mostrava le informazioni relative al tempo di collegamento e all'indirizzo di caricamento per tutti i driver di un sistema, oltre a un dump dello stack esistente al momento dell'arresto anomalo. In Windows 2000 vengono mostrati solo il codice di arresto e le linee di indirizzo associate (le linee di indirizzo traducono uno o più parametri del codice di arresto in posizioni all'interno dei driver del dispositivo) insieme a un messaggio verboso. Il messaggio di supporto suggerisce di controllare le impostazioni del BIOS e del disco rigido e disabilitare la deframmentazione di software e scanner di virus per provare a evitare un nuovo arresto anomalo. I servizi di supporto Microsoft Premier (PSS) hanno determinato, in base alla loro esperienza e al feedback dei clienti, che la BSOD in stile NT 4 non è utile per determinare la causa di un arresto anomalo.
Personalmente ho trovato utile l'elenco dei driver caricati, e in particolare il dump dello stack, quando gli utenti segnalano i bug dei driver: è molto più facile e veloce ottenere queste informazioni piuttosto che chiedere agli utenti di inviare un dump di arresto anomalo di molti megabyte. Spesso ho isolato la causa dell'arresto anomalo in base al dump dello stack e ho verificato le versioni dei driver che gli utenti hanno caricato in base alle informazioni sulla versione visualizzate nell'elenco dei driver. Sono curioso di sapere cosa ne pensate: vorreste che la BSOD in stile NT 4 fosse disponibile in Windows 2000 oppure il nuovo formato della BSOD è sufficiente? Mandatemi una e-mail se volete esprimere la vostra opinione. Riferirò i risultati di questo sondaggio informale nella prossima newsletter. A proposito di BSOD, date un'occhiata all'aggiornamento per Windows 2000 del sempre popolare screen saver BlueScreen di Systems Internals, di cui si parla in questo numero.
Grazie.
- Mark
NOVITÀ DI SYSTEMS INTERNALS
SDELETE
Nell'ambito della conformità di Windows NT 4.0 ai requisiti della classificazione di sicurezza C2, è stata implementa la "protezione dal riutilizzo degli oggetti". Ciò significa che NT azzera le risorse di file e memoria che le applicazioni allocano quando accedono alle risorse per la prima volta. Questo impedisce a un'applicazione, ad esempio, di creare un file di grandi dimensioni e di esaminarne il contenuto per vedere cosa è stato archiviato in precedenza sul disco. Tuttavia, la protezione dal riutilizzo degli oggetti non si estende alla protezione delle risorse accessibili da applicazioni che aggirano le API standard relative alle risorse o che aggirano completamente il sistema operativo. Ad esempio, è possibile usare un editor di dischi come DiskProbe del Resource Kit, per esaminare il contenuto di parti non allocate di un disco. In questo modo è possibile visualizzare i dati che in precedenza appartenevano ai file eliminati.
Molti ambienti richiedono una funzionalità di eliminazione sicura. Questa funzione consente agli utenti di eliminare in modo permanente i dati sensibili, in modo che non siano visibili dagli strumenti che aggirano le strutture di protezione del sistema operativo. L'avvento di Encrypting File System (EFS) ha evidenziato la necessità di una funzionalità di eliminazione sicura in Windows 2000. Quando si crittografa un file non crittografato in precedenza, EFS non cancella il contenuto delle allocazioni del disco che contengono i dati non crittografati del file quando libera le allocazioni del disco. Quindi, anche se la versione attiva di un file crittografato è sicura, la versione precedente del file esiste ancora nelle parti non allocate di un disco fino a quando non viene sovrascritta da nuovi dati di file assegnati da NTFS a tali parti.
Per colmare questa lacuna, ho scritto SDelete (Secure Delete). Si tratta di uno strumento da riga di comando che consente di eliminare in modo sicuro non solo i file standard, ma anche qualsiasi dato precedentemente eliminato presente nelle parti non allocate di un disco. Funziona anche con i file compressi, crittografati e sparse di Windows NT/2000, un elemento che richiede l'uso dell'API di deframmentazione. SDelete aderisce allo standard di cancellazione e sanificazione DOD 5220.22-M del Dipartimento della Difesa degli Stati Uniti, quindi una volta eliminati, i dati spariscono per sempre.
Fornisco SDelete con il codice sorgente completo e una descrizione del suo funzionamento, in modo che possiate vedere come usa l'API di deframmentazione e possiate verificare che, come affermo, impedisce il recupero dei dati sensibili eliminati.
La documentazione sull'API di deframmentazione per Windows NT/2000 è disponibile all'indirizzo http://www.sysinternals.com/defrag.htm. È possibile scaricare SDelete con il codice sorgente completo all'indirizzo http://www.sysinternals.com/sdelete.htm.
AGGIORNAMENTO WIN2K DELLO SCREEN SAVER BLUESCREEN
Le modifiche apportate da Microsoft alla schermata di avvio di NT e al layout della schermata blu della morte (BSOD) in Windows 2000 hanno reso necessario un importante aggiornamento dello screen saver BlueScreen di Systems Internals. Per continuare a offrire il massimo del realismo della BSOD, ho rilasciato la versione 2.0 dello screen saver. Non solo riflette le modifiche al formato della BSOD, ma imita anche con precisione la schermata di avvio di Windows 2000, con aggiornamenti per indicatore di avanzamento circolare e barra di avanzamento. È così reale che lo screen saver ingannerà anche gli utenti e gli sviluppatori esperti di Windows 2000. In NT 4.0 lo screen saver BlueScreen presenta ancora naturalmente la BSOD e le schermate di avvio di NT 4.0.
Come ho fatto a ricreare la schermata di avvio di Windows 2000 in modo così perfetto e allo stesso tempo a non violare le leggi sul copyright? Non includo la grafica bitmap di avvio di Windows 2000 con lo screen saver. Uso invece DirectX per passare alla modalità grafica usata da Windows 2000 durante la sequenza di avvio e quindi faccio riferimento alle risorse bitmap del file kernel di Windows 2000, ntoskrnl.exe. Queste risorse (visibili aprendo le risorse di ntoskrnl.exe in Visual Studio) sono quelle visualizzate dal kernel e ciò differisce da Windows 9x, in cui gli elementi grafici di avvio sono in realtà file distinti. Non sembra che agli OEM di computer venga data la possibilità di personalizzare l'esperienza di avvio in Windows 2000...
È possibile scaricare lo screen saver BlueScreen all'indirizzo http://www.sysinternals.com/bluescreen.htm. Se avete storie divertenti di qualcuno che è stato ingannato con lo screen saver, raccontatemela.
Altre informazioni sulla BSOD sono disponibili nella mia rubrica NT Internals di Windows NT Magazine di dicembre 1997, "Inside the Blue Screen". Un link nella pagina delle pubblicazioni di Systems Internals, all'indirizzo http://www.sysinternals.com/publ.htm, consente di accedere alla versione online di questa rubrica. La pagina contiene anche dei link ad altre presentazioni online di articoli e rubriche di cui sono autore.
"LINUX AND THE ENTERPRISE"
L'enorme risposta della comunità Linux al mio articolo nel numero di aprile di Windows NT Magazine sulle carenze di scalabilità del kernel Linux ha spinto la rivista ad anticipare la pubblicazione della versione online dell'articolo. È possibile trovare un link all'articolo "Linux and the Enterprise" nella sezione "Articles" all'indirizzo http://www.sysinternals.com/publ.htm. L'articolo descrive diverse limitazioni dell'attuale versione del kernel Linux (2.2x), tra cui la mancanza di un meccanismo efficiente di attesa degli eventi, una serializzazione significativa delle chiamate di sistema, l'assenza di I/O asincrono e una scarsa implementazione dell'API socket sendfile, denominata TransmitFile in NT. La combinazione di queste limitazioni impedisce a Linux di competere testa a testa con NT e altri UNIX, in termini di prestazioni, su applicazioni di classe enterprise come server web, server di database e server di posta elettronica.
"INSIDE NT UTILITIES"
Se avete usato Filemon, Regmon o HandleEx e volete saperne di più sulle loro funzioni e implementazioni, vi invito a leggere il mio articolo "Inside NT Utilities" di Windows NT Magazine di febbraio. Descrive l'interno di questi strumenti e, per Regmon e Filemon, spiega un po' i codici di errore e i tipi di richiesta registrati durante l'acquisizione dell'attività del Registro di sistema o del file system. Il link alla versione online di questo articolo, appena reso disponibile, si trova all'indirizzo http://www.sysinternals.com/publ.htm.
LA MIA RUBRICA SU WINDOWS NT MAGAZINE DI MAGGIO
Vi siete mai chiesti in che modo Windows NT/2000 organizza il contenuto del Registro di sistema in memoria o nel disco? Il numero attuale (maggio) di Windows NT Magazine include la mia rubrica "Inside the Registry", che racconta questo e altro ancora. Ad esempio, informazioni su come il sottosistema in modalità kernel di Configuration Manager (il sottosistema responsabile della gestione del Registro di sistema) cerca le chiavi, archivia i dati dei valori, ottimizza la ricerca e protegge l'integrità dei file del Registro di sistema nel disco. Windows NT Magazine, http://www.winntmag.com, è disponibile presso Borders e Barnes & Nobles.
NOTIZIE QUASI RECENTI
Non molto tempo dopo il rilascio di Windows 2000 Beta 2, ho preso la build verificata (debug) del file immagine del kernel (ntoskrnl.exe), ho eseguito una ricerca di stringhe sul kernel e ho creato un elenco dei nomi dei file di origine usati per compilare il kernel. La build verificata del kernel di NT/2000 contiene numerose istruzioni Assert (controlli di coerenza) che includono il nome file del file in cui si trova l'asserzione. Supponendo che praticamente ogni file di qualsiasi significato nell'origine kernel avrà almeno un'asserzione, l'elenco è abbastanza completo. Il dump dell'elenco in uno script Java mi ha offerto un'utile visualizzazione ad albero simile a Esplora risorse della struttura di directory di origine di Windows 2000. È disponibile all'indirizzo http://www.sysinternals.com/nt5src.htm.
NOVITÀ DI INTERNALS
LE BRUTTE MANIERE DEL DR. GUI
Nel numero di marzo/aprile di Microsoft Developer Network News il Dr. GUI risponde alla domanda di un lettore che chiede come un driver può creare affinità (forzare l'uso di una CPU specifica) per i thread. Il Dr. GUI risponde che non è possibile determinare il numero di processori in un sistema da un driver e che un thread del driver non può indicare il processore su cui è in esecuzione. Purtroppo il Dr. GUI ha sbagliato questa diagnosi (forse farebbe meglio a occuparsi solo di GUI).
Il kernel di NT (ntoskrnl.exe) esporta una variabile denominata KeNumberProcessors definita in NTDDK. H come:
extern PCCHAR KeNumberProcessors;
È possibile farvi riferimento direttamente in un driver simile al seguente:
CHAR i;
for( i = 0; i < *KeNumberProcessors; i++ ) {
// do processor specific stuff
}
Per determinare il processore in cui è in esecuzione un thread di driver, usare KeGetCurrentProcessorNumber(), un'altra esportazione del kernel non solo definita in NTDDK. H, ma addirittura documentata nel DDK!
Il Dr. GUI ha prescritto la medicina sbagliata per questo disturbo, come gli ho fatto educatamente presente per e-mail. Con mia sorpresa, il Dr. GUI non ha mai confermato la ricezione del messaggio. Chissà se il buon dottore ammetterà l'errore nel prossimo numero...
WINDEV '99 EAST
L'edizione 1999 della East Coast della più importante conferenza per sviluppatori Windows si avvicina rapidamente. WinDev '99 East si svolge dal 14 al 18 giugno al Boston Cambridge Marriot. Interverranno molti grandi nomi dello sviluppo di Windows, tra cui Jeff Richter, Jeff Prosise e Don Box. Sarò lì con Jamie Hanrahan e Brian Catlin per i driver di dispositivo. Le mie presentazioni comprendono un'esercitazione di un giorno sugli eventi interni di NT, una sulla scrittura dei driver del file system Windows NT/2K e una su problemi avanzati di sviluppo dei driver di dispositivi. Passate a salutarci!
RILASCIO IMMINENTE DI NUMEGA DRIVERWORKS
Compuware NuMega Labs sta per rilasciare un nuovo e potente kit di sviluppo di driver di dispositivo per Windows 9x/NT/2K, DriverStudio. DriverStudio combina tutti gli strumenti per driver di dispositivo esistenti di NuMega, tra cui DriverAgent, DriverWorks, SoftICE e VtoolsD, e aggiunge il nuovo BoundsChecker per i driver e FieldAgent (solo per Windows NT/2K).
La versione del driver di dispositivo di BoundsChecker offre un monitoraggio completo di ogni API del kernel usata dal driver e può essere usata per monitorare le interazioni del driver con qualsiasi altro driver di dispositivo nel sistema. FieldAgent consente di distribuire la versione del driver di BoundsChecker nei sistemi client in modo che i client possano raccogliere tracce che potranno essere analizzate dall'utente. Prossimamente, come aggiornamento gratuito per i clienti di DriverStudio, arriveranno TrueTime for drivers e TrueCoverage for drivers, strumenti che consentono di ottimizzare facilmente le prestazioni e testare i driver di dispositivo.
Questo pacchetto è un eccellente kit di sviluppo di driver e lo consiglio vivamente. Sto usando il programma Beta. Altre informazioni sono disponibili all'indirizzo http://www.numega.com.
DDK BETA 3 RILASCIATO
In concomitanza con il rilascio di Windows 2000 Beta 3, Microsoft ha reso disponibile per il download gratuito il Windows 2000 Beta 3 DDK (Device Driver Kit). Il DDK è disponibile all'indirizzo http://www.microsoft.com/ddk/ddk2kb3.htm. Spero che l'SDK segua a ruota, poiché ci sono diverse API Win32 nella Beta 3 che non sono documentate nell'edizione di aprile di MSDN.
SPINLOCK IN CODA WIN2K
Windows 2000 usa un nuovo tipo di spinlock denominato "spinlock in coda" per i relativi blocchi globali. I blocchi globali in Windows 2000 sono uguali a quelli di Windows NT 4.0 e includono:
KiDispatcherLock: blocco del database dell'utilità di pianificazioneKiContext-SwapLock: blocco dello swap di threadMmPfnLock: blocco del database del frame della pagina fisicaMmSystemSpaceLock: blocco dello spazio di indirizzi in modalità kernelCcMasterSpinLock: spinlock globale di Gestione cacheCcVacbSpinLock: blocco della matrice di mapping di Gestione cache
In un uniprocessore gli spinlock in coda funzionano esattamente come i normali spinlock. Nella build multiprocessore di NT, tuttavia, gli spinlock in coda sono notevolmente diversi. Come gli spinlock standard, gli spinlock in coda vengono implementati nell'HAL. Il kernel chiama la funzione KeAcquireQueuedSpinlock HAL per acquisire uno spinlock in coda e richiama KeReleaseQueuedSpinlock per rilasciare uno spinlock in coda. KeAcquireSpinlock e KeReleaseSpinlock, le funzioni HAL usate dal kernel per acquisire e rilasciare spinlock standard, richiedono l'indirizzo dello spinlock specificato come parametro. Al contrario, le funzioni di spinlock in coda accettano il numero di indice di uno spinlock globale. Il kernel inizializza gli spinlock globali in una matrice, in cui ogni spinlock ha un numero di indice predefinito usato dal kernel per identificarli nell'HAL. Di conseguenza, gli spinlock in coda non possono essere definiti e usati dai driver di dispositivo, poiché non è possibile aumentare la matrice di spinlock in coda globali.
In Windows 2000 ogni area di controllo del processore (PCR) in un SMP (esiste una PCR per ogni processore) ha una matrice con un numero di voci pari al numero di spinlock in coda. Ogni voce della matrice contiene due campi: un puntatore allo spinlock in coda corrispondente (il campo "spinlock") e il campo "queue". Nella descrizione seguente, quando faccio riferimento ai campi spinlock e queue, parlo dei campi associati alla voce di matrice per lo spinlock acquisito o rilasciato.
KeAcquireQueuedSpinlock funziona così: la funzione prova ad acquisire lo spinlock utilizzando l'istruzione interlocked-exchange della CPU per inserire l'indirizzo della PCR del processore corrente nello spinlock. Se lo spinlock è occupato, la funzione ha, come parte dell'operazione di scambio, l'indirizzo della PCR di un altro processore. La funzione si identifica quindi come "in attesa" attivando il bit basso del campo spinlock nella propria PCR. Successivamente, inserisce il proprio indirizzo PCR nel campo queue della PCR recuperato dallo spinlock. Infine, attende in un ciclo occupato fino a quando il bit basso non viene disattivato nel relativo campo spinlock quando il bit è inattivo e al processore corrente è stato concesso lo spinlock, quindi torna al chiamante della funzione di acquisizione.
Dopo che un processore ha acquisito uno spinlock in coda e ha completato l'elaborazione da eseguire mantenendo il blocco, chiama KeReleaseQueuedSpinlock. KeReleaseQueuedSpinlock esamina il campo queue dello spinlock specificato nella PCR del processore corrente. Se il campo queue è diverso da zero, un altro processore ha "accodato" la PCR. KeReleaseQueuedSpinlock cancella il bit basso del campo spinlock per la PCR in attesa e quindi cancella il proprio campo queue e torna. Cancellando il bit basso nel campo spinlock della PCR in attesa, ha segnalato alla CPU successiva che può avere il blocco. Se il campo queue era zero, nessun altro processore è in attesa del blocco e KeReleaseQueuedSpinlock esegue semplicemente un'operazione interlocked exchange per cancellare lo spinlock globale.
Con gli spinlock in coda i processori "si accodano" in attesa di uno spinlock occupato. Ogni processore si accoda comunicando al precedente che è in attesa. Questo fornisce un ordine deterministico all'acquisizione di uno spinlock in coda. I processori acquisiscono lo spinlock nell'ordine in cui lo richiedono. Per gli spinlock standard non esiste un ordinamento di questo tipo. Gli spinlock in coda hanno un altro vantaggio più significativo. Quando è in attesa che venga cancellato il bit basso del campo spinlock, un processore gira nella memoria privata del proprio processore. Quando un processore attende occupato uno spinlock standard, gira sullo spinlock globale stesso, che è condiviso da tutti i processori. Di conseguenza, gli spinlock in coda hanno migliori caratteristiche del bus multiprocessore perché non è presente l'accesso alla riga di cache condivisa durante l'attesa occupata. Inoltre, a causa della natura di accodamento degli spinlock in coda, in genere sono presenti meno operazioni di blocco del bus rispetto agli spinlock standard quando un blocco è conteso da diversi processori.
Gli spinlock in coda sono uno dei numerosi miglioramenti apportati da Microsoft alla scalabilità multiprocessore di Windows 2000.
SVILUPPI FUTURI
Windows 2000 include numerose caratteristiche che lo rendono più resistente agli errori dell'operatore e alle applicazioni con comportamento anomalo. Una di esse è che molti dei driver e DLL nella directory %systemroot%\system32 e %systemroot%\system32\drivers sono protetti da un watchdog denominato System File Protector (SFP). È possibile verificarne l'esistenza accedendo a tale directory system32 e rinominando ntoskrnl.exe. Il watchdog si attiverà e indicherà che ha rilevato la manomissione di un file di sistema protetto e lo sta riparando. Se si controlla di nuovo la directory si scoprirà che ntoskrnl.exe è stato magicamente ripristinato. La prossima volta vi dirò come funziona.
Grazie per aver letto la newsletter Systems Internals.
Pubblicato sabato 15 maggio 1999 alle 19:15 da ottoh
[Archivio newsletter ^] [< Volume 1, Numero 1] [Volume 1, Numero 3 >]