Archive for May, 2007

Step into Kernel (VmWare+WinDbg)

31 de May de 2007

Agora chega de papinho furado e vamos ao que realmente interessa. Falando sobre Kernel Debugging, já escrevi um post descrevendo os passos necessários para fazer Kernel Debugging com o WinDbg utilizando duas máquinas e um cabo serial. Mas ter duas máquinas dedicadas a essa prática é um luxo que nem todos têm. Assim, em outro post, comentei sobre como instalar e utilizar o SoftIce para depurar drivers em uma única máquina dedicada para o debug. Digo máquina dedicada para debug porquê utilizar sua máquina de desenvolvimento para depurar drivers pode não ser uma das suas melhores idéias. Os mais corajosos e confiantes em seu próprio código ainda se arriscam nessa prática. Bom, eu não posso falar muito, já fiz isso em tempos de vacas magras. De qualquer forma, ainda não fugimos da necessidade de ter duas máquinas para termos um ambiente mínimo de desenvolvimento e teste de drivers. Uma alternativa a esses cenários é a utilização de uma única máquina, mas que tenha memória e CPU suficientes para rodar uma máquina virtual a fim de fazer o debug de Kernel. Neste post vou dar os passos para utilizar uma máquina virtual como cobaia para testar e depurar drivers.

Configurando a máquina virtual

O meio de comunicação natural entre máquinas reais que utilizam o WinDbg para fazer o Kernel Debugging é uma porta serial. Para seguir os mesmos passos, precisamos fazer com que a sua máquina virtual ganhe uma porta serial para fazer esta comunicação possível. Com sua máquina virtual desligada, clique sobre a opção Edit vitual machine settings.


Aparecerá uma janela com a lista dos dispositivos já instalados em sua máquina no tab Hardware. Clique em Add… de forma a adicionar um novo dispositivo e selecione Serial Port na lista de dispositivos que será apresentada na tela a seguir.


Depois de clicar em Next, selecione a opção Output named pipe. Isso fará com que a porta serial na máquina virtual se comunique com a máquina real através de um pipe nomeado. Clicando em OK, serão apresentadas as configurações específicas do pipe nomeado. O nome do pipe será utilizado mais tarde em uma das configurações do WinDbg, então caso você queira utilizar um outro nome que não o sugerido aqui, trate de se lembrar deste mesmo nome mais tarde. Em seguida, mude o valor do segundo combo de forma a indicar que o a outra ponta desta comunicação será uma aplicação, no caso o WinDbg. Depois disso, é só clicar em Finish.


Ao final destas configurações, marque a opção Yield CPU on poll conforme mostra a figura abaixo.

Configurando a máquina TARGET

Feito todo esse “Ziriguidum”, agora teremos que configurar o sistema da máquina TARGET para que ela esteja apta a fazer o Kernel Debugging. Lembre-se que para o Windows que roda dentro da máquina virtual, não existe pipe nomeado, apenas uma porta serial. Se você ainda não sabe o que é uma máquina TARGET nem como configurar uma, então dê um pulo neste post e siga os passos descritos na parte onde uma máquina TARGET é configurada.

Configurando a máquina HOST

Admitindo que sua máquina TARGET já foi configurada, agora teremos que configurar o WinDbg de forma que ele se conecte a uma máquina utilizando o pipe nomeado no lugar de uma porta serial. Para isso, costumo criar um arquivo de batch que contenha a seguinte linha de comando:

start C:\Arquiv~1\Debugg~1\windbg.exe -b -k com:pipe,port=\\.\pipe\com_1,resets=0

Criar um arquivo de batch não é um passo obrigatório, talvez você prefira redigitar tudo na janela Run… a cada vez que o debug for iniciado, mas é tudo uma questão de gosto. Repare que o nome do pipe aparece aqui. Espero que você ainda se lembre daquele nominho que você escolheu.

Conectando…

Agora que temos tudo já configurado, é só conectar e depurar. Nessa história, a máquina virtual é quem cria o pipe nomeado que será aberto pelo WinDbg. Sendo assim se você iniciar o WinDbg com os parâmetros demodntrados antes de iniciar a máquina virtual, você verá a janela abaixo informando que o pipe não foi encontrado.


Por isso a seqüência é primeiro ligar a máquina virtual, selecionar a opção debug no Boot como mostrado abaixo, e somente depois disso é que você deveria inciar o WinDbg com os parâmetros acima descritos.


Quando o WinDbg finalmente conecta na máquina virtual via o pipe nomeado, temos as seguintes mensagens em nosso Command Window dentro do WinDbg.


Daí em diante você já sabe… É pegar os paus mesmo (no bom sentido).

Mais uma vez espero ter ajudado.
Até a próxima. 🙂

Agora ele só fala disso…

