[Arquivo de Boletins Informativos ^] [< Volume 1, Número 1] [Volume 1, Número 3 >]
O Boletim Informativo do Systems Internals Volume 1, Número 2
15 de maio de 1999 — Nesta edição:
NOVIDADES NOS SISTEMAS INTERNOS
- SDelete
- Atualização do Win2K da Proteção de tela BlueScreen
- "Linux e as Empresas"
- "Dentro de utilitários do NT"
- Coluna My May da Windows NT Magazine
- Coisas não tão novas
NOTÍCIAS INTERNAS
- Os maus modos do dr. GUI
- WinDev '99 East
- Liberação iminente da versão do Numega Driver Works
- DDK beta 3 liberado
- Spinlocks enfileirados do Win2K
O QUE ESTÁ POR VIR
- Protetor de Arquivos do Sistema Win2K (SFP)
PATROCINADOR: WINTERNALS SOFTWARE
O Boletim Informativo de Sistemas Internos é patrocinado pela Winternals Software, na Web em http://www.winternals.com. O Winternals Software é o principal desenvolvedor e provedor de ferramentas de sistemas avançados para Windows NT/2K. Os produtos Winternals Software incluem FAT32 para Windows NT 4.0, ERD Commander (capacidade de disco de inicialização para Windows NT) e NTRecover.
Olá, pessoal.
Bem-vindos à segunda edição do boletim do Systems Internals. Atualmente, o boletim informativo tem 2.700 assinantes, com as assinaturas intensificando.
Desde o último boletim informativo, a Microsoft lançou oficialmente o Windows 2000 Beta 3. O número do build do kernel do Beta 3 é 2031, enquanto que o do kernel de versão inicial do NT 4.0 era 1381 e do NT 3.51 tinha um número de build de 1025. . O que acho estranho (e um pouco irritante) é que a Microsoft incrementa o número de build sempre que faz uma compilação completa do sistema operacional (todos os dias úteis). No entanto, o número de build relatado do kernel reflete o da sua versão pública inicial. Por exemplo, embora o número de build real do kernel do NT 4.0 Service Pack 5 seja muito mais alto do que 1381, o kernel ainda relata 1381 como o número de build.
A versão Beta 3 do Windows 2000 deve ser um toque de atenção para a comunidade de desenvolvedores. A Microsoft anunciou que enviará o Windows 2000 em outubro, e que o Beta 3 representa a versão completa de recursos do que será enviado, para que os desenvolvedores possam começar a criar novos produtos sem medo de que as coisas mudem.
O Windows 2000 vem com uma série de novas APIs, serviços em camadas e aprimoramentos de kernel. Uma alteração que ficará especialmente visível para os desenvolvedores de driver de dispositivo é que a BSOD (Blue Screen of Death) foi alterada. Nas versões anteriores do NT, a BSOD exibia informações de endereço de carga e tempo de link para todos os drivers em um sistema, bem como um despejo da pilha como ela existe no momento da falha. No Windows 2000, apenas o código de parada e as linhas de endereço associadas (linhas de endereço traduzem um ou mais dos parâmetros de código de parada em locais dentro de drivers de dispositivo) são mostrados, juntamente com uma mensagem detalhada. A mensagem de suporte sugere que você verifique suas configurações de BIOS e disco rígido e desabilite o software de desfragmentação e scanners de vírus para tentar evitar a falha novamente. Os Serviços de Suporte determinaram, com base em sua experiência e nos comentários dos clientes, que o BSOD no estilo NT 4 não é útil para determinar a causa de uma falha.
Eu pessoalmente achei a lista de drivers carregados e, em particular, o despejo de pilha, úteis ao obter relatórios de bugs de driver de usuários, é muito mais fácil e mais rápido obter essas informações do que fazer com que os usuários enviem um despejo de memória de vários megabytes. Muitas vezes isolei a causa da falha com base no despejo de pilha e verifiquei as versões do driver que os usuários carregaram com base nas informações de versão exibidas na lista de drivers. Estou curioso para saber o que vocês pensam: vocês gostariam de ver o BSOD no estilo NT 4 levado para o Windows 2000 ou o novo formato de BSOD é suficiente? Enviem-me um email se tiverem uma opinião. Divulgarei os resultados dessa pesquisa informal no próximo boletim informativo. Ainda no assunto dos BSODs, certifiquem-se de verificar a atualização do Windows 2000 da sempre popular Proteção de tela BlueScreen do Sistema Interno, que é abordada nesta edição.
Agradecemos!
-Mark
NOVIDADES NOS SISTEMAS INTERNOS
SDELETE
Como parte do cumprimento do Windows NT 4.0 com os requisitos de classificação de segurança C2, ele implementa a "proteção contra reutilização de objeto". Isso significa que o NT zera recursos de arquivos e memória que os aplicativos alocam ao acessar os recursos pela primeira vez. Isso impede que um aplicativo, por exemplo, crie um arquivo grande e examine seu conteúdo para ver o que foi armazenado anteriormente no disco. No entanto, a proteção contra reutilização de objeto não se aplica à proteção de recursos acessíveis por aplicativos que ignoram APIs relacionadas a recursos padrão ou que ignoram completamente o sistema operacional. Por exemplo, você pode usar um editor de disco, como o DiskProbe do Kit de Recursos, para examinar o conteúdo de partes não alocadas de um disco. Isso permite que você veja dados que pertenciam anteriormente a arquivos excluídos.
Muitos ambientes exigem uma funcionalidade de "exclusão segura". Esse recurso permite que os usuários excluam permanentemente dados confidenciais para que não fiquem visíveis a ferramentas que ignoram as instalações de proteção do sistema operacional. O advento do EFS (Encrypting File System) destacou a necessidade de uma instalação de exclusão segura no Windows 2000. Quando você criptografa um arquivo não criptografado anteriormente, o EFS não apaga o conteúdo das alocações do disco que continham os dados não criptografados do arquivo quando ele as libera. Assim, mesmo que a versão ativa de um arquivo criptografado seja segura, sua versão antiga ainda existe nas partes não alocadas de um disco até que ela seja substituída por novos dados de arquivo que o NTFS atribui a essas partes.
Para preencher essa lacuna, criei o SDelete (Exclusão Segura). É uma ferramenta de linha de comando que possibilita não apenas excluir arquivos padrão com segurança, mas também excluir com segurança todos os dados excluídos anteriormente que existem nas partes não alocadas de um disco. Além disso, ele funciona com arquivos compactados, criptografados e esparsos do Windows NT/2000, que requer o uso da API de desfragmentação. O SDelete segue o padrão de limpeza e higiene do Departamento de Defesa, DOD 5220.22-M, para que você possa ter certeza de que, uma vez que excluídos, esses dados se foram para sempre.
Eu forneço o SDelete com o código-fonte completo e uma descrição de como ele funciona, para que você possa ver como ele faz uso da API de desfragmentação e confirmar minhas afirmações de que isso impedirá que seus dados confidenciais excluídos sejam recuperáveis.
Você pode encontrar a documentação sobre a API de desfragmentação do Windows NT/2000 em http://www.sysinternals.com/defrag.htm. Baixar o SDelete com código-fonte completo em http://www.sysinternals.com/sdelete.htm.
ATUALIZAÇÃO DA PROTEÇÃO DE TELA BLUESCREEN DO WIN2K
As alterações feitas pela Microsoft na tela de inicialização do NT e no layout da BSOD no Windows 2000 fizeram com que a Proteção de tela BlueScreen do Systems Internals exigisse uma atualização importante. Para continuar fornecendo o máximo no realismo de BSOD, liberei a versão 2.0 da proteção de tela. Ela não só reflete as alterações no formato BSOD, mas também imita precisamente a tela de inicialização do Windows 2000, completa com faixa de progresso rotativa e atualizações da barra de progresso. É tão real que a proteção de tela enganará até mesmo usuários e desenvolvedores especialistas do Windows 2000. Claro, no NT 4.0, a Proteção de tela BlueScreen ainda apresenta as telas de inicialização e BSOD.
Como recriei a tela de inicialização do Windows 2000 tão perfeitamente e, ao mesmo tempo, não violei as leis de direitos autorais? Não incluo os gráficos de bitmap de inicialização do Windows 2000 com a proteção de tela. Em vez disso, uso o DirectX para alternar o modo gráfico para o mesmo usado pelo Windows 2000 durante a sequência de inicialização e, em seguida, referencio os recursos de bitmap do arquivo kernel do Windows 2000, ntoskrnl.exe. Esses recursos (você pode visualizá-los abrindo os recursos do ntoskrnl.exe no Visual Studio) são os que o kernel exibe, o que é uma alteração da maneira do Windows 9x de fazer as coisas em que os gráficos de inicialização são, na verdade, arquivos separados. Não parece que os OEMs do computador terão a oportunidade de personalizar a experiência de inicialização no Windows 2000...
Você pode baixar a Proteção de tela BlueScreen em http://www.sysinternals.com/bluescreen.htm. Se você tem uma história bem-humorada relacionada a enganar alguém com a proteção de tela, compartilhe-a.
Você pode descobrir mais informações sobre o "como" e o "porquê" das BSODs na minha coluna NT Internals da Windows NT Magazine de dezembro de 1997, "Dentro da Blue Screen". Um link na página Publicações do Systems Internals, http://www.sysinternals.com/publ.htm, levará você para a versão online dessa coluna. A página também contém links para outras apresentações online de artigos e colunas que escrevi.
"LINUX E AS EMPRESAS"
A enorme resposta da comunidade Linux ao meu artigo na edição de abril da Windows NT Magazine sobre as deficiências de escalabilidade do kernel do Linux levou a revista a postar a versão online do artigo antes do previsto. Você pode encontrar um link para o artigo "Linux e as Empresas" na seção "Artigos" em http://www.sysinternals.com/publ.htm. O artigo descreve várias limitações da versão atual do kernel do Linux (2.2x), incluindo a falta de um mecanismo eficiente de espera de eventos, serialização significativa de chamada do sistema, nenhuma E/S assíncrona e uma implementação ruim da API do soquete do sendfile (no NT é chamado de TransmitFile). A combinação dessas limitações impede o Linux de competir frente a frente com o NT e outros UNIXs, em termos de performance, quanto a aplicativos de classe empresarial, como servidores Web, servidores de banco de dados e servidores de email.
"DENTRO DE UTILITÁRIOS DO NT"
Se você usou Filemon, Regmon ou HandleEx e queria saber mais sobre o que eles lhe dizem e como eles são implementados, terá interesse na minha coluna da Windows NT Magazine de fevereiro, "Dentro dos Utilitários do NT". Esta coluna descreve os elementos internos dessas ferramentas e, para Regmon e Filemon, informa um pouco sobre os códigos de erro e os tipos de solicitação que eles registram durante a captura da atividade do Registro ou do sistema de arquivos. Um link para a versão online deste artigo, que acabou de ficar disponível, está localizado em http://www.sysinternals.com/publ.htm.
COLUNA MY MAY DA WINDOWS NT MAGAZINE
Você já se perguntou como o Windows NT/2000 organiza o conteúdo do Registro na memória ou no disco? A edição atual (maio) da Windows NT Magazine inclui minha coluna, "Dentro do Registro", que fala disso e muito mais. Por exemplo, saiba como o subsistema do modo kernel do Configuration Manager (o subsistema responsável por gerenciar o Registro) procura chaves, armazena dados de valor, otimiza a pesquisa e protege a integridade dos arquivos no disco do Registro. A Windows NT Magazine, http://www.winntmag.com, está disponível na Borders e na Barnes and Nobles.
COISAS NÃO TÃO NOVAS
Pouco depois que o Windows 2000 Beta 2 foi lançado, peguei o build Verificado (depuração) do arquivo de imagem do kernel (ntoskrnl.exe), fiz uma pesquisa de cadeia de caracteres no kernel e criei uma lista dos nomes dos arquivos de origem usados para compilá-lo. O build Verificado do kernel do NT/2000 contém várias instruções Assert (verificações de consistência) que incluem o nome do arquivo no qual o Assert está localizado. Supondo que praticamente todos os arquivos de qualquer significância na origem do kernel terão pelo menos um Assert, a lista é bastante abrangente. Despejar a lista em um script Java me deu uma boa visão de árvore semelhante à do Explorador da estrutura de diretório da árvore de origem do Windows 2000. Confira em http://www.sysinternals.com/nt5src.htm.
NOTÍCIAS INTERNAS
OS MAUS MODOS DO DR. GUI
Na edição de março/abril do Microsoft Developer Network News, o dr. GUI coloca uma pergunta de um leitor que questiona como um driver pode criar afinidade (forçar para usar uma CPU específica) com seus threads. O dr. GUI responde que não há como determinar o número de processadores em um sistema de um driver e que um thread de driver não pode dizer em qual processador ele está sendo executado. Infelizmente, o dr. GUI estragou esse diagnóstico (talvez o ele deva se ater a GUIs).
O kernel do NT (ntoskrnl.exe) exporta uma variável chamada KeNumberProcessors definida no NTDDK.H como:
extern PCCHAR KeNumberProcessors;
Ele pode ser referenciado diretamente em um driver como este:
CHAR i;
for( i = 0; i < *KeNumberProcessors; i++ ) {
// do processor specific stuff
}
Para determinar em qual processador um thread de driver está sendo executado, use KeGetCurrentProcessorNumber(), outra exportação de kernel que não é definida apenas no NTDDK.H, mas na verdade está documentada no DDK!
O dr. GUI prescreveu a medicação errada para esta doença, então eu educadamente avisei-o sobre isso em um email educado. Surpreendentemente, o dr. GUI nunca nem leu o email. Vamos ver se o bom doutor confessa o erro na próxima problema...
WINDEV '99 EAST
A edição East Coast de 1999 da principal conferência para desenvolvedores do Windows está se aproximando rapidamente. A WinDev '99 East acontecerá de 14 a 18 de junho no Boston Cambridge Marriot. Vários grandes nomes do desenvolvimento do Windows vão falar, incluindo Jeff Richter, Jeff Prosise e Don Box. Estarei lá com Jamie Hanrahan e Brian Catlin no tema de drivers de dispositivo. Minhas apresentações incluem um tutorial de um dia sobre os elementos do NT, um sobre como gravar drivers do sistema de arquivos do Windows NT/2K, e outro sobre problemas de desenvolvimento avançado de drivers de dispositivo. Venha e diga olá!
LIBERAÇÃO IMINENTE DO NUMEGA DRIVER WORKS
O Compuware NuMega Labs está prestes a liberar um novo kit avançado de desenvolvimento de driver de dispositivo para Windows 9x/NT/2K, o DriverStudio. O DriverStudio combina todas as ferramentas de driver de dispositivo existentes do NuMega, incluindo DriverAgent, DriverWorks, SoftICE e VtoolsD, e adiciona o novo BoundsChecker para drivers e FieldAgent (somente Windows NT/2K).
A versão para driver de dispositivo do BoundsChecker fornece monitoramento abrangente de cada API de kernel que seu driver usa, e você pode utilizá-la para monitorar as interações do driver com qualquer outro driver de dispositivo no sistema. O FieldAgent permite implantar a versão para driver do BoundsChecker em sistemas do cliente para que os clientes possam coletar rastreamentos que você pode analisar. Em breve, TrueTime para drivers e TrueCoverage para drivers virão como uma atualização gratuita para clientes do DriverStudio. São ferramentas que permitem que você ajuste a performance e teste a cobertura de seus drivers de dispositivo com facilidade.
Esse pacote é o melhor kit de desenvolvimento de driver, e eu recomendo de coração (estou no programa Beta). Descubra mais em http://www.numega.com.
DDK BETA 3 LIBERADO
Em conjunto com a liberação do Windows 2000 Beta 3, a Microsoft disponibilizou para download gratuito o DDK do Windows 2000 Beta 3 (Kit de Driver de Dispositivo). Você pode conseguir o DDK em http://www.microsoft.com/ddk/ddk2kb3.htm. Espero que o SDK venha em breve, pois há várias APIs do Win32 na versão Beta 3 que não estão documentadas na edição de abril do MSDN.
SPINLOCKS ENFILEIRADOS DO WIN2K
O Windows 2000 usa um novo tipo de spinlock chamado "spinlock enfileirado" para seus bloqueios globais. Os bloqueios globais no Windows 2000 são os mesmos do Windows NT 4.0 e incluem:
KiDispatcherLock: o bloqueio do banco de dados do agendadorKiContext-SwapLock: o bloqueio de troca de threadMmPfnLock: o bloqueio de banco de dados de quadro de página físicoMmSystemSpaceLock: o bloqueio de espaço de endereço no modo kernelCcMasterSpinLock: o spinlock global do Gerenciador de CacheCcVacbSpinLock: o bloqueio da matriz de mapeamento do Gerenciador de Cache
Em um uniprocessador, os spinlocks enfileirados funcionam exatamente como spinlocks normais. No entanto, no build multiprocessador do NT, os spinlocks enfileirados são significativamente diferentes. Assim como os spinlocks padrão, os spinlocks enfileirados são implementados no HAL. O kernel chama a função HAL KeAcquireQueuedSpinlock para adquirir um spinlock em fila e invoca KeReleaseQueuedSpinlock para liberar um spinlock em fila. KeAcquireSpinlock e KeReleaseSpinlock, as funções do HAL que o kernel usa para adquirir e liberar spinlocks padrão, exigem o endereço do spinlock especificado como um parâmetro. Por outro lado, as funções de spinlock enfileirado usam o número de índice de um spinlock global. O kernel inicializa os spinlocks globais em uma matriz, em que cada spinlock tem um número de índice predefinido que o kernel usa para identificá-los ao HAL. Portanto, os spinlocks enfileirados não podem ser definidos e usados por drivers de dispositivo, pois não há como aumentar a matriz de spinlock na fila global.
No Windows 2000, cada PCR (região de controle do processador) em um SMP (há uma PCR para cada processador) tem uma matriz com tantas entradas quanto há spinlocks enfileirados. Cada entrada de matriz contém dois campos: um ponteiro para o spinlock enfileirado ao qual ela corresponde (o campo "spinlock") e o campo "fila". Na descrição a seguir, quando me refiro aos campos spinlock e fila, estou falando dos campos associados à entrada de matriz para o spinlock que está sendo adquirido ou liberado.
KeAcquireQueuedSpinlock funciona assim: a função tenta adquirir o spinlock usando a instrução de CPU de troca interligada para posicionar o endereço da PCR do processador atual no spinlock. Se o spinlock for mantido, a função terá, como parte da operação de troca, o endereço do PCR de outro processador. Em seguida, a função se identifica como "aguardando" alternando o bit baixo do campo spinlock em seu próprio PCR. Em seguida, ela coloca o endereço da sua própria PCR no campo de fila da PCR recuperada do spinlock. Por fim, ela aguarda em um loop ocupado até que o bit baixo seja desativado em seu campo spinlock. Quando o bit estiver desativado, o processador atual recebeu o spinlock e, portanto, retorna ao chamador da função de aquisição.
Depois que um processador adquiriu um spinlock enfileirado e terminou o processamento que ele queria fazer enquanto segurava o bloqueio, ele chama KeReleaseQueuedSpinlock. KeReleaseQueuedSpinlock examina o campo de fila do spinlock especificado na PCR do processador atual. Se o campo fila for diferente de zero, outro processador terá "enfileirado" sua PCR lá. KeReleaseQueuedSpinlock limpa o bit baixo do campo spinlock para a PCR em espera e, em seguida, limpa seu próprio campo fila e retorna. Ao limpar o bit baixo no campo spinlock da PCR em espera, ele sinaliza a próxima CPU na linha de que ela pode ter o bloqueio. Se o campo fila for zero, nenhum outro processador aguardará o bloqueio e KeReleaseQueuedSpinlock simplesmente executará uma operação de troca interligada para limpar o spinlock global.
A operação de spinlocks enfileirados é aquela em que os processadores "entram na fila" aguardando um spinlock que está sendo mantido. Cada processador entra na fila informando ao da frente que está aguardando. Isso fornece uma ordem determinística para que os processadores de spinlocks enfileirados adquiram o spinlock na ordem em que o solicitam. Para spinlocks padrão, não há tal ordem. Spinlocks enfileirados têm outra vantagem mais significativa. À medida que um processador gira esperando a limpeza do bit baixo de seu campo spinlock, ele está girando na memória privada de seu próprio processador. Quando um processador ocupado aguarda um spinlock padrão, ele gira no próprio spinlock global, que é compartilhado por todos os processadores. Portanto, os spinlocks enfileirados têm melhores características de barramento multiprocessador porque não há acesso compartilhado à linha de cache durante a espera ocupada. Além disso, devido à natureza de enfileiramento de spinlocks enfileirados, normalmente há menos operações de bloqueio de barramento do que para spinlocks padrão quando um bloqueio está sob contenção de vários processadores.
Spinlocks enfileirados são apenas um dos vários aprimoramentos que a Microsoft fez à escalabilidade de multiprocessamento do Windows 2000.
O QUE ESTÁ POR VIR
O Windows 2000 inclui vários recursos que o tornam mais resiliente a erros de operador e aplicativos com comportamento inadequado. Um deles é que muitas das DLLs e drivers no diretório %systemroot%\system32 e %systemroot%\system32\drivers são protegidas por um watchdog chamado SFP (Protetor de Arquivos do Sistema). Você pode verificar sua existência acessando esse diretório system32 e renomeando como ntoskrnl.exe. O watchdog se ativará e notificará você de que detectou adulteração de um arquivo do sistema protegido e está reparando-o. Se você verificar o diretório novamente, descobrirá que ntoskrnl.exe foi magicamente substituído. Da próxima vez, vou dizer como isso funciona.
Obrigado por ler o Boletim Informativo dos Sistemas Internos.
Publicado no sábado, 15 de maio de 1999 19:15 por ottoh
[Arquivo de Boletins Informativos ^] [< Volume 1, Número 1] [Volume 1, Número 3 >]