Step into Kernel (Firewire)
Já sei! Seu computador de teste não tem porta serial e você precisa fazer debug de Kernel nele. Creio que depois da porta serial, a maneira mais utilizada para depurar o Kernel do Windows seja utilizando uma interface firewire. Ainda existe a opção de se fazer o debug de Kernel utilizando USB 2.0, mas isso ainda é para poucos, já que além de apenas ser suportado pelo Windows Vista, ainda é necessário ter um cabo especial. Os detalhes sobre debug de Kernel pela porta USB podem ser encontrados neste post. Hoje a história é outra.
Mas eu não tenho porta firewire
Larga a mão de ser chorão. O que importa aqui não é o fato de você ter ou não uma porta firewire em seu micro de desenvolvimento, mas sim o fato da máquina do cliente ter uma porta firewire. Você sabe muito bem que pela Lei de Murphy, aquele problema que você nem sabia que existia só acontece naquela máquina que não tem portas seriais. Então melhor você estar preparado para encontrar esse tipo de coisa. Elas realmente acontecem. Sua reclamação poderia ainda ser diferente: "Mas eu não tenho porta serial". Alguns notebooks que não possuem portas seriais oferecem portas firewire, mas idependente disso, existem placas tanto PCI quanto PCMCIA capazes que disponibilizar a interface IEEE 1394. Desta forma, seja sua máquina um desktop ou um notebook, existem meios delas ganharem portas firewire.
Configurando o lado TARGET
Se você ainda não sabe o que significa lado HOST/TARGET e está completamente perdido sobre o assunto, leia este post introdutório antes de continuar. Configurar o lado TARGET não é muito diferente do que já vimos em outros posts desta série. Podemos editar o aquivo boot.ini, como já vimos neste post para adicionar as seguintes configurações de debug. [boot loader]
timeout=10
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)<<...>>/fastdetect /debugport=1394 /channel=44
multi(0)disk(0)<<...>>/fastdetect O número do canal a ser utilizado pode ser qualquer um, mas o valor deve ser o mesmo em ambos os lados TARGET e HOST. Caso você esteja querendo depurar um Windows Vista, o método de configurar as mesmas coisas mudaram um pouco como vimos neste outro post. A figura a seguir mostra os passos para setar o modo de configuração do sistema para interface IEEE 1394. Lembre-se que aqui estamos apenas configurando a maneira com a qual o sistema seria depurado caso exista uma entrada de debug na lista de boot da máquina. Este post mostra os detalhes de como criar uma entrada adicional nesta lista e configurá-la para debug.
Só isso? Nem doeu!
 Para se fazer Kernel Debug utilizando um cabo firewire, ambos os micros devem estar rodando Windows XP ou superior, não necessariamente a mesma versão em ambos os lados. Existe uma particularidade quanto utilizar sistemas anteriores ao Windows XP SP2 ou Windows 2003 Server sem service pack no lado TARGET da história, conforme informa esta página. Para estes sistemas, deve-se desabilitar a controladora do barramento 1394. Isso é necessário porque o Windows, que está sendo depurado inconscientemente, pode querer tentar conversar com a interface Firewire durante o debug, e isso pode fazer com que a conexão com o depurador caia. Para desabilitar essa interface nos sistemas acima citados, você deve simplesmente selecionar o ítem "Disable" no menu de contexto que aparece quando você clica com o botão direito do mouse sobre a controladora firewire. Posso desabilitar a controladora Firewire independente da versão do Windows? Não, se você desabilitar a controladora em sistemas posteriores aos acima citados, você poderá não conseguir depurar o sistema quando ele mudar entre os estados de energia do sistema. Estados de energia? Você está falando da aura do computador? Supondo que você está querendo depurar seu driver durante as transições energia do sistema que são gerenciadas pelo Power Manager. O Power Manager determina qual barramento pode ser desligado para economizar energia. Assim, o sistema pode decidir desligar a interface firewire durante seu debug de um driver qualquer, e dessa forma, você não vai conseguir acompanhar as IRPs de gerenciamento de energia chegando ao seu driver.
