Kernel hacking methodology - como descobrir onde hackear o kernel do linux

Question

Eu tenho um laptop barato que eu gostaria de mexer, um Thinkpad SL 500.

O que me incomoda são dois leds, o de conectividade sem fio e o de hibernação, que não acendem, apesar de funcionais, eu tentei no Windows.

Então eu gostaria de escrever um driver de kernel para eles, nada grande, parece uma boa idéia brincar com o kernel.

Minha pergunta é qual metodologia devo seguir sistematicamente para descobrir quais dispositivos são responsáveis por esses leds (em geral, não necessariamente específicos do meu hardware) e quais drivers são responsáveis pelos outros dois. leds que funcionam, bluetooth e o indicador da bateria?

E quando falo de metodologia, realmente me refiro à metodologia, passo a passo, com motivos para cada etapa, como na resposta que dei a outra pessoa aqui: O que & & mean in void * p = & & abc;

Eu sou proficiente em fagrep através de grandes repositórios de código, usando analisadores de código estáticos & co, mas eu acho que a minha falta de conhecimento de hardware me impede sobre este problema.

PS: Estou usando o ArchLinux, então quase a versão mais recente do kernel.

    

Answer 1

I think my lack of hardware knowledge hinders me on this problem.

Então vamos começar com o básico. Os LEDs indicadores podem ser controlados de várias maneiras:

• O LED é controlado diretamente por um chip / dispositivo periférico. Nessa situação, a CPU e o driver do kernel não teriam controle sobre o LED. Este é tipicamente o caso dos LEDs "activity" e "link speed" em um conector Ethernet RJ-45; esses LEDs estariam sob controle direto / exclusivo do dispositivo Ethernet PHY.

• O LED é controlado por um pino GPIO (General Purpose Input / Output) da CPU ou SoC.

• O LED é uma saída de lógica externa (por exemplo, um chip FPGA).

• O LED é uma saída em um chip periférico.

As últimas três situações podem não ser distinguíveis no código-fonte. Um bit em uma porta ou dispositivo register ativará ou desativará o LED. Inspecione o arquivo de cabeçalho para o que os outros bits no registro controlarão. O registro será lido / escrito usando instruções de E / S ou instruções de busca / armazenamento de memória, dependendo da arquitetura do processador.

Observe que o LED geralmente é um dissipador de corrente e está vinculado à alta voltagem lógica, portanto, o LED é ligado aterrando o pino gravando um valor 0 bit. Por outro lado, o LED geralmente é desativado gravando um valor de 1 bit. Como apenas um bit do registro está sendo alterado, uma leitura de todo o registro é normalmente necessária antes da modificação do bit. O próprio registrador pode ser uma região crítica, que exigirá a aquisição (& liberação) de um mutex ou spin-lock para proteger toda a operação.

Inspeção de código-fonte

Se os drivers de dispositivo são proprietários, você está ferrado. Caso contrário, você deve conseguir obter o código-fonte. Sua distro deve disponibilizar seu código-fonte. Existem visualizadores on-line, como esta árvore de kernel do Linux , com hyperlinks de referência cruzada incorporados. Se os drivers não estiverem na árvore de origem do kernel da linha principal, você deverá pedir ao fabricante do hardware para fornecer o código fonte de acordo com os termos da GPL.

Você mencionou quatro indicadores:

• conectividade sem fio
• hibernação
• conectividade Bluetooth
• bateria

Obtenha a saída do comando lsmod , que listará os módulos de tempo de execução anexados ao kernel. Na lista de módulos, você precisa determinar quais drivers correspondem à funcionalidade desses LEDs, por exemplo, rede sem fio, energia, etc. Supondo que este ThinkPad tenha um chip controlador sem fio Intel, será necessário procurar no diretório drivers/net/wireless/iwlwifi . Inspecione os arquivos Kconfig e Makefile nesse diretório de driver para as correlações entre o nome do dispositivo HW real, os símbolos de configuração, o (s) módulo (s) .ko construídos e o código-fonte correspondente.

Revise o código-fonte do driver para manipulação do LED indicador. Se a operação não for comentada, você terá que procurar uma operação de bits, uma macro ou uma chamada de procedimento. Há muitas maneiras de organizar esse código, dependendo da modularidade do código, ou se as técnicas de OOP foram empregadas e essas operações de LED são encapsuladas em procedimentos em algum outro driver. Cuidado com o texto (código executável) em macros (ou seja, #define ) e em arquivos de cabeçalho. Ou seja, revisar apenas os arquivos .c seria um erro. Tenha também em atenção que alguns códigos de dispositivos podem estar abaixo de arch/xxx/platform ou arch/xxx/machine , especialmente para computadores de placa única incorporados.