15 de maio de 1999 - Nesta edição:

  1. O QUE HÁ DE NOVO NOS SISTEMAS INTERNOS

    • Estação SDelete
    • BlueScreen Screen Saver Win2K Update
    • "Linux e a Enterprise"
    • "Inside NT Utilities"
    • Minha Coluna da revista NT Windows de maio
    • Coisas não tão novas
  2. NOTÍCIAS INTERNAS

    • As Más Maneiras de Cabeceira do Dr. GUI
    • WinDev '99 Leste
    • Lançamento de obras de motorista numega iminente
    • Beta 3 DDK lançado
    • Win2K Queued Spinlocks
  3. O QUE ESTÁ POR VIR

    • Win2K System File Protetor (SFP)

PATROCINADOR: SOFTWARE WINTERNALS

A Newsletter Sistemas Internos é patrocinada pela Winternals Software, na Web http://www.winternals.com. Winternals Software é o principal desenvolvedor e fornecedor de ferramentas avançadas de sistemas para Windows NT/2K. Os produtos de Software Winternals incluem FAT32 para Windows NT 4.0, Comandante ERD (capacidade de boot-disk para Windows NT) e NTRecover.

Olá a todos,

Bem-vindos à segunda edição da newsletter Systems Internals. O boletim tem atualmente 2700 subscritores, com as subscrições ainda a decorrerem forte.

Desde a última newsletter que a Microsoft lançou oficialmente Windows 2000 Beta 3. O número de construção do núcleo Beta 3 é 2031, enquanto o do núcleo de lançamento inicial da NT 4.0 foi de 1381 e o NT 3.51 tinha um número de construção de 1025. . O que acho estranho (e um pouco irritante), é que a Microsoft incrementa o número de construção cada vez que faz uma construção completa do sistema operativo (todos os dias de trabalho), no entanto, o número de construção reportado do núcleo reflete o da sua versão pública inicial. Por exemplo, embora o número real de construção do núcleo NT 4.0 Service Pack 5 seja muito superior a 1381, o núcleo ainda relata 1381 como o número de construção.

O lançamento beta 3 de Windows 2000 pretende ser uma chamada de atenção para a comunidade de desenvolvedores. A Microsoft anunciou que irá enviar Windows 2000 em outubro, e que o Beta 3 representa a versão completa do que irá enviar, para que os desenvolvedores possam começar a escrever novos produtos sem receio de que as coisas mudem por baixo dos mesmos.

Windows 2000 vem com uma série de novas APIs, serviços em camadas e melhorias de núcleo. Uma mudança que será especialmente visível para os desenvolvedores do dispositivo é que o Ecrã Azul da Morte (BSOD) mudou. Em versões anteriores do NT, o BSOD apresentou informações sobre o tempo de ligação e o endereço de carga para todos os controladores de um sistema, bem como um despejo da pilha tal como existe no momento do acidente. Em Windows 2000 apenas são mostrados os códigos de paragem e as linhas de endereços associadas (linhas de endereço traduzem um ou mais dos parâmetros do código de paragem em locais dentro dos controladores do dispositivo), juntamente com uma mensagem verbose. A mensagem de suporte sugere que verifique as definições de BIOS e disco rígido e desative software e scanners de vírus para tentar evitar a colisão novamente. O Microsoft Premier Support Services (PSS) determinou, com base na sua experiência e no feedback do cliente, que o BSOD de estilo NT 4 não é útil para determinar a causa de uma falha.

Pessoalmente, achei a lista de motoristas carregada, e em particular a lixeira da pilha, para ser útil quando se obtém relatórios de bugs do condutor dos utilizadores é muito mais fácil e rápido obter esta informação do que ter utilizadores para enviar um depósito de colisão multi-megabyte. Muitas vezes isolei a causa do acidente com base no despejo da pilha, e verifiquei as versões do condutor que os utilizadores carregaram com base nas informações da versão exibidas na lista de condutores. Estou curioso para saber o que pensa: gostaria de ver o BSOD de estilo NT 4 levado para a frente para Windows 2000, ou o novo formato BSOD é suficiente? Envie-me um e-mail se tiver uma opinião. Vou reportar os resultados desta sondagem informal no próximo boletim. Já que estou a falar de BSODs, não se esqueça de verificar a atualização de 2000 Windows da sempre popular Systems Internals BlueScreen Screen Saver, que está abrangida por esta edição.

Obrigado!

- Marca

O QUE HÁ DE NOVO NOS SISTEMAS INTERNOS

SDELETE