Configurando o lado HOST
Normalmente, para fazer iniciar uma sessão de debug do lado HOST, basta abrir o WinDbg, selecionar o ítem "Kernel Debug..." do menu File, clicar na aba 1394, preencher o número do canal que se deseja utilizar, clicar OK como mostra a figura abaixo e correr para o abraço.
Tudo isso que acabei de descrever continua valendo, mas para que seja possível utilizar firewire do lado HOST, o WinDbg precisa instalar os drivers virtuais de acesso ao barramento IEEE 1394, como mostra nesta página. O WinDbg faz isso automagicamente quando você seleciona as opções acima, mas os drivers só poderão ser instalados se você estiver logado como administrador do sistema. Caso contrário você receberá a seguinte mensagem.  Pô Fernando, sou desenvolvedor de driver! Você acha mesmo que não sou administrador da minha máquina? Tudo bem, você pode até ser, mas mesmo sendo um administrador no Windows Vista você precisará executar o WinDbg clicando com o botão direito do mouse sobre o ícone do WinDbg e selecionar o ítem "Run as Administrator". Aí sim, você repete o procedimento descrito acima para que os drivers virtuais sejam instalados. Esse procedimento é necessário somente na primeira vêz que você utiliza a porta firewire para debug, nas próximas vezes, os drivers já estarão instalados. Para quem estiver utilizando um sistema anterior ao Vista e já estiver utilizando uma conta admininstrativa, é como meu amigo Thiago diz: "Sai na urina". Ou seja, o driver virtual será instalado e você terá a saída como mostra a figura abaixo, que demonstra as mesmas operações realizadas no Windows Vista rodando o WinDbg como Administrador. Daí em diante é só debug mesmo.
Dump Racing
Aproveitando que estamos todos aqui reunidos, vamos fazer um teste e verificar se a velocidade do firewire ajuda mesmo com relacão à fazer Kernel Debug. Vamos imaginar a situação onde você esteja em visita a um cliente onde obviamente seu driver não está funcionando adequadamente. Lembra daquele bug que você nem sabia que existia? Pois bem, se trata de um deadlock. Deadlock são especialmente queridos na hora de fazer debug, porque você está lá quando o problema acontece, mas tela azul que é bom nada. Nessa situação, você pode gerar um arquivo de dump da máquina e deixar para analizar o problema em casa, afinal de contas, roupa suja se lava em casa, e assim poder liberar a máquina do cliente para uso, já que normalmente nessas situações, ficam umas três pessoas em cima de você perguntando "E aí? Descobriu o problema?" a cada 3 minutos. Configurei meu desktop aqui de casa para fazer debug do Windows Vista por uma porta serial. Esta máquina tem 2GB de memória RAM. Um arquivo de dump full é uma cópia de tudo que esta na memória do computador naquele instante, por isso, nada mais justo que este arquivo tenha aproximadamente 2GB de tamanho. Este arquivo pode ser gerado na máquina HOST durante uma sessão de debug utilizando o comando .dump. Segue abaixo a saída deste comando quando utilizado sobre uma conexão serial. 0: kd> .dump /f c:\Temp\SERIAL.DMP
Creating a full kernel dump over the COM port is a VERY VERY slow operation.
This command may take many HOURS to complete. Ctrl-C if you want to terminate the command.
Creating c:\Temp\SERIAL.DMP - Full kernel dump
Percent written 0
Percent written 1
Percent written 2
:
:Vocês repararam na mensagem ameaçadora que nos foi exibida? Particularmente penso que estes engenheiros de software são todos uns desesperados, provavelmente por causa quantidade de café que eles consomem por dia. Já posso até imaginar quantos nem esperam o dump começar para já pressionar CTRL+C e interromper o processo. São uns covardes mesmo. Bom, já que isso vai me custar algum tempo, vou aproveitar para dar uma mijada. Muito, mas muito tempo mesmo depois... :
:
Percent written 97
Percent written 98
Percent written 99
Dump successfully written
0: kd>OK, tudo bem até aqui. Agora vamos repetir o processo em uma sessão de debug utilizando o cabo firewire. A mesma máquina com a mesma quantidade de memória e até o mesmo comando. 1: kd> .dump /f c:\Temp\FIREWIRE.DMP
Creating c:\Temp\FIREWIRE.DMP - Full kernel dump
Percent written 0
Percent written 5
Percent written 10
:
:
Percent written 90
Percent written 95
Dump successfully written
1: kd>Tá, tudo bem, a contagem vai de cinco em cinco ao invés de um em um como foi com o cabo serial, grande coisa. Não é a toa que demore mais pela porta serial, eles gastam processamento com tudo. Agora podemos comparar as datas de criação e modificação nos atributos de cada arquivo para poder determinar quanto tempo levou para poder gerá-los.
Lembrando que o mês de junho termina no dia 30, podemos concluir que o dump pela porta serial levou aproximadamente 2 dias, 5 horas e 12 minutos. É uma pena essa janela não mostrar os segundos para termos mais precisão aqui. De qualquer forma, lembrando também que cada minuto tem 60 segundos, o mesmo dump gerado pela porta firewire levou aproximadamente 7 minutos. Nossa, foi quase! Se não fosse por essa pequena vantagem de 3187 minutos. Até mais...
A matéria mais difícil
 Como alguns de vocês já estão cansados de saber, estou cursando o quinto ano de Engenharia da Computação. No começo do curso, naturalmente pastei para poder aprender Cálculo, Álgebra, Física e aquelas outras matérias que tiram fumacinha da calculadora. Como não pude sair do meu colegial técnico e ir direto para uma universidade, trabalhei um pouco na área até eu conseguir pagar a mensalidade de uma faculdade. Estagiário ganha pouco mesmo. Esse tempo, além de me trazer uma graninha extra por mês, também me trouxe um cadim de experiência. Não foi muita, mas o suficiente para identificar possíveis deslises de professores durante as aulas de programação. O curso de Engenharia da Computação tem duração de seis anos, e durante esse tempo eu ainda tinha que trabalhar, mesmo porque eu tinha que pagar a faculdade. Durante esse tempo acabei lendo um livro ou dois, ou três, quatro, cinco, enfim, alguns. É natural os professores tenderem a não explicar exatamente como as coisas são ou funcionam, e assim, ganhar um pouco de tempo para poder abordar mais assuntos com menos detalhes. Afinal, você não aprende tudo o que precisa na universidade, mas você já consegue ter uma boa noção de onde você está se enfiando quando for trabalhar na área e por onde começar a buscar mais detalhes sobre determinado assunto. Eu mesmo, nos cursos de drivers que já dei, tento explicar o essencial, o que o aluno vai mesmo utilizar, mas sempre tento deixar claro que existem detalhes a serem vistos. Durante o curso, eu mal podia esperar para ver as matérias técnicas, que me abririam os olhos para uma nova maneira de ver os dispositivos eletrônicos, circuitos integrados e os computadores. Depois de engolir algumas atravessadas de professores de Linguagem C e de Engenharia se Software, finalmente comecei a estudar algo realmente interessante. A matéria de Sistemas Operacionais é mesmo surpreendente. Nela estudamos diferentes sistemas operacionais que rodam sobre diferentes arquiteturas de computadores. Ufa! Pelo menos uma arquitetura e um sistema operacional eu conheço razoavelmente bem. Tudo bem o professor dizer que Thread e Processo é a mesma coisa, explicar Inter Process Communication sem nem tocar no assunto Memória Virtual e Marshaling, mas foi show tentar engolir a explicação sobre Sincronismo e Gerenciamento de Interrupções dos sistemas operacionais. Tudo bem, eu só posso dizer que o professor escorregou em Windows, eu não conheço todos os outros Sistemas Operacionais. Acho que ele só escolheu o sistema operacional errado na hora de dar um exemplo infeliz. Não me lembro das palavras exatas, mas meu professor nos ensinou que o Windows XP ainda não é um sistema operacional preemptivo, e que as chamadas ao sistema operacional não podiam acontecer concorrentemente. Primeiro uma, depois a outra e assim por diante. Particularmente acho que ele deve ter confundido XP com 9X. Afinal os dois possuem a letra X. Nessa hora eu tive que parar de ler o livro que eu estava lendo e pedir para ele repetir aquilo. Eu poderia ter ouvido errado, mas infelizmente não foi isso que aconteceu. Ele disse aquilo mesmo. Mais tarde na mesma aula ele nos disse que o Windows XP ainda não consegue gerenciar interrupções adequadamente, que se uma interrupção ocorre enquanto um processo está rodando, o sistema normalmente espera o processo inteiro terminar para que só depois ele possa atender à uma interrupção.  Como em toda sala de aula universitária, sempre existe um grupinho de alunos que odeiam o Windows e defendem uma outra opção de Sistema Operacional. Nada contra eles, nem contra a opção deles, mas de vêz em quando me aparece cada figura que é um caso sério. Enfim, estes logo disseram ironicamente aos risos: "É lógico! Porque é o mais inteligente a se fazer". Assim todos na sala começaram a rir desse péssimo exemplo de gerenciamento de interrupções do Windows. Eu nunca falo nada, sou aquele cara que chega uns 30 minutos mais cedo na sala pra poder ler meu livro em paz. Não saio fazendo campanha a favor do Windows nem contra outros sistemas. Não fico explicando como completar uma IRP para cada pessoa que encontro no café, mas essa eu não podia deixar passar em branco. Perguntei ao professor: "Nossa, que interessante isso! Onde foi mesmo que o senhor leu isso?". "Em qualquer livro de Sistemas Operacionais" ele me respondeu. Vejam só que inocência da minha parte, eu imaginava que os livros clássicos de Sistemas Operacionais tinham sido escritos quando o Windows XP ainda nem existia. Então eu disse: "Não é por nada, é que não é isso que tenho visto nos livros que tenho lido. Talvêz eu esteja lendo os livros errados."  | Windows Driver Model (1999)