21 de May de 2007

As inscrições para o curso de drivers para Windows já começaram a operar nesse final de semana. Por causa de alguns atrasos, o início do curso foi adiado e também já foi confirmado para o dia 23 de junho.

Para ver a lista completa de cursos de extensão oferecidos pela universidade, selecione o ítem “Tecnologia da informação” do menu “Extensão” no site da Universidade.

Para quem curte a criação de Pingüins, o hard coder e amigo William, estará dando um curso de desenvolvimento de drivers para Linux na mesma universidade. Ele também utilizará um dos hardwares de treinamentos da OSR, que aparece na foto acima, para dar a oportunidade de pôr a mão na massa. No caso do curso de Linux, o hardware utilizado será o de USB.

Até mais…

Curso de drivers para Windows

10 de May de 2007

Como alguns de vocês puderam ler em um outro post, fui convidado pela Universidade Gama Filho a ministrar um curso de desenvolvimento em Kernel Mode para Windows. Já foram fechados os detalhes do curso que darei e já estariam produzindo o material para a divulgação, mas enquanto este post era escrito, fui notificado de que ocorreu um atraso na produção deste material e que estaria disponível a partir do dia 21 de maio. Já dei uma olhada no Folder que eles estão produzindo, e pelo que vi, resolveram resumir a descrição do curso que darei. Por esta razão, vou colocar a versão completa da descrição aqui. Segue o arquivo que enviei para a universidade.

Objetivo:
==========
Este curso é destinado aos desenvolvedores ou estudantes que precisam entender
os conceitos fundamentais sobre implementação de drivers para Windows. Este
curso não abordará implementações específicas de drivers, tais como impressoras,
vídeo, SCSI, NDIS, USB, 1394 ou UMDF. O objetivo deste curso é preparar os
alunos que querem entender, testar, complementar ou construir drivers para
Windows empregando os conceitos gerais envolvidos durante o processo.
 
 
Pré-requisitos:
==================
Conhecimento da linguagem C
Básico de API Windows
Básico de Sistemas Operacionais
 
 
Tópicos abordados:
=====================
Visão geral da arquitetura do Sistema
        Processos e Threads     
        Memória Virtual e Paginação
        Kernel Mode x User Mode
        Subsistemas e API nativa
        IoManager
        Pilha de Drivers e Plug-and-Play
        Object Manager
                Terminal Server
        Camada de abstração de Hardware (HAL)
 
Ambiente (obtenção, instalação e utilização)
        Windows Device Driver Kit
        Microsoft Visual Studio Express
        Microsoft Windows Debugging Tools
        Símbolos
 
Escrevendo um Driver
        Escrevendo DriverEntry e DriverUnload
        Compilando o Driver
        Instalando o Driver (Legacy)
                Dependências
                Grupos
                Load Order
        Depurando o Driver
                Instalações Checked Build
                Driver Verifier
                Mapeando imagem para depuração
                Utilizando Máquinas Virtuais
                SoftIce
        Criando DeviceObject
        Symbolic Links
        I/O Request Packets
        IOCTLs e DeviceIoControl
        Implementando Dispatch Routines
                Buffered I/O
                Direct I/O
                Neither I/O
        Objetos, Handles e Ponteiros
        Contexto Arbitrário
        IRQL's, APC's, DPC's e WorkItems
        Sincronismo
                Mutex
                FastMutex
                ERESOURCE
                Spin Lock
        Eventos e Timers
        Filas Personalizadas
 
Interações com Hardware
        Port I/O
        Interrupções e ISR's
        DMA
 
Escrevendo Filtros
        Escrevendo a rotina AddDevice
        Filtros para drivers Legacy
        Repassando IRPs
        Stack Locations
        Completion Routines
        Tratamento de IRPs Pendentes
        Cancelamento de IRPs
        Criando IRPs para outros Drivers
 
Tipos de Drivers
        Legacy drivers
        WDM Drivers
        Minidrivers
        Miniports
        Miniclass
 
Instalações
        Criando um arquivo .INF
        O uso da SetupApi
 
Referências
        Web sites
        Grupos de discussão
        Livros

Até o momento em que este post foi escrito, o atendimento da universidade não estava apto a fornecer detalhes sobre o curso, tais como data de inscrição, conteúdo ou mesmo calendário. Mas posso lhes adiantar o que estou sabendo até agora.

O curso terá duração de 40 horas, sendo distribuídas em 10 aulas de 4 horas cada. As aulas serão dadas aos sábados das 13:00 às 17:00.

O curso está marcado para ter sua primeira turma iniciando dia 26 de maio. Serão necessários no mínimo 5 alunos para formar uma turma, mas pela quantidade de pessoas que já entraram em contato buscando detalhes (mesmo sem divulgação), minha preocupação passa a ser o limite superior de 10 alunos. Resolvemos limitar a turma em 10 alunos para que houvesse um melhor aproveitamento do conteúdo.