Como parte do Windows NT 4.0 que cumpre os requisitos de classificação de segurança C2, implementa "proteção contra a reutilização de objetos". Isto significa que as aplicações de ficheiros e recursos de memória NT zeros alocam quando as aplicações acedem aos recursos pela primeira vez. Isto impede que uma aplicação crie, por exemplo, um grande ficheiro e examine o seu conteúdo para ver o que foi previamente armazenado no disco. No entanto, a proteção contra a reutilização de objetos não permite proteger os recursos acessíveis por aplicações que contornam as APIs padrão relacionadas com os recursos, ou que contornam completamente o sistema operativo. Por exemplo, pode utilizar um editor de discos, como o DiskProbe do Kit de Recursos, para examinar o conteúdo de porções não acotadas de um disco. Isto permite-lhe ver dados que anteriormente pertenciam a ficheiros eliminados.

Muitos ambientes requerem uma capacidade de "excluir segura". Esta funcionalidade permite aos utilizadores eliminar permanentemente dados sensíveis para que não seja visível por ferramentas que contornam as instalações de proteção do sistema operativo. O advento do Sistema de Ficheiros Encriptadores (EFS) salientou a necessidade de uma instalação de exclusão segura em Windows 2000. Quando encripta um ficheiro previamente não encriptado, o EFS não apaga o conteúdo das alocações de discos que continham os dados não encriptados do ficheiro quando liberta as alocações de disco. Assim, mesmo que a versão ativa de um ficheiro que encripta seja segura, a versão antiga do ficheiro ainda existe nas partes não atribuídas de um disco até que seja substituída por novos dados de ficheiros que o NTFS atribui a essas partes.

Para preencher este buraco, escrevi SDelete (Secure Delete). É uma ferramenta de linha de comando que permite não só eliminar ficheiros padrão de forma segura, mas também eliminar de forma segura quaisquer dados previamente eliminados que existam nas porções não afetadas de um disco. Além disso, funciona com Windows ficheiros NT/2000 comprimidos, encriptados e escassos, algo que requer o uso da API desfragmentação. A SDelete adere ao Departamento de Defesa, limpando e higienizando o DOD 5220.22-M, para que possa ter a certeza de que assim que apagar dados, desaparece para sempre.

Dou à SDelete um código fonte completo e uma descrição de como funciona, para que possa ver como faz uso da API desfragmentação, e para que possa verificar as minhas alegações de que evitará que os seus dados sensíveis eliminados sejam recuperáveis.

Você pode encontrar documentação sobre a Windows API de desfragmentação NT/2000 emhttp://www.sysinternals.com/defrag.htm. Descarregue SDelete com código fonte completo em http://www.sysinternals.com/sdelete.htm.

BLUESCREEN SCREEN SAVER WIN2K UPDATE

As alterações que a Microsoft fez ao ecrã de arranque NT e ao layout Blue Screen of Death (BSOD) em Windows 2000 fizeram com que o Systems Internals BlueScreen Screen Saver necessitasse de uma grande atualização. Para continuar a fornecer-lhe o máximo no realismo BSOD, eu languei a versão 2.0 do protetor de ecrã. Não só reflete as alterações ao formato BSOD, como também imita precisamente o ecrã de arranque Windows 2000, completo com a rotação de listras de progresso e atualizações da barra de progresso. É tão real que o protetor de ecrã vai enganar até Windows utilizadores e desenvolvedores especializados de 2000. Claro que, sob o NT 4.0 BlueScreen Screen Saver ainda apresenta o NT 4.0 BSOD e ecrãs de arranque.

Como é que recriei o ecrã de startups Windows 2000 tão perfeitamente e, ao mesmo tempo, não violei as leis de direitos de autor? Não incluo os gráficos de mapas de Windows de 2000 com o protetor de ecrã. Em vez disso, uso o DirectX para mudar o modo gráfico para o mesmo usado por Windows 2000 durante a sequência de arranque, e depois refiro os recursos bitmap do ficheiro de kernel Windows 200, ntoskrnl.exe. Estes recursos (pode vê-los abrindo os recursos de ntoskrnl.exe em Visual Studio) são os que o núcleo exibe, o que é uma mudança da forma Windows 9x de fazer as coisas onde os gráficos de arranque são realmente ficheiros separados. Não parece que os OEMs de computador terão a oportunidade de personalizar a experiência de arranque em Windows 2000...

Você pode baixar o protetor de ecrã BlueScreen em http://www.sysinternals.com/bluescreen.htm. Se tem uma história humorística relacionada com enganar alguém com o protetor de ecrã, por favor, passe-o.