"The operating system can preempt any subroutine at any moment for an arbitrarily long period of time, so we cannot be sure of completing critical tasks without interfere or delay. Even if we take steps to prevent preemption, code executing simultaneously on other CPU in same computer can interfere with our code." |  | Windows NT Device Driver Development (1999)
"As was mentioned in Chapter 1, Windows NT is a pre-emptive, multithreaded, and multitasking, operating system. It employs a traditional operating system technique to provide this multitasking capability by associating a quantum with each thread when it starts running." |  | Desvendando o Windows NT (1998)
"Como o Windows NT implementa um escalador preemptivo, se outro thread, com uma prioridade mais alta se aprontar para execução, o thread sendo executado atualmente é solicitado antes de terminar sua fatia de tempo." |  | Windows Internals (2005):
"Windows implements a priority-driven, preemptive scheduling system the highest priority runnable (ready) thread always runs, with the caveat that thread chosen to run might be limited by the processors on wich the thread is allowed to run, a phenomenom called Processor Afinitty." |  | Developing Drivers with Windows Driver Foundation (2007):
"Windows is a preemptive multitasking operating system in wich multiple thread can try to aceess shared data or resources concurrently and multiple drivers functions can run concurrently." |
Enfim, é óbvio que não vou discutir com meu professor e tornar minha vida acadêmica um inferno. Mais uma vez vou respirar fundo e fazer dizer aquele sonoro "Ahhhh tá...". É nestes momentos que eu fico preocupado sobre um outro aspecto. Felizmente posso ouvir e filtrar o que professores de programação em Linguagem C e Sistemas Operacionais dizem, mas nada posso fazer quanto aos professores de Eletrônica, Inteligência Artificial, Microcontroladores e outras tantas matérias que estamos aprendendo. Será que estamos ouvindo as mesmas barbaridades e não sabemos? De qualquer forma, a matéria que pensei que seria a mais fácil, agora é uma das que me atormentam.
Leia sempre...
Utilizando o Registry (Parte 2)
Pois é, como eu estava dizendo na primeira parte deste post. Isso é muito código. Todo esse negócio parece trabalhoso, não? Montar uma UNICODE_STRING para o caminho da chave que se deseja acessar, montar um OBJECT_ATTRIBUTES com ela, abrir handle, determinar o tamanho dos valores a serem lidos, alocar um buffer grande suficiente, ler o valor que se deseja, desalocar qualquer buffer temporário utilizado no processo, e por fim, fechar o handle para a chave do registro. Você pode conferir quanto código utilizamos em nosso exemplo do post anterior para se ler dois valores no registro. Hoje veremos um grupo de rotinas de manipulação de registro que facilita esse processo.
Rotinas RTL de Registro
São apenas cinco as rotinas que compõem esse grupinho. Na referência você encontra uma descrição de cada uma delas. Esse grupo de rotinas tem como característica comum o fato de não termos que utilizar handles para as chaves. Os handles são abertos e fechados para cada operação. Outra característica comum é que você não precisa compor o nome completo da chave na qual estão os valores que você quer ler ou escrever. Essas rotinas trabalham com um esquema de nome de chave relativo a algum lugar pré-definido. Confuso? Vamos dar uma olhada numas das rotinas para que tenhamos um exemplo mais prático. Tentando seguir a mesma idéia do exemplo dado no post anterior, precisamos inicialmente verificar se a chave, onde os valores estão armazenados, existe de fato. Tem uma funçãozinha justamente para isso. NTSTATUS
RtlCheckRegistryKey(
IN ULONG RelativeTo,
IN PWSTR Path
);Notem que o primeiro parâmetro dessa rotina é uma constante que indica qual será a referência a ser aplicada ao segundo parâmetro. Observe a tabela abaixo que foi retirada da referência. Um exemplo seria o seguinte: Se usarmos RTL_REGISTRY_ABSOLUTE como primeiro parâmetro, o segundo deve ser o caminho completo da chave de registro. Afinal, temos que passar o caminho absoluto da chave. Por outro lado, se utilizarmos RTL_REGISTRY_SERVICES, o segundo parâmetro deveria ser apenas o complemento do caminho referente a chave Services. Foi esta a opção que utilizei no exemplo deste post. Observe como ficou nossa rotina de criação dos parâmetros no registro.
NTSTATUS
CreateParams(VOID)
{
NTSTATUS nts = STATUS_SUCCESS;
WCHAR wzParam[] = L"DriverEntry.com.br";
ULONG ulParam = 0x12345678;
__try
{
nts = RtlCreateRegistryKey(RTL_REGISTRY_SERVICES,
L"KernelReg2\\Parameters");
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
nts = RtlWriteRegistryValue(RTL_REGISTRY_SERVICES,
L"KernelReg2\\Parameters",
L"DoubleWord",
REG_DWORD,
&ulParam,
sizeof(ulParam));
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
nts = RtlWriteRegistryValue(RTL_REGISTRY_SERVICES,
L"KernelReg2\\Parameters",
L"String",
REG_SZ,
wzParam,
sizeof(wzParam));
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
nts = GetExceptionCode();
ASSERT(FALSE);
}
return nts;
}Mais uma vêz, o código demonstrado aqui está disponível para download ao final deste post.
O fácil que complica
Pelo que pudemos ver até aqui, esse grupo de rotinas já facilitou um pouco nossa vida. Mas é na rotina de leitura que podemos ver a economia de código acontecer de verdade. O custo disso fica por conta de entender como a rotina de leitura funciona. NTSTATUS
RtlQueryRegistryValues(
IN ULONG RelativeTo,
IN PCWSTR Path,
IN PRTL_QUERY_REGISTRY_TABLE QueryTable,
IN PVOID Context,
IN PVOID Environment OPTIONAL
);Olhando assim nem parece que ela morde, mas se você der uma olhada na referência, verá que ela pode ser bem flexivel. Flexibilidade as vezes é traduzido por "Difícil de acertar a maneira certa de utilizar". Os dois primeiros parâmetros são os já conhecidos de antes. A coisa começa a mudar com o terceiro parâmetro, que é uma tabela que contém os detalhes dos valores a serem lidos do registro. Não vou entrar nos detalhes de cada parâmetro desta rotina neste post. Vou apenas fazer o código equivalente ao exemplo do post anterior.
NTSTATUS
LoadParams(VOID)
{
NTSTATUS nts = STATUS_SUCCESS;
RTL_QUERY_REGISTRY_TABLE QueryTable[] =
{
{ NULL, RTL_QUERY_REGISTRY_DIRECT | RTL_QUERY_REGISTRY_REQUIRED,
L"DoubleWord", &g_ulParam, REG_NONE, NULL, 0 },
{ NULL, RTL_QUERY_REGISTRY_DIRECT | RTL_QUERY_REGISTRY_REQUIRED,
L"String", &g_usParam, REG_NONE, NULL, 0 },
{ NULL, 0, NULL, NULL, REG_NONE, 0, NULL }
};
__try
{
if (g_usParam.Buffer)
RtlFreeUnicodeString(&g_usParam);
nts = RtlQueryRegistryValues(RTL_REGISTRY_SERVICES,
L"KernelReg2\\Parameters",
QueryTable,
NULL,
NULL);
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
nts = GetExceptionCode();
ASSERT(FALSE);
}
return nts;
}Não, não está faltando nada. É só isso mesmo. Vamos olhar mais de perto o que fizemos aqui. A tabela que preenchemos tem os dados das leituras a serem realizadas e é definida como mostra abaixo. typedef struct _RTL_QUERY_REGISTRY_TABLE {
PRTL_QUERY_REGISTRY_ROUTINE QueryRoutine;
ULONG Flags;
PWSTR Name;
PVOID EntryContext;
ULONG DefaultType;
PVOID DefaultData;
ULONG DefaultLength;
} RTL_QUERY_REGISTRY_TABLE, *PRTL_QUERY_REGISTRY_TABLE;Olhando cada membro dela temos: - QueryRoutine: Aqui você tem um ponteiro de função que será chamado quando o este ítem da tabela for lido no registro. Não usamos este método em nosso exemplo. Existem algumas coisas interessantes sobre essa rotina de callback. Ela é chamada para cada ítem desta tabela, mas se o valor a ser lido for do tipo REG_MULTI_SZ, a rotina de callback é chamada uma vez para cada string contida neste valor. Consulte a referência para uma completa descrição destes detalhes.
- Flags: O flag que utilizamos aqui foi o RTL_REGISTRY_DIRECT que sinaliza que não usaremos o método do callback. Outro flag é o RTL_QUERY_REGISTRY_REQUIRED que indica que o valor descrito nesta linha da tabela é obrigatório. Caso o valor não seja encontrado, RtlQueryRegistryValues retorna erro e os demais valores não serão lidos.
- Name: Aqui vem o nome do valor a ser lido. Note que não é um UNICODE_STRING, mas um array de WCHAR terminado em zero.
- EntryContext: Em nosso exemplo, este parâmetro é o buffer onde o valor lido será armazenado, mas nos casos onde recebemos a chama pela a rotina de callback, este valor é passado como um dos parâmetros.
Os parâmetros DefaultType, DefaultData e DefaultLengh seriam utilizados caso o valor não existisse e não fosse um valor obrigatório. Cada valor a ser lido é representado por uma linha nesta tabela. A rotina identifica o fim da tabela quando encontrar os membros QueryRotuine e Name forem NULL. Calma aí Fernando! Muito bem, nada nessa manga, nada nessa e os valores são lidos? Espertinho você hein? Pensou que ia enganar todo mundo com essa conversinha? Muito bem! Onde é que eu indico o tamanho do buffer oferecido para a leitura? Muito boa a sua pergunta! Acho até que eu mesmo não teria feito uma pergunta tão boa. O tamanho o buffer é indicado pelo próprio buffer. No caso da string, passamos um ponteiro para um UNICODE_STRING, o tamanho do buffer da string já é descrito por essa estrutura, mas se o buffer desta estrutura for NULL, a rotina aloca o buffer do tamanho necessário. Temos que desalocar esse buffer quando não for mais utilizá-lo. Para leituras onde o buffer resultante é menor ou igual ao sizeof(ULONG) então o valor resultante é armazenado diretamente no lugar apontado por EntryContext. Para demais detalhes consulte a referência. Esta função é bem flexível e não vou conseguir colocar tudo que essa rotina oferece em um único post, mas sintam-se a vontade para mandar suas dúvidas em relação a ela. Have fun! Download KernelReg2.zip
Utilizando o Registry (Parte 1)
 No último post, em resposta à uma dúvida de um leitor, comentei um pouco sobre como criar e usar novas IOCTLs. Afinal de contas, o lema desse blog é "Servir bem para servir sempre". Dúvidas de leitores são ótimas fontes de sugestões para novos posts. Creio que como em qualquer outra especialidade, o desenvolvimento de drivers é um tópico que pode ser desmembrado em muitas e muitas partes. Não é a toa que o menor livro que eu conheço sobre desenvolvimento de drivers não tenha menos de quatrocentas páginas. Por isso é bom saber quais são as dificuldades dos leitores para saber sobre qual assunto postar aqui. Sintam-se à vontade para mandar novas sugestões ou dúvidas. Já há algum tempo, recebi um e-mail de Fábio Dias (Fortaleza, CE), que sugeriu um post sobre como acessar o Registry a partir de um driver. Muito bem, vamos lá.