Concordo que 40 horas é pouco para aprender tudo que é necessário para desenvolver drivers, mas já será um excelente ponto de partida para ter seu primeiro contato. Se você é do tipo de pessoa que precisa aprender absolutamente tudo para começar a desenvolver, então já vou lhe adiantando que este curso não é para você. Os maiores desenvolvedores de Kernel que eu conheço (de Blog, mas conheço), e que trabalham com isso a anos e anos, dizem que nunca sabem tudo. Para se ter uma idéia, alguns desenvolvedores focam apenas determinados assuntos dentro do Kernel. Um trabalha a 10 anos só com drivers de disco, um outro trabalha a 7 anos somente com drivers de rede. Tony Mason, por exemplo, trabalha a 18 anos só com File System Drivers. Agora pergunta pra eles se eles sabem tudo. E eu que, por uma época, me sentia mal por tentar me focar somente em trabalhos de Kernel e recusava trabalhos em User Mode. As vezes, em rodas de amigos, ouvia comentários de como fazer isso ou aquilo em .Net, e eu viajando na maionese. Eu mal sabia que dentro do assunto Kernel ainda existia uma infinidade de detalhes e especializações. Será possível aprender tudo?

Estou preparando o conteúdo de forma que os alunos possam ter pequenas experiências práticas, tais como escrever e compilar um driver “Hello World”, instalá-los em máquinas virtuais e depurá-los. Não tem jeito, tem que colocar a mão na massa. Conectar duas máquinas reais com um cabo serial e fazer Debug de Kernel. Gerar e analizar Crash Dumps. Penso que temos que tirar o máximo proveito do fato de estarmos juntos em uma sala aula, e realizar algumas experiências que os livros tentam descrever somente com palavras e figuras. É esta vontade de pôr as coisas em prática que contribuíram para que eu adquirisse o kit de treinamento à venda na OSR Online. O kit que estarei levando para o curso, e que aparece na foto acima, é basicamente uma placa PCI de I/O Digital. Meu objetivo é fazer com que drivers de alunos possam controlar este dispositivo.

Bom, à medida que eu for recebendo notícias, irei repassando a vocês.
Até mais.

Este post foi sobre um curso oferecido em um evento isolado. Caso você esteja interessado em treinamentos para desenvolvimento de drivers e software de baixo nível para Windows, dê uma olhada nesta página.

E aí? Deu Boston?

2 de May de 2007

Como comentei em meu último post, participei do seminário de desenvolvimento de drivers File System para Windows promovido pela OSR em Boston. Neste post vou comentar um pouco sobre como foram as coisas por lá.

Para começar, ninguém menos que Tony Mason para dar este seminário que foi muito, mas muito proveitoso. Para quem não conhece, Tony Mason é um dos quatro sócios da OSR. Ele trabalha com drivers a mais de 20 anos, e particularmente com File Systems a partir de 1989. Começou a trabalhar com File Systems para Windows NT em 1993, mas já desenvolvia File Systems para UNIX antes disso. Tony Mason também é a pessoa responsável por revisar e atualizar o conteúdo do livro Windows NT File System Internals escrito por Rajeev Nagar e publicado em 1997. O livro hoje é referência no assunto e sua edição revisada, que ainda não tem data prevista, trará assuntos novos que foram implementados no Windows 2000, XP e Vista. Também comentei um pouco sobre isso neste post.

Podem me chamar de “paga pau”, mas é lindo ver como ele simplesmente sapateia nos detalhes de implementação de File Systems Drivers (FSD) e File Systems Filters (FSF). Adivinha se meu exemplar do livro foi autografada por ele. Agora vou poder guardar esse autógrafo em minha agenda ao lado da embalagem do meu primeiro absorvente. Eu adoraria poder mostrar aqui, mas como temos uma assinatura envolvida, não acho que seria uma boa idéia colocar isso na Internet.

Na turma éramos em quinze alunos, onde doze eram norte-americanos, um romeno, um canadense e um brasileiro. Tive a oportunidade de ser o primeiro brasileiro a fazer este curso na OSR. Haviam pessoas de várias idades. O mais novo tinha aproximadamente 25 anos enquanto que o mais velho tinha os cabelos completamente brancos. Imagino que a idade média da classe ficava perto dos 40 anos. Me conforta a certeza de que nesta área de desenvolvimento, não corremos o risco de ser substituídos pela garotada que acabou de sair da universidade simplesmente por menores preços de mão de obra. Fala a verdade! Quantos programadores de 40 anos você conhece? Eu disse programadores, não gerentes. Pois é, felizmente o desenvolvimento de drivers ainda vai exigir muito arroz com feijão dessa galera.