Pode descobrir mais informações sobre os "como" e "Por que dos BSODs" na minha coluna de dezembro de 1997 Windows NT Internals, "Insides", da NT Magazine, "Inside the Blue Screen". Um link na página de Publicações De Sistemas http://www.sysinternals.com/publ.htm Internos, irá levá-lo para a versão on-line dessa coluna. A página também contém links para outras apresentações on-line de artigos e colunas que autorei.

"LINUX AND THE ENTERPRISE"

A enorme resposta da comunidade Linux ao meu artigo na edição de abril da revista NT Windows sobre as deficiências de escalabilidade do kernel Linux levou a revista a publicar a versão on-line do artigo antes do previsto. Pode encontrar um link para o artigo, "Linux and the Enterprise", na secção "Artigos" http://www.sysinternals.com/publ.htm. O artigo descreve várias limitações da atual libertação do kernel Linux (2.2x), incluindo a falta de um mecanismo eficiente de espera de eventos, uma serialização significativa de chamadas de sistema, nenhuma I/O assíncrono, e uma má implementação do ficheiro de envio (em NT a chamada TransmitFile) socket API. A combinação destas limitações impede o Linux de competir frente a frente com NT e outros UNIXs, em termos de desempenho, em aplicações de classe empresarial como servidores web, servidores de base de dados e servidores de e-mail.

"INSIDE NT UTILITIES"

Se usou Filemon, Regmon ou HandleEx, e queria saber mais sobre o que lhe dizem e como são implementados, então estará interessado na minha coluna de fevereiro Windows NT Magazine, "Inside NT Utilities". Esta coluna descreve os internos destas ferramentas, e para o Regmon e o Filemon, diz-lhe um pouco sobre os códigos de erro e os tipos de pedido que registam durante a captura da atividade do registo ou do sistema de ficheiros. Um link para a versão on-line deste artigo, que acaba de ficar disponível, está localizado em http://www.sysinternals.com/publ.htm.

MINHA COLUNA DE REVISTA MAY WINDOWS NT

Já se perguntou como Windows NT/2000 organiza o conteúdo do Registo na memória ou no disco? A atual edição (maio) da revista NT inclui Windows a minha coluna, "Inside the Registry", que lhe diz isso e muito mais. Por exemplo, saiba como o subsistema de modo kernel do Gestor de Configuração (o subsistema responsável pela gestão do Registo) procura chaves, armazena dados de valor, otimiza a procura e protege a integridade dos ficheiros do registo em disco. Windows revista NT, http://www.winntmag.com está disponível na Borders e Barnes and Nobles.

COISAS NÃO TÃO NOVAS

Pouco tempo depois de Windows Beta 2 2000 ter sido lançado, tomei a construção verificada (depurado) do ficheiro de imagem do núcleo (ntoskrnl.exe), fiz uma pesquisa de cordas no núcleo, e inventei uma lista dos nomes dos ficheiros de origem usados para construir o núcleo. A construção verificada do núcleo NT/2000 contém numerosas declarações afirma (verificações de consistência) que incluem o nome do ficheiro do ficheiro no qual o Assert está localizado. Assumindo que praticamente todos os ficheiros de qualquer significado na fonte de kernel terão pelo menos um Assert nele, a lista é bastante abrangente. Despejar a lista num guião de Java deu-me uma boa visão de árvore parecida com o Explorer da estrutura do diretório da árvore de origem Windows 2000. Confira em http://www.sysinternals.com/nt5src.htm.

NOTÍCIAS INTERNAS

DR. AS MÁS MANEIRAS DE CABECEIRA DE GUI

Na edição de março/abril da Microsoft Developer Network News Dr. GUI faz uma pergunta de um leitor que pergunta como um condutor pode afinizar (forçar a usar um CPU específico) os seus fios. O Dr. GUI responde que não há forma de determinar o número de processadores num sistema a partir de um controlador, e que um fio condutor não pode dizer em que processador está a funcionar. Infelizmente, o Dr. GUI estragou este diagnóstico (talvez o Dr. GUI deva cingir-se às GUIs).

O kernel NT (ntoskrnl.exe) exporta uma variável chamada KeNumberProcessors que é definida em NTDDK. H como:

extern PCCHAR KeNumberProcessors;

Pode ser referenciado diretamente num motorista como este:

CHAR    i;

for( i = 0; i < *KeNumberProcessors; i++ ) {

    // do processor specific stuff
}