HKEY_LOCAL_MACHINE é coisa se User Mode
Antes de sair dizendo quais APIs você deve usar para acessar o registro, vamos antes dar uma olhada em como o registro está organizado. Creio que o primeiro passo aqui seja falar sobre como abrir uma chave do registro. Assim como em User Mode, temos que ter uma string que informe o caminho da chave a qual queremos abrir, e assim obter um handle para ela. Opa! Eu disse handle? Sendo assim, vale comentar que as chaves do registro também são recursos gerenciados pelo Object Manager. As chaves do registro estão todas armazenadas sob o namespace "\Registry". Desta forma, enquanto usamos HKEY_LOCAL_MACHINE em User Mode como nome de uma das divisões básicas do registro, em Kernel Mode usamos "\Registry\Machine". E de maneira análoga à HKEY_USERS temos "\Registry\Users". Mais detalhes aqui.
Qual é o CurrentControlSet?
A rotina DriverEntry de qualquer driver para Windows NT recebe dois parâmetros de entrada, sendo um deles um ponteiro para a estrutura DRIVER_OBJECT que representa a instância do nosso driver, e o outro parâmetro é um UNICODE_STRING contendo o caminho do registro que indica onde nosso driver está cadastrado. Mas como assim? Nosso driver pode não saber como ele foi cadastrado no registro? Aqui na referência é simples: "The registry path string pointed to by RegistryPath is of the form \Registry\Machine\System\CurrentControlSet\Services\DriverName" Tudo bem, vamos pegar carona em um driver qualquer e dar uma olhada nisso utilizando o WinDbg. Vamos abrir um parênteses aqui para informar aos mais novos neste blog que estou utilizando uma máquina virtual para fazer os testes com o driver de exemplo, como explica neste post. Isso permite que eu possa fazer Debug de Kernel sem necessariamente ter que utilizar duas máquinas. Para facilitar a substituição do driver a cada modificação que faço, estou utilizando o mapeamento de drivers do WinDbg, como explica neste outro post. Este recurso permite que o WinDbg sempre carregue uma nova versão driver na máquina TARGET sem que eu tenha que necessariamente substituir o driver nela. Fecha parênteses. Antes mesmo do driver ser carregado, coloquei um breakpoint na rotina DriverEntry. Opa! Como você pode colocar um breakpoint em um driver que ainda não foi carregado? Ah tá... Você pode fazer isso utilizando o comando bu como mostra abaixo. Os breakpoints são setados quando o driver for carregado. Na linha seguinte, eu apenas listo os breakpoints, só pra... Quando o driver é carregado, a execução pára em meu breakpoint e uso a extensão !ustr, que mostra UNICODE_STRINGs, para ver o valor desse meu segundo parâmetro da DriverEntry. kd> bu KernelReg!DriverEntry
kd> bl
0 eu 0001 (0001) (KernelReg!DriverEntry)
kd> g
KD: Accessing 'Z:\Sources\DriverEntry\KernelReg\objchk_w2k_x86\i386\KernelReg.sys'
(\??\C:\WINDOWS\system32\drivers\KernelReg.sys)
File size 2K.
MmLoadSystemImage: Pulled \??\C:\WINDOWS\system32\drivers\KernelReg.sys from kd
Breakpoint 0 hit
KernelReg!DriverEntry:
f8d394a0 8bff mov edi,edi
kd> !ustr poi(pusRegistryPath)
String(114,114) at 82302000: \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\KernelRegMas não era pra ser CurrentControlSet? Na verdade o CurrentControlSet é um link para um outro ControlSet. No caso observado acima, o CurrentControlSet está refletindo o ControlSet001, ou seja, as alterações feitas no ControlSet001 são vistas no CurrentControlSet e vice-versa. O CurrentControlSet pode refletir qualquer outro ControlSet. Algumas regras determinam quando eles mudam, como em casos de mudanças de configurações de sistema ou instalações de drivers. Para saber para onde o CurrentControlSet está apontando, dê uma olhada no valor Current que está na chave "\Registry\Machine\System\Select" como mostra a figura abaixo. Mas isso é apenas para efeito de curiosidade. Quando você utiliza CurrentControlSet como parte do caminho da chave que você deseja acessar, o Object Manager faz a traducão pra você e todos vivem felizes para sempre.
Cadê \Registry\Machine\Software?
Já pode ter acontecido com alguns de vocês. Vocês escrevem um driver que deve ler uma certa chave dentro de "\Registry\Machine\Software" quando o driver é carregado. Enquanto você faz testes com o driver, que neste momento tem seu Start configurado para Manual(3), tudo funciona que é uma maravilha, mas na hora de mudar o Start do driver para Boot(0) ou System(1), não conseguimos abrir a chave recebendo STATUS_OBJECT_NAME_NOT_FOUND (0xC00000034). Como assim nome não encontrado? Estava aqui agora mesmo! O que acontece é que a chave SOFTWARE é montada mais tarde. Assim, durante o boot do sistema ela ainda não existe. Para fazer acesso a essa chave, você terá que esperar um cadim, talvez utilizando a tática deste post. Aí tudo funciona que é uma beless.
Algo a dizer sobre HKEY_CURRENT_USER?
Então, veja bem. Quem é o Current User? Usuário que está fazendo a chamada, certo? Assim, conforme a tradição, você começa pensando que é fácil e estando logado como Paulo, você inicia seu driver manualmente. O driver, durante a chamada à DriverEntry, lê configurações referentes ao usuário logado, que de fato estão armazenadas dentro de HKEY_CURRENT_USER do Paulo. Bom, acho que está certo até aqui. Já ouviram aquela expressão "Quem muito acha acaba se perdendo"? Pois é, tá tudo errado. Para Paulo, as configurações estão lá mesmo, mas a rotina DriverEntry é chamada em contexto de sistema, que por sinal não é Paulo. Esse é um problema enfrentado mesmo em User Mode, quando serviços, que são executados em conta de sistema, tentam abrir a chave HKEY_CURRENT_USER. Uma coisa que temos que ter em mente é que "O usuário logado" não é uma informação única do sistema. Tentem imaginar um Terminal Service, podem haver vários usuários logados ao mesmo tempo. Mesmo quando há somente um usuário logado no sistema, threads podem ser executadas em contexto de outros usuários ou mesmo em contexto de sistema. Drivers não tem contexto próprio. Algumas partes do driver são executadas em contexto de sistema, outras em contexto arbitrário. Dependendo do tipo de driver e sua posiçao dentro da pilha de dispositivos, ele pode receber as chamadas em contexto do usuário. Que é o caso dos drivers de File System por exemplo. Ah tá! Aí sim HKEY_CURRENT_USER vai funcionar! Er... Como posso dizer isso? Não, não vai funcionar. Segundo a referência da Microsoft, não existe uma tradução simples para HKEY_CURRENT_USER, mas existem rotinas que oferecem simplificações. Depois de toda essa conversinha sobre contexto e tals, você ainda terá que acessar a chave HKEY_USERS, ou melhor dizendo, "\Registry\User", no formato já conhecido dos programadores User Mode utilizado com HKEY_USERS. Um exemplo é: "\Registry\User\S-1-5-21-73586283-1897051121-839522115-500". O equivalente para uma conta de sistema é a chave "\Registry\User\.DEFAULT".
Tá tá tá! Exemplo agora
Mais uma vez, estou assumindo que você já sabe compilar e instalar um driver como explicado neste post. O código exemplo disponível para download ao final deste post também pode ser compilado pelo Visual Studio utilizando o DDKBUILD, como explica este post. Neste exemplo vou mostrar a leitura de dois valores do registro que estão em uma chave como mostra a figura abaixo. Para deixar a brincadeira mais divertida, quando o driver for executado pela primeira vez, este criará a chave e os valores nela contidos quando perceber que estes ainda não existem.  Os valores estarão contidos em uma sub-chave da chave que recebemos como parâmetro na rotina DriverEntry. Então, nosso trabalho básico na codificação da DriverEntry é justamente criar o caminho completo da chave do registro que conterá estes valores. Com esta UNICODE_STRING em mãos, a passaremos para as rotinas de leitura e escrita no registro. Segue abaixo a codificação da rotina DriverEntry. Ela não mostra nada de especial com relação ao registro. Como sempre, vale a pena dar uma lida nos comentários.
extern "C"
NTSTATUS
DriverEntry(__in PDRIVER_OBJECT pDriverObject,
__in PUNICODE_STRING pusRegistryPath)
{
UNICODE_STRING usParameters = RTL_CONSTANT_STRING(L"\\Parameters");
UNICODE_STRING usFullRegPath = {0, 0, NULL};
PWCHAR pwzBuffer = NULL;
NTSTATUS nts = STATUS_SUCCESS;
__try
{
__try
{
pDriverObject->DriverUnload = OnDriverUnload;
pwzBuffer = (PWCHAR)ExAllocatePoolWithTag(PagedPool,
pusRegistryPath->Length +
usParameters.Length,
_KRN_REG_TAG);
if (pwzBuffer == NULL)
ExRaiseStatus(STATUS_INSUFFICIENT_RESOURCES);
RtlInitEmptyUnicodeString(&usFullRegPath,
pwzBuffer,
pusRegistryPath->Length +
usParameters.Length);
RtlCopyUnicodeString(&usFullRegPath,
pusRegistryPath);
RtlAppendUnicodeStringToString(&usFullRegPath,
&usParameters);
nts = LoadParams(&usFullRegPath);
if (!NT_SUCCESS(nts))
{
if (nts != STATUS_OBJECT_NAME_NOT_FOUND)
ExRaiseStatus(nts);
nts = CreateParams(&usFullRegPath);
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
nts = LoadParams(&usFullRegPath);
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
}
}
__finally
{
if (pwzBuffer)
ExFreePool(pwzBuffer);
}
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
nts = GetExceptionCode();
ASSERT(FALSE);
}
return nts;
}Aqui é mais brincadeira de UNICODE_STRING mesmo. Vamos dar uma olhada na rotina que grava os valores no registro. Esta rotina também não oferece nada de muito diferente do que já estamos habituados a ver em User Mode. Mas é como se diz por aí: "Um exemplo vale mais que mil artigos". Nossa, essa foi terrível! Eu preciso parar com isso. Vocês devem estar pensando agora: "Caraca! Cada coisa que a gente precisa ler pra poder ter um exemplo de driver".
NTSTATUS
CreateParams(__in PUNICODE_STRING pusRegistryPath)
{
HANDLE hKey = NULL;
NTSTATUS nts = STATUS_SUCCESS;
OBJECT_ATTRIBUTES ObjAttributes;
UNICODE_STRING usStringParam = RTL_CONSTANT_STRING(L"String");
UNICODE_STRING usDWordParam = RTL_CONSTANT_STRING(L"DoubleWord");
ULONG ulParam = 0x12345678;
WCHAR wzParam[] = L"DriverEntry.com.br";
__try
{
__try
{
InitializeObjectAttributes(&ObjAttributes,
pusRegistryPath,
OBJ_CASE_INSENSITIVE,
NULL,
NULL);
nts = ZwCreateKey(&hKey,
KEY_SET_VALUE,
&ObjAttributes,
0,
NULL,
REG_OPTION_NON_VOLATILE,
NULL);
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
nts = ZwSetValueKey(hKey,
&usDWordParam,
0,
REG_DWORD,
&ulParam,
sizeof(ulParam));
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
nts = ZwSetValueKey(hKey,
&usStringParam,
0,
REG_SZ,
&wzParam,
sizeof(wzParam));
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
}
__finally
{
if (hKey)
ZwClose(hKey);
}
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
nts = GetExceptionCode();
ASSERT(FALSE);
}
return nts;
}Por fim a parte mais divertida desta história. Creio que a maior parte da diversão está concentrada na rotina ZwQueryValueKey, que realiza a leitura de valores no registro. NTSTATUS
ZwQueryValueKey(
IN HANDLE KeyHandle,
IN PUNICODE_STRING ValueName,
IN KEY_VALUE_INFORMATION_CLASS KeyValueInformationClass,
OUT PVOID KeyValueInformation,
IN ULONG Length,
OUT PULONG ResultLength
);O ponto que difere da API usada em User Mode para fazer a mesma tarefa é o terceiro parâmetro KEY_VALUE_INFORMATION_CLASS. Um enum que informa quais as informações gostaríamos de obter sobre determinado valor no registro. Um deles solicita apenas o nome enquanto outro solicita todas as informações e o último informações parciais referentes ao valor. typedef enum _KEY_VALUE_INFORMATION_CLASS {
KeyValueBasicInformation,
KeyValueFullInformation,
KeyValuePartialInformation
} KEY_VALUE_INFORMATION_CLASS;Para cada valor do enum, uma estrutura diferente é retornada. Sempre em um único bloco, a estrutura pode trazer várias informações utilizando Offsets de onde encontrar o dado dentro daquela única alocação de memória. No exemplo, utilizei o KeyValuePartialInformation, que imagino ser o valor mais utilizado. Mais uma vez fica minha dica para que leiam os comentários trecho abaixo.
NTSTATUS
LoadParams(__in PUNICODE_STRING pusRegistryPath)
{
HANDLE hKey = NULL;
NTSTATUS nts = STATUS_SUCCESS;
OBJECT_ATTRIBUTES ObjAttributes;
UNICODE_STRING usStringParam = RTL_CONSTANT_STRING(L"String");
UNICODE_STRING usDWordParam = RTL_CONSTANT_STRING(L"DoubleWord");
ULONG ulBytes = 0;
PWCHAR pwzBuffer = NULL;
PKEY_VALUE_PARTIAL_INFORMATION pValueInfo = NULL;
__try
{
__try
{
InitializeObjectAttributes(&ObjAttributes,
pusRegistryPath,
OBJ_CASE_INSENSITIVE,
NULL,
NULL);
nts = ZwOpenKey(&hKey,
GENERIC_READ,
&ObjAttributes);
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
ulBytes = sizeof(KEY_VALUE_PARTIAL_INFORMATION) +
sizeof(ULONG) - sizeof(UCHAR);
pValueInfo = (PKEY_VALUE_PARTIAL_INFORMATION)
ExAllocatePoolWithTag(PagedPool,
ulBytes,
_KRN_REG_TAG);
if (!pValueInfo)
ExRaiseStatus(STATUS_INSUFFICIENT_RESOURCES);
nts = ZwQueryValueKey(hKey,
&usDWordParam,
KeyValuePartialInformation,
pValueInfo,
ulBytes,
&ulBytes);
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
ASSERT(pValueInfo->Type == REG_DWORD);
g_ulParam = *(PULONG)pValueInfo->Data;
ExFreePool(pValueInfo);
pValueInfo = NULL;
nts = ZwQueryValueKey(hKey,
&usStringParam,
KeyValuePartialInformation,
NULL,
0,
&ulBytes);
ASSERT(nts == STATUS_BUFFER_OVERFLOW ||
nts == STATUS_BUFFER_TOO_SMALL);
pValueInfo = (PKEY_VALUE_PARTIAL_INFORMATION)
ExAllocatePoolWithTag(PagedPool,
ulBytes,
_KRN_REG_TAG);
if (!pValueInfo)
ExRaiseStatus(STATUS_INSUFFICIENT_RESOURCES);
nts = ZwQueryValueKey(hKey,
&usStringParam,
KeyValuePartialInformation,
pValueInfo,
ulBytes,
&ulBytes);
if (!NT_SUCCESS(nts))
ExRaiseStatus(nts);
ASSERT(pValueInfo->Type == REG_SZ);
pwzBuffer = (PWCHAR)ExAllocatePoolWithTag(PagedPool,
pValueInfo->DataLength,
_KRN_REG_TAG);
if (!pwzBuffer)
ExRaiseStatus(STATUS_INSUFFICIENT_RESOURCES);
if (g_usParam.Length)
RtlFreeUnicodeString(&g_usParam);
RtlInitEmptyUnicodeString(&g_usParam,
pwzBuffer,
(USHORT)pValueInfo->DataLength);
RtlAppendUnicodeToString(&g_usParam,
(PCWSTR)pValueInfo->Data);
}
__finally
{
if (pValueInfo)
ExFreePool(pValueInfo);
if (hKey)
ZwClose(hKey);
}
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
nts = GetExceptionCode();
ASSERT(FALSE);
}
return nts;
}Ufa! Quanto código! Nesta primeira parte do assunto busquei utilizar as APIs que mais se parecem com as APIs de User Mode. No próximo post trarei uma maneira diferente de fazer a mesma coisa que fizemos aqui. Espero ter ajudado,
Até mais... Download KernelReg.zip
Criando e usando IOCTLs
Essa semana recebi a seguinte pergunta de um leitor: "É possível meu aplicativo passar um IOCTL customizável (feito por mim) para o driver, e este reconhecer sem problemas?" A resposta à curto prazo é: "Sim, e boa sorte!", mas que graça tem ter um blog se não podemos falar um pouco mais a respeito e até dar um exemplo assim de lambuja? Este post assume que você já sabe alguns conceitos básicos, tais como compilar, instalar e testar drivers. Mas se você ainda não sabe fazer isso, não se preocupe, a vida ainda vale a pena. Basta ler este post.
O driver que calculava
Vamos criar um driver de exemplo que usa a mesma idéia que meu amigo Heldai já usava para ilustrar o uso de IOCTLs quando eu ainda estava aprendendo a fazer telas azuis. No exemplo de hoje vamos fazer um driver que some dois números contidos em uma estrutura que será recebida via um IOCTL. Sem mais blablablas acho que podemos começar pela definição da estrutura. Como a tia do prezinho já nos ensinou, vamos criar apenas um arquivo de header que seja incluído tanto pelo projeto da aplicação como pelo projeto do driver. Este arquivo de header não deve incluir nenhum outro arquivo de header específico de User Mode e nem de Kernel Mode, ou seja, nada de Windows.h nem de ntddk.h. Tudo isso já está prontinho, testadinho, e como meu amigo Rafael costuma dizer, "compilandinho" num projeto disponível para download ao final do post. typedef struct _KERNEL_MATH_REQUEST
{
ULONG x;
ULONG y;
} KERNEL_MATH_REQUEST, *PKERNEL_MATH_REQUEST;
typedef struct _KERNEL_MATH_RESPONSE
{
ULONG r;
} KERNEL_MATH_RESPONSE, *PKERNEL_MATH_RESPONSE;
Criando o IOCTL
O IOCTL é mais do que simplesmente um número para identificar a operação desejada. Ele é composto por uma máscara de bits que são interpretados pelo Windows. Esta máscara é definida como mostra a figura abaixo. Você pode obter maiores detalhes sobre esta macro neste link. Para definir o IOCTL nós utilizamos a macro CTL_CODE que tem seus parâmentros como mostra abaixo. #define IOCTL_Device_Function CTL_CODE(DeviceType, Function, Method, Access) Vamos definir nosso IOCTL como mostra abaixo. #define IOCTL_SOMA_QUE_EU_TO_MANDANDO \
CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_SUBTRAI_QUE_EU_TO_MANDANDO \
CTL_CODE(FILE_DEVICE_UNKNOWN, 0x801, METHOD_BUFFERED, FILE_ANY_ACCESS)Agora vamos dar uma olhada em cada parâmetro que foi escolhido aqui e dar uma pincelada a respeito. FILE_DEVICE_UNKNOWN - Dando uma olhada em nossa DriverEntry podemos verificar que este foi o mesmo tipo utilizado na chamada à rotina IoCreateDevice.
extern "C" NTSTATUS
DriverEntry(__in PDRIVER_OBJECT pDriverObj,
__in PUNICODE_STRING pusRegistryPath)
{
UNICODE_STRING usDeviceName = RTL_CONSTANT_STRING(L"\\Device\\KernelSum");
UNICODE_STRING usSymbolicLink = RTL_CONSTANT_STRING(L"\\DosDevices\\KernelSum");
NTSTATUS nts;
PDEVICE_OBJECT pDeviceObj;
pDriverObj->DriverUnload = OnDriverUnload;
pDriverObj->MajorFunction[IRP_MJ_CREATE] =
pDriverObj->MajorFunction[IRP_MJ_CLEANUP] =
pDriverObj->MajorFunction[IRP_MJ_CLOSE] = OnCreateCleanupClose;
pDriverObj->MajorFunction[IRP_MJ_DEVICE_CONTROL] = OnDeviceIoControl;
nts = IoCreateDevice(pDriverObj,
0,
&usDeviceName,
FILE_DEVICE_UNKNOWN,
0,
FALSE,
&pDeviceObj);
if (!NT_SUCCESS(nts))
{
ASSERT(FALSE);
return nts;
}
nts = IoCreateSymbolicLink(&usSymbolicLink,
&usDeviceName);
if (!NT_SUCCESS(nts))
{
IoDeleteDevice(pDeviceObj);
ASSERT(FALSE);
return nts;
}
return STATUS_SUCCESS;
}O segundo parâmetro, o Function, recebe o número 0x800, já que os números abaixo disso são reservados à Microsoft. METHOD_BUFFERED - Indica ao IoManager que o driver receberá uma cópia do buffer de entrada passado à função DeviceIoControl. O IoManager aloca um buffer de sistema, ou seja, em Kernel Space, suficientemente grande para que caibam tanto os dados de entrada como os dados de saída. Quando a função DeviceIoControl é chamada, o IoManager aloca o buffer de sistema e copia o buffer de entrada para dentro dele. O driver recebe a IRP, obtém os parâmetros de entrada, processa-os e escreve os dados de saída no mesmo buffer de sistema. Quando a IRP é completada, o IoManager copia os dados de saída do buffer de sistema para o buffer de saída oferecido pela aplicação. Além do método Buffered, ainda existem os métodos de Direct I/O e Neither. Para o nosso exemplo de hoje, o méthodo Buffered está ótimo. Fico devendo um post que fala sobre como usar cada um dos outros métodos. FILE_ANY_ACCESS - Indica que o handle não precisa ser aberto com um tipo de acesso especial para poder executar este IOCTL.
Da aplicação para o driver
Para enviar um IOCTL para o driver, você precisa utilizar a função DeviceIoControl como mostra o exemplo abaixo. Este é um programa bem simples que mostra este uso.
int __cdecl main(int argc, CHAR* argv[])
{
HANDLE hDevice;
DWORD dwError = ERROR_SUCCESS,
dwBytes;
KERNEL_MATH_REQUEST Request;
KERNEL_MATH_RESPONSE Response;
printf("Opening \\\\.\\KernelSum device...\n");
hDevice = CreateFile("\\\\.\\KernelSum",
GENERIC_ALL,
0,
NULL,
OPEN_EXISTING,
0,
NULL);
if (hDevice == INVALID_HANDLE_VALUE)
{
printf("Error #%d opening device...\n",
(dwError = GetLastError()));
return dwError;
}
Request.x = 3;
Request.y = 2;
printf("Calling DeviceIoControl...\n");
if (!DeviceIoControl(hDevice,
IOCTL_SOMA_QUE_EU_TO_MANDANDO,
&Request,
sizeof(KERNEL_MATH_REQUEST),
&Response,
sizeof(KERNEL_MATH_RESPONSE),
&dwBytes,
NULL))
{
printf("Error #%d calling DeviceIoControl...\n",
(dwError = GetLastError()));
CloseHandle(hDevice);
return dwError;
}
printf("%d + %d = %d\n",
Request.x,
Request.y,
Response.r);
printf("Closing device...\n");
CloseHandle(hDevice);
return 0;
}Note que não existe nenhuma amarração forte entre o IOCTL e os bufferes de entrada ou de saída utilizados, mas é preciso ficar atento aos tamanhos dos bufferes quando o driver fizer uso deles. Ninguém vai querer corromper o heap de alocações de Kernel ou sair disparando excessões em Kernel Mode, vai? Vejam como os dados são tratados pelo driver ao receber a IRP_MJ_DEVICE_CONTROL. Leiam os comentários, eles fazem parte do texto explicativo. Nossa, até que essa frase que representa a minha preguiça ficou legal. No fundo mesma frase quer dizer: "Ah meu! Fala sério que além de preparar esse exemplo, você ainda quer que eu duplique toda a informação dos comentários. E na bunada não vai dinha?"
NTSTATUS
OnDeviceIoControl(__in PDEVICE_OBJECT pDeviceObj,
__in PIRP pIrp)
{
PIO_STACK_LOCATION pStack;
NTSTATUS nts;
PKERNEL_MATH_REQUEST pRequest;
PKERNEL_MATH_RESPONSE pResponse;
pStack = IoGetCurrentIrpStackLocation(pIrp);
switch(pStack->Parameters.DeviceIoControl.IoControlCode)
{
case IOCTL_SOMA_QUE_EU_TO_MANDANDO:
case IOCTL_SUBTRAI_QUE_EU_TO_MANDANDO:
if (pStack->Parameters.DeviceIoControl.InputBufferLength !=
sizeof(KERNEL_MATH_REQUEST) ||
pStack->Parameters.DeviceIoControl.OutputBufferLength !=
sizeof(KERNEL_MATH_RESPONSE))
{
nts = STATUS_INVALID_BUFFER_SIZE;
pIrp->IoStatus.Information = 0;
break;
}
ASSERT(pIrp->AssociatedIrp.SystemBuffer != NULL);
pRequest = (PKERNEL_MATH_REQUEST)pIrp->AssociatedIrp.SystemBuffer;
pResponse = (PKERNEL_MATH_RESPONSE)pIrp->AssociatedIrp.SystemBuffer;
if (pStack->Parameters.DeviceIoControl.IoControlCode == IOCTL_SOMA_QUE_EU_TO_MANDANDO)
pResponse->r = pRequest->x + pRequest->y;
else
pResponse->r = pRequest->x - pRequest->y;
nts = STATUS_SUCCESS;
pIrp->IoStatus.Information = sizeof(KERNEL_MATH_RESPONSE);
break;
default:
nts = STATUS_INVALID_DEVICE_REQUEST;
pIrp->IoStatus.Information = 0;
}
pIrp->IoStatus.Status = nts;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return nts;
}
Compilando assim ou assado
O projeto de exemplo que está disponível para download ao final deste post pode ser compilado de duas maneiras. Uma delas é utilizando a maneira padrão de compilar drivers oferecida pelo WDK. Resumidamente você vai em Start->All Programs->Windows Drivers Kits->WDK 6000->Build Environments->Windows XP->Windows XP x86 Checked Build Environment. Isso deve abrir uma jabela de prompt como mostra abaixo. Depois disso é só ir ao diretório onde você baixa essas tranqueiras da internet e entrar no diretório raiz do projeto. Lá você chama o Build.exe e um abraço. A outra maneira de compilar todo o projeto permite que você compile de dentro do Visual Studio 2008, que foi o ambiente que utilizei para compor este projeto. Porém, para compilar o projeto pela IDE, você precisará usar o DDKBUILD como mostra este outro post que fala a respeito. Enquanto estive fora, recebi uma outra dúvida de um leitor que queria saber como ler/escrever no registro usando um driver. No próximo post falarei sobre isso além de outros detalhes referentes ao registro do ponto de vista de um driver. Até lá! Download KernelSum.zip
Tirando o atraso :-P
 Mais uma vez fiquei sem postar por um longo tempo. Agora você deve estar pensando: "Lá vem ele com aquela ladainha de que não tem tempo, que tudo está difícil, que Deus não gosta dos programadores de Kernel e assim por diante". Bom, vou pular essa parte de dar minhas desculpas e vou logo dizendo o que estive fazendo durante esse tempo.