Pasmem, uma mulher (aproximadamente 43 anos e parecia mulher mesmo!) também fazia parte do grupo. Não é machismo. Vocês sabem o quanto é incomum ver uma mulher (que não parece homem) programando, e programando Kernel ainda por cima. Outro indivíduo desta espécie rara é Molly Brown, programadora responsável pelo NT Cache Manager. Confira aqui.

Como era de se esperar, o ritmo do seminário foi acelerado. Afinal de contas o conteúdo é bem denso. Tivemos uma visão geral de IoManager, memória virtual, multi-thread, multi-processamento e Object Manager só para começar. Esses assuntos ainda fazem parte apenas do sistema operacional e não específicamente de FSD. Começamos a ver o conteúdo de File System própriamente dito lá pela metade do segundo dia. Todo o conteúdo foi muito bem distribuído, e para cada ponto explicado, recebíamos os comentários focando no desenvolvimento de FSD, FSF, e Redirectors. Interessante ver como cada ponto era discutido com direito aos comentários sobre as diferenças de implementação entre as diversas versões do Windows.

Em nosso grupo havia pelo menos uma pessoa que iria desenvolver um Redirector, outra que iria desenvolver um File System, mas o público em geral aprimorava seus conhecimentos para desenvolver anti-virus, anti-malware, controle de acesso e até sistemas de replicação de dados. Todos implementados como FSF.

Replicação de dados? Não seria melhor desenvolver replicação de dados com um filtros de disco? É, eu também acho. A interface de File System é muito mais complexa que a interface de discos, mas vai explicar isso pro fulano lá. Meus sinceros votos de boa sorte a ele.

Vou dizer que o nível da turma era médio. Bom, eu já lí o livro do Rajeev algumas vezes e já tive a oportunidade de trabalhar com FSFs. Eu estava ciente que não ia desperdiçar esta oportunidade de estar lá aprendendo coisas que um livro poderia me ensinar, mas não foi bem assim que uma parte do grupo pensou. Talvez eles foram pensando que seria fácil. Era engraçado quando tínhamos nossos Coffe-Breaks e eles comentavam que o assunto era muito profundo e com muitos detalhes. Sem dúvida que é! Alguns deles nunca tiveram contato com FSD antes. Posso dizer que aproveitou bem o curso quem já teve contato com o assunto e pôde desfrutar dos detalhes de interação entre o FSD e outros componentes do sistema como o Cache Manager, Memory Manager ou mesmo o Lan Manager Server. Teve gente que ficou meio que travando nos comentários de IoMarkIrpPending e Completion Routines. Fala sério! Não que este assunto seja trivial, mas precisava deixar para aprender isso em um seminário de FSD?

Tinha gente muito boa lá também. Perguntas e discussões faziam Tony abrir os fontes do FASTFAT, CDFS ou do RDR para mostrar como as coisas são implementadas no mundo real. E eu achei que era só a referência que considerava fonte de exemplo como parte da documentação. Você já procurou alguma informação sobre IRP_MN_MDL na referência? Bom, consegui encontrar uma pista na parte que fala sobre IRP_MJ_READ, onde eles listam esta entre outras opções e dizem:

“For more information about handling this IRP, study the CDFS and FASTFAT samples that are included in the Windows Driver Kit (WDK).”

Segundo Tony, desenvolver um FSD requer muito conhecimento e experiência, mas ao contrário que muitos pensam, desenvolver filtros é ainda pior. Todos começam com a falsa impressão de que é necessário alterar apenas uma pequena parte do filtro de exemplo do WDK (SFilter) que já estaria tudo bem. Mas um efeito colateral acaba exigindo mais uma alteração aqui, outra alí, e quando se percebe, temos uma complexidade maior que a de um projeto de FSD. Um argumento forte que ele usou foi que quando você implementa um FSD, você sabe de tudo que acontece, mas quando você desenvolve um filtro, você está na interface de duas caixas pretas, o Sistema Operacional e o FSD, e qualquer alteração de comportamento gerada pelo seu filtro pode gerar as mais estranhas, intrigantes e inesperadas situações a serem depuradas em ambas as caixas pretas.

A OSR nos forneceu um fichário com todos os PPT’s utilizados no seminário, também nos deu uma maleta da OSR, uma edição da NT Insider e para a surpresa de alguns, uma mola maluca. Uma mola maluca? Bom, resumidamente é uma mola, só que maluca.

Se quiser saber mais sobre File System Drivers, uma excelente fonte de informação são as listas de discussões da OSR. Vale a pena dar uma olhada. Obviamente vou comentar mais sobre este assunto por aqui.

Até a próxima. 🙂