Para determinar em que processador está a funcionar uma linha de condutor, utilize o KeGetCurrentProcessorNumber(), outra exportação de núcleo que não é apenas definida em NTDDK. H, mas está documentado no DDK!

O Dr. GUI receitou a medicação errada para esta doença, por isso, informei educadamente o Dr. através de um e-mail educado. Surpreendentemente, o Dr. GUI nunca reconheceu o e-mail. Vamos ver se o bom Dr.

WINDEV '99 LESTE

A edição de 1999 da Costa Leste da principal conferência para Windows desenvolvedores está a aproximar-se rapidamente. WinDev '99 East está a decorrer de 14 a 18 de junho no Boston Cambridge Marriot. Vários grandes nomes Windows desenvolvimento estão a falar, incluindo Jeff Richter, Jeff Prosise e Don Box. Estarei lá com Jamie Hanrahan e Brian Catlin na pista do condutor do dispositivo. As minhas apresentações incluem um tutorial de um dia sobre os internos da NT, bem como um sobre a escrita Windows controladores de sistema de ficheiros NT/2K e um sobre problemas avançados de desenvolvimento do condutor de dispositivos. Venha cumprimentá-lo!

CONDUTOR DA NUMEGA TRABALHA LANÇAMENTO IMINENTE

A Compuware NuMega Labs está prestes a lançar um poderoso novo Windows kit de desenvolvimento de dispositivos 9x/NT/2K, DriverStudio. DriverStudio combina todas as ferramentas de controlador de dispositivos existentes da NuMega, incluindo DriverAgent, DriverWorks, SoftICE e VtoolsD, e adiciona o novo BoundsChecker para condutores e FieldAgent (apenas Windows NT/2K).

A versão do controlador do dispositivo boundsChecker fornece uma monitorização abrangente de cada kernel API que o seu condutor utiliza, e pode usá-lo para monitorizar as interações do seu condutor com qualquer outro controlador de dispositivo no sistema. O FieldAgent permite-lhe implementar a versão do controlador do BoundsChecker para os sistemas de clientes para que os clientes possam recolher vestígios para si que possa analisar. Logo que uma atualização gratuita para clientes DriverStudio é TrueTime para condutores, e TrueCoverage para condutores, ferramentas que lhe permitem facilmente afinar e a cobertura testar os controladores do dispositivo.

Este pacote é o melhor kit de desenvolvimento de condutores, e recomendo-o vivamente (estou no programa Beta). Saiba mais em http://www.numega.com.

BETA 3 DDK LANÇADO

Em conjunto com o lançamento do Windows Beta 3 de 2000, a Microsoft disponibilizou gratuitamente o Windows 2000 Beta 3 DDK (Device Driver Kit). Você pode pegar o DDK em http://www.microsoft.com/ddk/ddk2kb3.htm. Espero que o SDK o siga em breve, uma vez que há uma série de APIs Win32 na Beta 3 que não estão documentados a partir da edição de abril da MSDN.

WIN2K QUEOU SPINLOCKS

Windows 2000 usa um novo tipo de spinlock chamado "spinlock" para as suas fechaduras globais. Os bloqueios globais em Windows 2000 são os mesmos que os Windows NT 4.0, e incluem:

  • KiDispatcherLock: o bloqueio da base de dados do programador
  • KiContext-SwapLock: o bloqueio de troca de piso
  • MmPfnLock: o bloqueio físico da base de dados de quadros
  • MmSystemSpaceLock: a fechadura espacial do endereço do modo kernel
  • CcMasterSpinLock: o spinlock global do Gestor de Cache
  • CcVacbSpinLock: a fechadura de mapeamento-matriz do Gestor cache

Num uniprocessador, os spinlocks funcionam exatamente como os spinlocks normais. No multiprocessador de NT, no entanto, os spinlocks em fila são significativamente diferentes. Tal como os spinlocks padrão, os spinlocks em fila são implementados no HAL. O núcleo chama a função HAL KeAcquireQueuedSpinlock para adquirir um spinlock em fila, e invoca KeReleaseQueuedSpinlock para libertar um spinlock em fila. KeAcquireSpinlock e, KeReleaseSpinlock as funções HAL que o núcleo utiliza para adquirir e soltar spinlocks padrão, requerem o endereço da centrifugação especificada como parâmetro. Em contraste, as funções de spinlock em fila tomam o número de índice de uma centela global. O núcleo inicializa as centrifugações globais numa matriz, onde cada spinlock tem um número de índice predefinido que o núcleo usa para identificá-los ao HAL. Assim, os spinlocks em fila não podem ser definidos e utilizados pelos controladores do dispositivo, uma vez que não existe forma de aumentar a matriz global de eixos em fila.