Curso de Drivers para Windows
Bom deixe-me ver onde foi mesmo que eu parei. Meu último post foi durante o período em que eu estava dando um curso de desenvolvimento de drivers para uma turma fechada. O curso foi ministrado em cinco sábados de 8 horas cada. Não preciso dizer que isso me ocupou por um tempo. Tá tá tá, sem desculpas.
Quarto Encontro de Programadores de C/C++
No sábado subsequente ao final do curso, fui dar uma passeada neste evento. Deixaram a porta meio aberta e consegui entrar para dar uma espiada e falar um pouco sobre Arquitetura e Desenvolvimento de drivers para Windows com linguagem C. Confesso que o convite para participar deste evento foi uma surpresa para mim. Não sou um grande programador de C++, mas utilizo a linguagem C com classes como meu amigo Strauss gosta de dizer. Posso dizer que foi muito interessante poder participar desse evento de altíssimo nível técnico e ter a oportunidade de ver como a linguagem pode ser utilizada em diferentes cenários. Os slides da minha palestra estão disponíveis neste link.
De volta à Boston
 Até parece que as coisas só acontecem aos sábados. De qualquer forma, no sábado subsequente ao encontro, embarquei em uma viajem de um mês para Boston. Da última vez que estive por lá foi para fazer um treinamento na OSR como descrevi neste post. Desta vez foi um programa de integração da IBM. Pude conhecer pessoalmente as pessoas com quem trabalho e que antes só conhecia por Web Conferência. Mais uma vez foi bem interessante e tentei aproveitar ao máximo. Fomos em dois brasileiros em um Indiano. Senti muita saudade do nosso cafézinho brasileiro. Nessa foto abaixo estão, da esquerda para a direita, David E. Jones (Gerente), Scott D. Hankin (Documentação), William C. Oliveira (Linux), William H. Taber (Linux), Mridula Muppana (Testes), Paul Ganshirt (Windows), Niraj Kumar (AIX), Kaveesh Mishra (Windows), Fernando Roberto (Windows) e Richard Kissel (AIX e Linux). Esta é apenas uma parte de todo o time de MVFS.  Não sabe o que é MVFS? É um File System que faz parte de um produto chamado ClearCase. Não conhece o ClearCase? Bom, além da Wikipedia, pude ter o prazer de esbarrar com uma observação sobre o ClearCase no livro de Rajeev Nagar. Este livro, como eu não me canso de dizer, ainda é a única referência respeitável sobre desenvolvimento de File Systems para Windows apesar de ter sido publicado pela primeira vez em 1997. Mas onde está o ClearCase nesta história? Bom, se você é doente como eu e tem esse livro, dê uma olhadinha no início do capítulo nove. Na primeira página deste capítulo você encontrará as seguintes passagens. Isso é realmente muito legal! :-)
