[Archivio newsletter ^] [Volume 1, Numero 2 >]
Newsletter Systems Internals Volume 1, Numero 1
14 aprile 1999 - In questo numero:
NOVITÀ DI SYSTEMS INTERNALS
- VolumeID per Windows 9x
- EFSDump
- ListDLLs per Compaq Alpha
- "Inside the Boot Process, Part 2"
- Articolo sulla rivista Windows NT di aprile
- Nessun credito dove è dovuto
- Notizie quasi recenti
NOVITÀ DI INTERNALS
- Windows 2000 Driver Verifier
- Test di Y2K con Boot.ini
SVILUPPI FUTURI
- Spinlock in coda in Windows 2000
- Tokenmon
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 prima edizione della newsletter Systems Internals. Sono lieto di annunciare che la newsletter ha già raggiunto i 1000 abbonati da quando è stata annunciata, poco più di una settimana fa.
L'obiettivo della newsletter è quello di fornire informazioni tempestive sulle nuove utilità e sugli articoli pubblicati su Systems Internals, oltre a proporre chicche sui componenti interni di Windows per i quali non esiste un forum appropriato nel sito Web di Systems Internals. In caso di commenti o suggerimenti in merito alla newsletter, è possibile scrivere all'indirizzo mark@.... Invitiamo a inoltrare la newsletter a chiunque potrebbe essere interessato. Le istruzioni per abbonarsi, annullare l'abbonamento o modificarlo sono disponibili nella parte finale della newsletter.
Grazie.
- Mark
NOVITÀ DI SYSTEMS INTERNALS
VOLUMEID PER WINDOWS 9X
Anche se Windows NT e Windows 9x consentono di modificare l'etichetta di un'unità logica o di un disco floppy usando il comando "label", non forniscono alcuno strumento per modificare gli ID volume che assegnano arbitrariamente quando si formattano le unità. Il programma VolumeID, disponibile per Windows NT nel sito System Internals da oltre un anno, è stato appena adattato per Windows 9x. Questa applet consente di modificare gli ID volume di dischi rigidi e dischi floppy nel modo preferito.
VolumeID usa API che consentono alle applicazioni di leggere e scrivere direttamente nelle unità logiche e in Win9x, unità fisiche (dischi floppy), ignorando i file system. In Windows NT/2K VolumeID usa le normali funzioni ReadFile e WriteFile per accedere ai dati delle unità non elaborate. Il trucco sta nel modo in cui specifica il nome del volume a cui vuole accedere. Per sapere come accedere alle unità fisiche o logiche da un'applicazione in Windows NT/2K, consultare l'articolo Q100027 della Microsoft Knowledge Base. Per l'accesso alle unità logiche di Windows 9x, è possibile basarsi sull'esempio di codice fornito nell'articolo Q174569 della Microsoft Knowledge Base. Se è necessario eseguire l'accesso diretto all'unità floppy dalla propria applicazione su Windows 9x, usare l'IOCTL Win32 VWIN32_DIOC_DOS_INT13, documentato in MSDN.
Scaricare VolumeID all'indirizzo http://www.sysinternals.com/misc.htm.
EFSDUMP
Windows 2000 segnerà il debutto della tecnologia di crittografia dei file predefinita di Microsoft, Encrypting File System. Con EFS è disponibile una serie di nuove API per la modifica dei file crittografati, tra cui una, QueryUsersOnEncryptedFile, che consente di vedere quali utenti sono registrati per l'accesso ai file crittografati e quali utenti sono registrati come agenti di ripristino per tali file. Ho scritto un piccolo programma denominato EFSDump che consente di visualizzare facilmente queste informazioni per i file crittografati nel sistema.
A proposito delle API EFS, ci sono diverse nuove API che non sono state documentate in MSDN fino ad aprile, cosa piuttosto preoccupante in questa fase avanzata del ciclo di rilascio di Windows 2000. In particolare, OpenEncryptedFileRaw, ReadFileEncryptedRaw, WriteFileEncryptedRaw e CloseEncryptedFileRaw (tutte vengono esportati dalla ADVAPI32.DLL di Windows 2000) risultano attualmente tutte non documentate. Qualsiasi applicazione che intenda eseguire il backup di file crittografati deve usare queste API, il che significa che o Microsoft sta trasmettendo informazioni su tali API solo a partner selezionati, oppure le aziende produttrici di software di backup dovranno affannarsi per lanciare i loro prodotti quando Microsoft le documenterà pubblicamente. Una cosa è certa: gli sviluppatori del programma NTBACKUP di Windows 2000 hanno già avuto accesso alla documentazione delle API in quanto NTBACKUP di Windows 2000 Beta 3 usa attivamente le API.
Chi è interessato ai componenti interni di EFS può consultare la serie in due parti su EFS che pubblicherò a giugno/luglio nella mia rubrica "NT Internals" su Windows NT Magazine. Nell'articolo descrivo esattamente dove vengono memorizzate le chiavi FEK (File Encryption Keys) e le chiavi EFS degli utenti, come si svolge il processo di crittografia in NTFS, nel driver EFS e in LSASRV (Local Security Authority Subsystem Server) e, naturalmente, come funziona la decrittografia.
Scaricare EFSDump con il codice sorgente completo all'indirizzo http://www.sysinternals.com/misc.htm.
LISTDLLS PER COMPAQ ALPHA
Il numero di utilità disponibili per Alpha in Systems Internals continua ad aumentare. L'ultima novità è ListDLLs, un'utilità da riga di comando che consente di visualizzare le informazioni sulle DLL per i processi in esecuzione. Lo strumento HandleEx consente di visualizzare queste informazioni, oltre a quelle sugli handle (file, processi, thread, oggetti di sincronizzazione) aperti dai processi. HandleEx è però uno strumento dell'interfaccia utente grafica e non risulta sempre comodo, ad esempio non può essere eseguito all'interno di un file batch.
Si è interessati a conoscere il rapporto tra i download della versione x86 della utilità classica Systems Internals e quelli della corrispondente versione per Alpha? È di circa 20:1, il che corrisponde alle stime del settore secondo cui la base di utenti Alpha NT installata è pari al 5% del mercato NT totale.
È possibile scaricare ListDLLs e altre porte Alpha, tra cui HandleEx, all'indirizzo http://www.sysinternals.com/alpha.htm.
"INSIDE THE BOOT PROCESS, PART 2"
Il mio intervento nella rubrica "NT Internals" di gennaio della rivista Windows NT Magazine è ora disponibile online sul sito Web di Windows NT Magazine. Il collegamento a questo documento, così come alla Parte 1 e ai miei interventi precedenti in "NT Internals", è disponibile nella pagina Publications di Systems Internals: http://www.sysinternals.com/publ.htm.
ARTICOLO SULLA RIVISTA WINDOWS NT DI APRILE
Invito anche a dare un'occhiata al mio articolo in evidenza nel numero di aprile di Windows NT Magazine, "Linux and the Enterprise". Svelo alcuni problemi significativi relativi al kernel Linux 2.2 e alle applicazioni per server di rete (applicazioni "enterprise") che, in ultima analisi, impediranno a questa versione del kernel Linux di competere testa a testa con NT e altre varianti di UNIX in termini di prestazioni.
NESSUN CREDITO DOVE È DOVUTO
A questo proposito, forse avrete sentito parlare del recente rapporto di D.H. Brown (una società di analisi) sulle capacità di Linux come sistema operativo aziendale. È emerso che l'autore del rapporto ha attinto pesantemente a un mio messaggio di posta elettronica che qualcuno ha reso pubblico sul newsgroup Usenet del kernel Linux a gennaio. Se si ha accesso al rapporto e si leggono le pagine (44 e 45) in cui si parla di Linux e dei multiprocessori (il rapporto non è disponibile pubblicamente - bisogna acquistarlo per una somma considerevole), e poi si legge la mia e-mail a Deja News, si noterà un immediato parallelismo, fin nei minimi dettagli.
NOTIZIE QUASI RECENTI
Uso questa sezione della newsletter per segnalare le modifiche recenti apportate al sito Systems Internals di cui non si è a conoscenza, e/o per fornire ulteriori informazioni su un'utilità oltre a quelle disponibili sul sito. Ad esempio, un paio di settimane fa abbiamo rilasciato Filemon v4.1. Questa versione di Filemon è in grado di monitorare sia l'attività di named pipe che di mailslot in Windows NT/2K. Le modifiche al codice necessarie per supportare questo aspetto sono di entità relativamente modesta, dal momento che named pipe e mailslot sono implementati come driver del file system. La parte difficile (noiosa) è stata quella di individuare gli IOCTL (comandi di controllo I/O) privati supportati da questi file system speciali, in modo che Filemon possa mostrarli. È possibile scaricare Filemon (che funziona in Windows NT/2K e Windows 9x) all'indirizzo http://www.sysinternals.com/filemon.htm.
Per saperne di più sul funzionamento interno di Filemon, è possibile leggere il mio intervento nella rubrica "NT Internals" della rivista Windows NT di febbraio, intitolato "Inside NT Utilities". L'articolo descrive come usare Filemon, Regmon, NTFSDOS, NewSID e HandleEx e ne spiega il funzionamento.
NOVITÀ DI INTERNALS
WINDOWS 2000 DRIVER VERIFIER
In Windows 2000 Beta 3 viene introdotto un ausilio estremamente efficace per lo sviluppo dei driver di dispositivo, chiamato Driver Verifier. Questo strumento interagisce con il codice del kernel per ottenere il controllo del driver e verificarne l'aderenza alle regole della modalità kernel in modi che in precedenza non erano possibili. I driver di dispositivo difettosi sono di gran lunga il principale responsabile della reputazione di NT come sistema operativo instabile, e questo strumento mira a riparare tale reputazione aiutando gli autori dei driver a trovare i loro bug prima che lo facciano gli utenti.
Diversi tipi di problemi insignificanti possono superare i test di driver casuali (il tipo di test più comunemente eseguito con vincoli stretti di time-to-market) e perfino sfuggire ai test di stress approfonditi. Un tipo di problema comune dei driver è l'accesso alla memoria paginata con un "IRQL elevato" (priorità di interrupt elevata). Se la memoria a cui accede il driver è fisicamente presente al momento dell'accesso (non è stata paginata nel file di paging), l'accesso non autorizzato passerà inosservato. Se si rilascia un driver che viola questa regola nel vasto universo degli utenti, è inevitabile che si manifesti e che si verifichi un arresto anomalo con schermata blu.
Un altro tipo di errore comune nella programmazione dei driver consiste nel fatto che lo sviluppatore scrive il codice presupponendo che la memoria paginata e/o non paginata sia sempre disponibile, ovvero non controlla i valori di ritorno delle allocazioni. Se il pool si esaurisce e il driver riceve un indirizzo di buffer NULL, il driver dereferenzia il sistema e viene visualizzata una schermata blu. Anche se l'esaurimento del pool è un eventualità rara, non è un evento che dovrebbe causare una schermata blu per un amministratore di sistema. Un bug della memoria correlato è il sovraccarico o il sottocarico del buffer, in cui un driver legge o scrive oltre il buffer allocato.
Driver Verifier risolve i problemi di IRQL sostituendo le chiamate a tutte le funzioni che modificano gli IRQL in un driver (ad esempio KeRaiseIrql, KeAcquireSpinLock) con le corrispondenti funzioni del kernel di Verifier (VerifierKeRaiseIrql, VerifierKeAcquireSpinLock) durante il caricamento del driver. Ogni volta che l'IRQL viene impostato su DISPATCH_LEVEL o su un valore superiore, il codice del sistema di verifica richiama MmTrimAllPageableSystemMemory(), una funzione interna di Memory Manager, per forzare l'uscita di tutti i dati paginati dalla memoria fisica. Pertanto, nel momento in cui un driver infrange la regola IRQL di non accedere a dati o codice paginabile da DISPATCH_LEVEL o da un livello superiore, Memory Manager rileva il tentativo di accedere a una pagina non presente e visualizza una schermata blu. Questo consente allo sviluppatore di individuare rapidamente questo tipo di bug prima che il driver esca dalla porta, in quanto può eseguire il debug dell'arresto anomalo e vedere il driver che si trova nello stack degli errori.
Driver Verifier esegue il test dell'uso della memoria applicando una patch alla tabella di importazione del driver da verificare, in modo che il driver richiami le funzioni di memoria di Verifier invece delle versioni standard del kernel. Ad esempio, una chiamata a ExAllocatePool viene sostituita con una chiamata a VerifierAllocatePool. Esistono due tecniche usate da Verifier per aiutare uno sviluppatore a individuare rapidamente bug di memoria. Il primo è che usa uno speciale pool di memoria in cui una pagina di protezione (ovvero una pagina non valida) viene collocata subito dopo la fine del buffer. Inoltre, la parte che precede il buffer nella pagina in cui è allocato il buffer viene riempita con una firma. I sovraccarichi che si trovano all'interno di una pagina oltre la fine di un buffer vengono rilevati immediatamente perché generano errori di pagina non valida nella pagina di protezione. I sottocarichi che comportano modifiche ai dati precedenti a un buffer vengono rilevati da Verifier quando il driver dealloca la memoria, poiché la firma verrà modificata.
I driver che si aspettano sempre un pool non vuoto vengono ingannati da Verifier e generano arresti anomali con l'uso della tecnica della "memory fault injection". È possibile configurare Verifier in modo che faccia fallire in modo casuale le allocazioni di pool di un driver.
Driver Verifier controlla una serie di altri tipi di errore, tra cui la coerenza degli IRP (I/O Request Packet) e la protezione in sola lettura delle pagine di codice del sistema e del driver.
Gli sviluppatori di driver di dispositivo possono fare un favore a se stessi, alla propria azienda e alla comunità NT effettuando i test con Verifier. Si noti che è necessario testare anche i driver NT 4.0 compatibili con Windows 2000 non appena si ha accesso a Driver Verifier (la maggior parte degli sviluppatori lo riceverà con la distribuzione di Windows 2000 Beta 3 in MSDN a fine aprile o maggio).
Per altre informazioni, vedere Driver Verifier.
TEST DI Y2K CON BOOT.INI
Se si visita spesso il sito Web Systems Internals, probabilmente si è già a conoscenza di una nuova opzione di BOOT.INI di Windows 2000 non documentata, /YEAR. Nel sito Web non ho menzionato che l'opzione è supportata anche da NT 4.0 Service Pack 4. Questa opzione consente di effettuare lo spoofing di NT e tutto il software presente in un sistema NT facendo credere che si tratti di un anno diverso. Ad esempio, /YEAR=2001 fa intendere al sistema che si tratti del 2001 anziché del 1999. Pertanto, questa opzione è ideale per verificare la presenza di problemi legati all'anno 2000 a qualsiasi livello di software e il vantaggio di usarla invece di reimpostare manualmente l'orologio del BIOS (tramite l'applet Clock, ad esempio) è che la modifica è temporanea e si attiva solo quando si avvia un'installazione in cui l'opzione è presente nella relativa riga di BOOT.INI. In questo modo è facile creare un'installazione speciale per l'anno 2000 semplicemente prendendo una riga di avvio esistente da BOOT.INI, duplicandola e aggiungendo l'opzione /YEAR.
SVILUPPI FUTURI
La prossima newsletter sarà pubblicata tra qualche settimana. Il suggerimento relativo ai componenti interni che presenterò la prossima volta riguarda gli spinlock in coda, un nuovo tipo di spinlock che Windows 2000 usa per i propri spinlock globali. Ecco i spinlock globali esistenti in Windows 2000:
- KiDispatcherLock: blocco del database dell'utilità di pianificazione
- KiContext-SwapLock: blocco dello swap di thread
- MmPfnLock: blocco del database del frame della pagina fisica
- MmSystemSpaceLock: blocco dello spazio di indirizzi in modalità kernel
- CcMasterSpinLock: spinlock globale di Gestione cache
- CcVacbSpinLock: blocco della matrice di mapping di Gestione cache
Invece di usare i normali spinlock del kernel (KeAcquireSpinLock, KeReleaseSpinLock) per questi blocchi globali, come faceva NT 4.0, il kernel Windows 2000 usa spinlock in coda (KeAcquireQueuedSpinLock, KeReleaseQueuedSpinLock). Questi blocchi hanno alcune proprietà interessanti che riducono al minimo l'attività del bus sui provider di servizi di gestione delle app. La prossima volta spiegherò come vengono implementati gli spinlock in coda.
In arrivo da Systems Internals è Tokenmon, un altro strumento di monitoraggio. Tokenmon mostra informazioni dettagliate su tutte le attività relative ai token presenti nel sistema, compresi accessi, disconnessioni, uso dei privilegi e rappresentazione.
Grazie per aver letto la newsletter Systems Internals.
Pubblicata da ottoh mercoledì 14 aprile 1999 alle 19:16