Em Windows 2000, cada região de controlo de processadores (PCR) num SMP (há um PCR para cada processador) tem uma matriz com tantas entradas nele como existem spinlocks em fila. Cada entrada de matriz contém dois campos: um ponteiro para a centela da fila que corresponde ao campo "spinlock" e o campo "fila". Na seguinte descrição, quando me refiro aos campos de espii, estou a falar dos campos associados à entrada de matriz para o spinlock que está a ser adquirido ou libertado.

KeAcquireQueuedSpinlock funciona assim: a função tenta adquirir o spinlock utilizando a instrução cpu de troca interligada para colocar o endereço do PCR do atual processador no spinlock. Se o spinlock for mantido, a função tem, como parte da operação de troca, o endereço do PCR de outro processador. Em seguida, a função identifica-se como "esperando" toggling a parte baixa do campo de centrifugação no seu próprio PCR. Em seguida, coloca o seu próprio endereço pcr no campo de fila do PCR que recuperou do spinlock. Por fim, aguarda em ciclo movimentado até que a parte baixa seja desligada no seu campo de centrifugação quando a broca estiver desligada, então o processador atual foi concedido o spinlock e, por isso, volta a ligar a função de adquirente.

Depois de um processador ter adquirido um spinlock em fila e ter terminado o processamento que queria fazer enquanto segurava o cadeado, KeReleaseQueuedSpinlock chama. KeReleaseQueuedSpinlock olha para o campo de fila para a spinlock especificada no PCR do processador atual. Se o campo de fila não for zero, então outro processador "fez fila" no seu PCR. KeReleaseQueuedSpinlock limpa a parte baixa do campo de centrifugação para o PCR de espera, e, em seguida, limpa o seu próprio campo de fila e retorna. Ao limpar a parte baixa no campo de giro do PCR de espera, acaba de sinalizar o próximo CPU na linha que pode ter a fechadura. Se o campo de fila era zero, então nenhum outro processador está à espera da fechadura e KeReleaseQueuedSpinlock simplesmente executa uma operação de troca interligada para limpar o spinlock global.

O funcionamento dos spinlocks em fila é aquele em que os processadores "alinham-"à espera de um spinlock que é mantido. Cada processador faz fila dizendo ao outro que está à sua frente na fila que está à espera. Isto fornece uma ordem determinística para a aquisição de um processador de spinlock em fila adquire o spinlock na ordem que eles solicitam. Para os spinlocks padrão não existe tal encomenda. Os spinlocks em fila têm outra vantagem mais significativa. À medida que um processador gira à espera que o seu campo de centrifugação tenha a parte baixa limpa, está a girar na memória privada para o seu próprio processador. Quando um processador ocupado espera por uma spinlock padrão, gira na própria spinlock global, que é partilhada por todos os processadores. Assim, os spinlocks em fila têm melhores características de autocarro multiprocessador porque não há acesso à linha de cache partilhada durante a espera ocupada. Além disso, devido à natureza da fila de spinlocks em fila, existem normalmente menos operações de bloqueio de autocarros do que para spinlocks padrão quando um bloqueio está sob contenção de vários processadores.

Os spinlocks em fila são uma das várias melhorias que a Microsoft fez da escalabilidade multiprocessável de Windows 2000.

O QUE ESTÁ POR VIR

Windows 2000 inclui numerosas funcionalidades que o tornam mais resistente aos erros do operador e aplicações mal comportadas. Um deles é que muitos dos DLLs e condutores sob o %systemroot%\system32 diretório e %systemroot%\system32\drivers diretório estão protegidos por um cão de guarda chamado Protetor de Ficheiros do Sistema (SFP). Pode verificar a sua existência entrando nesse system32 diretório e renomeando ntoskrnl.exe . O cão de guarda irá acordar e notificá-lo que detetou adulteração com um ficheiro de sistema protegido e está a repará-lo. Se verificar o diretório de novo, verá que ntoskrnl.exe foi substituído magicamente. Da próxima vez, digo-te como isto funciona.


Obrigado por ler a Newsletter Sistemas Internos.

Publicado sábado, 15 de maio de 1999 1999 19:15 pm by ottoh

[Newsletters Archive ^][ Volume 1, Número 1][Volume 1, Número 3 ]

[Newsletters Archive ^][ Volume 1, Número 1][Volume 1, Número 3 ]

A Newsletter Sistemas Internas Volume 1, Número 2

http://www.sysinternals.com