Volta às aulas
Durante um mês inteiro após minha chegada de volta ao Brasil, dediquei algum tempo correndo atrás da matéria que perdi na faculdade. Pois é, ainda estou me graduando em Engenharia da Computação. Já estou trabalhando em meu TCC (Trabalho de Conclusão de Curso). Meu TCC terá obrigatóriamente que ter um driver de Windows, é o mínimo que eu poderia fazer. Finalmente vou poder mostrar o que sei fazer aos meus amiguinhos de sala. Durante o curso, alguns amigos me perguntam com o quê eu trabalho, já que freqüentemente estou lendo grandes livros da Microsoft. Depois de tentar explicar das maneiras mais simples possíveis, desenhando ou mesmo usando fantoches, eles ainda ficam com aquela cara de interrogação. Bom, na hora que eu mostrar a tela azul, eles vão acabar entendendo.  Aproveitei o passeio nos Estados Unidos para comprar esse kit de desenvolvimento da ALTERA. Esse kit vai fazer parte do meu TCC e futuramente poderei utilizá-lo em meus cursos de desenvolvimento de drivers. Hoje conto apenas com as placas de treinamento da OSR, conforme já falei a respeito neste post. Diferente das placas da OSR, este kit pode ter seu hardware definido por uma linguagem chamada VHDL, e assim, poderei fazer com que a placa tenha os mais variados comportamentos e poderei ilustrar a construção de drivers de interface para cada situação. Essa placa custa em torno de R$ 1.700,00 aqui no Brasil, enquanto que paguei apenas US$ 150,00 lá. Praticamente veio no doce. Sabe quando íamos à padaria comprar aquela casquinha de sorvete que vem recheada com maria-mole, e enfiada nela vem um brinquedo. Então, foi quase a mesma coisa. Uma outra coisa interessante nesse kit, além do preço, é que é possível fazer interface USB e interface PCI. Isso vai ser bem divertido.
Seminário de Portabilidade e Performance
Neste último final de semana, participei de mais esse evento organizado pelo grupo de C/C++ Brasil. É impressionante ver como estes eventos estão trazendo cada vez mais gente. Bati algumas fotos, mas vou deixar os comentários por conta do meu amigo Lesma, que já fez um post muito legal à respeito. De volta ao mundo dos bloggers, vou tentar não abandoná-los por tanto tempo. Desculpinhas à parte, num tá fáci não. Até a próxima.
Step into Kernel (Vista + USB2)
 Já comentei em outro post que é possível fazer Kernel Debugging através de uma porta USB 2.0. Neste post vou demonstrar essa tal conexão USB 2.0 funcionando. Ê laiá coisa boa. Então vamos deixar de conversinha mole e vamos logo ao que interessa. Se você não entende nada sobre Kernel Debugging, você pode ler este post, que tráz os conceitos e passos básicos sobre o assunto, ou você pode se perguntar "Como é que eu fui cair neste site?" e voltar para o ORKUT. O barramento USB não permite que tenhamos conexões diretas entre dois computadores. Para que possamos utilizar uma porta USB para este fim, teremos que contar com a ajuda de um hardware adicional. Apesar de receber o nome de Debug Cable, trata-se de um pequeno dispositivo que une os computadores através de portas USB. Não sei se já existem outros fabricantes para o Debug Cable, mas o que vou utilizar neste experimento é o NET20DC.
Utilizando o Debug Cable
Utilizar o Debug Cable é um luxo que apenas o Windows Vista ou sistemas posteriores podem desfrutar. Ele precisa ser conectado a uma porta USB 2.0 sem passar por nenhum HUB do lado TARGET. Mas como saber com certeza quais das minhas portas é de fato 2.0? Uma maneira fácil de saber isso, principalmente para quem tem o WDK instalado, é compilar o exemplo USBView, que está na pasta "C:\WinDDK\6000\src\usb\usbview" do WDK. Este programa enumera os controladores e os respectivos dispositivos USB conectados. Desta forma, quando conectarmos o Debug Cable à máquina TARGET, o USBView deve informar em qual porta este novo dispositivo está conectado. Repare que nesta janela podemos ver em qual controlador a porta que estamos utilizando pertence.  O Windows solicitará um driver ao detectar a presença deste novo dispositivo USB. Do lado TARGET nenhum driver precisa ser instalado para utilizar o Debug Cable. Assim você pode selecionar "Não exibir esta mensagem novamente para este dispositivo" na janela da figura abaixo. Não instalar nenhum driver faz todo o sentido do lado TARGET. Lembre-se de quem vai utilizar esta interface de debug do lado TARGET é a BIOS, e vai repassar o controle para o core do sistema operacional. Vale lembrar também que existe um outro requisito para utilizar o Debug Cable é que a BIOS da máquina TARGET implementar este controle de interface de debug. A parte mais infeliz desta história é que para saber se a sua BIOS está preparada ou não, basta tentar. Ou seja, você pode ter o Debug Cable, uma porta USB 2.0 livre, os cabos e ainda assim correr o risco de nada conectar pelo simples fato da BIOS não dar suporte. Fico feliz em saber que meu notebook dá esse suporte e que não gastei essa grana a toa importando o Debug Cable. Ufa!! 
Modificando o Boot.ini
Hêin? Boot.ini? Isso não te pertence mais. O Windows Vista utiliza uma nova arquitetura chamada Boot Configuration Data (BCD). Isso levou nosso amigo Boot.ini para a casa do chapéu. Para editar as configurações do BCD, utilizamos a ferramenta BCDEdit.exe, uma aplicação console que precisa ser executada com poderes administrativos. A execução desta ferramenta sem qualquer parâmetro nos retorna a seguite saída.  Para configurar o sistema de forma a termos duas opções de boot, uma com debug habilitado e outra não, siga os passos abaixo descritos. O Boot Manager gerencia Boot Loaders, que podem ser outros sistemas operacionais, mesmo que anteriores ao Windows Vista, como também podem ser conjuntos de configurações do mesmo sistema. Cada um destes ítens é identificado por um GUID. Observe que o primeiro comando faz uma cópia da configuração atual para uma que contenha a string "Windows Vista Cobaia Mode" como descrição. Em resposta a essa cópia, a ferramenta nos retorna o GUID resultante da cópia realizada. Observe também que no segundo comando habilitamos o debug de kernel para a configuração identificada pelo GUID que acabamos de receber. Neste momento, se dermos uma olhada nas configurações teremos o resultado como é exibido na mesma imagem abaixo.  Beleza, agora temos que configurar o meio de comunicação que será utilizado pelo Kernel Debugger. creio que a maioria dos micros ainda utilizem portas seriais para este fim. Neste caso, a configuração mais comum seria a de utilizar a porta serial COM1 com um baudrate de 115200. Para setar estas configurações, utilize a seguinte linha de comando. Para ver as configurações atuais, basta executar a segunda linha de comanodo como exibida abaixo. Se você ainda não sabe como utilizar a porta serial como meio de comunicação para o debug de kernel, este post fala a respeito. Entretando, neste post vou comentar sobre o debug de kernel utilizando uma porta USB 2.0 como meio de comunicação. Neste caso as configurações serão as descritas na linha de comando exibida abaixo. O TARGETNAME pode receber qualquer nome. Utilizei o nome "WINDBG" por motivos óbvios, mas você pode colocar qualquer nome. Como vocês podem ter imaginado, as configurações sobre o meio de comunicação de debug são globais, ou seja, não estão vinculadas a esta ou àquela configuração de boot identificada por um GUID. Creio que do lado TARGET já está tudo pronto para efetuar o link. Desta forma, quando reiniciarmos o computador vítima teremos o seguinte menu exibido pelo Boot Manager.
Configurando o HOST
Do lado HOST desta brincadeira, teremos que adicionar o driver que controla o Debug Cable e permitir que o Windbg possa utilizar este dispositivo. Apesar de eu estar utilizando Windows Vista no lado HOST, nada impede de você utilizar o Windows 2000 ou superior neste lado da conversa. A brincadeira começa quando você pluga o dispositivo e clica em "Localizar e instalar o driver (recomendado)" na janela de "Novo hardware encontrado" já exibida neste post. Neste momento o Windows procura pelo driver no banco de dados do Windows Update. A coisa começa a ficar divertida quando o Windows me pede para inserir o disco que veio com o Debug Cable. Apenas duas palavras ficaram em minha mente neste momento: "Que disco?". Sem muitas opções eu cliquei em "Eu não tenho essa porcaria de disco! Cê tá loco? Me mostre qualquer coisa pelo amor de Deus". Alguns de vocês já devem até ter esta seqüência de janelas decoradas de tanto não encontrar drivers para todos os dispositivos que você tem. Por fim quando a última janela me foi mostrada, me veio uma luz, mais uma daquelas idéias brilhantes que tenho a cada ano bisexto. Foi quando pensei comigo mesmo "Já sei! Vou visitar o site do fabricante e procurar por uma sessão de suporte.". E no site do fabricante... E no site da Microsoft... Em fim, mandei o tal e-mail para obter qualquer sinal de que eu não tivesse jogado meu dinheiro no lixo. Em menos de uma hora recebo a resposta com uma lista de requisitos e passos a serem seguidos, mas o mais importante só me foi revelado no final. Eu sabia que podia contar com a inteligência e a agilidade da Microsoft para resolver isso. Mas fica minha dica para os que estão lendo este post. Quando o Windows solicitar o driver do novo dispositivo, aponte a pasta "C:\Program Files\Debugging Tools for Windows\usb". E é com prazer que vos mostro a janela a seguir:
Configurando o Windbg
 Agora é brincadeira de criança. Selecione o ítem "Kernel Debug..." do menu "File". Clique na aba "USB 2.0" e coloque o mesmo TARGETNAME que você escolheu lá na configuração do TARGET com o BCDEdit.exe. No meu caso, o nome é WINDBG como exibido ao lado. Clicando em OK, a janela de comandos do WinDbg deve exibir o texto destacado em vermelho a seguir, e ficar esperando a conexão se completar. A saída abaixo foi obtida com um CTRL+Break após o debugger ter conectado. Microsoft (R) Windows Debugger Version 6.8.0004.0 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Using USB2 for debugging
Waiting to reconnect...
USB2: Write opened
Connected to Windows Vista 6000 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Vista Kernel Version 6000 MP (1 procs) Free x86 compatible
Built by: 6000.16584.x86fre.vista_gdr.071023-1545
Kernel base = 0x82000000 PsLoadedModuleList = 0x82111e10
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run kd.exe) or, *
* CTRL+BREAK (if you run WinDBG), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
820818d0 cc int 3
0:kd> Agora acabou a parte fácil, os próximos passos já serão referentes a encontrar o bug. Mas isso vai ter que ficar para um outro post. Espero ter ajudado.
T+ :-)
|
|
