Bom dia a todos,
Hoje gostava de vos trazer algo muito interessante.
Aqui refiro-me à
system call ptrace() do Linux.
Ela permite correr um trace às system calls e aos registos do processador de um processo child target ou fazer o attachment a um processo target que já esteja a correr.
Ela permite também implementar um debugger.
Com uma interface de debugging pode-se inclusive fazer coisas engraçadas, como por exemplo, simular alguns dos efeitos da radiação num sistema CPU e memória. Como por exemplo possíveis flips de bits aleatórios ou em padrões pré-determinados nos diferentes registos, ou em determinadas zonas de memória ou em determinados endereços de memória que possam ser o controlo de periféricos de hardware dentro do CPU. Assim simular cenários como sistemas em satélites sob o efeito de partículas sub-atómicas de alta energia. Mesmo antes de submeter o hardware a um teste físico de radiação real. Com isto pode-se simular o efeito no programa e avaliar a degradação ou resiliência de um programa a determinados erros a correr em cima de uma determinada plataforma ou CPU a custo zero e em qualquer computador. Para sistemas em tempo real ou quase tempo real penso que teria de se medir com exatidão os tempos destas chamadas inerentes à syscall ptrace() e respetivo código adjacente dentro do código do tracer que corre o ptrace() e descontar esses tempos no sistema de tempos real target. Os CPU's para o onboard de satélites ou de sondas de deep space, onde não existe a magnetosfera que envolve a terra, a proteger esses equipamentos, esses CPU's são normalmente radiation hardened o que significa que das duas uma, ou tem métodos de redundância internos como por exemplo duplicação de buses e de registos ou então tem como os mais recentes PowerPC acho que dos últimos mainframes da IBM que tem correção de erros CRC por hardware entre a passagem dos dados de um registo para o outro, tal como as memória dos servidores são ECC. Outra forma é colocar uma camada de um material denso a isolar as die's dos chips de menores features como por exemplo chumbo. Mas o chumbo acaba por ser pesado. À medida que cada features de transístor e de condutores dentro de um chip vai diminuindo de tamanho e aumentando de número destes problemas de bit-flips por raios cósmicos que nos atravessam em todos os segundos vão fazendo mais estragos. Caso não tenham visto, procurem no youtube por algum vídeo por Cloud Chamber para verem pelos vossos próprios olhos a quantidade de raios cósmicos com partículas de alta energia que nos atravessam em cada segundo vindas do outro lado da galáxia. Só uma pequena fração (baixa probabilidade) é que interage com o hardware, mas a interação está longe de ser nula.
O uso de uma interface de debugger programável como o ptrace() pode também ser usado para "esconder como algum programa verdadeiramente funciona", dividindo-o em duas ou mais entidades externas separadas. Normalmente um programa está num executável ou num conjunto de executáveis que como um todo implementam cada uma das partes de um sistema. Contudo pode-se contemplar por exemplo o caso de um programa que faz a leitura de dados de ficheiros de texto de uma diretoria. Esse programa faz a simples leitura dos dados, contudo existe um outro programa do outro "lado da galáxia" que faz attachment a esse primeiro programa e que coloca um conjunto de breakpoints ao primeiro programa em pontos chave e que vai alterar o seu comportamento em memória ou mesmo no transito dos dados por um registo, fazendo com que os dados sejam descodificados nesse registo por obra e graça do código de um programa externo ao código do programa target. Para quem vir de fora o código do primeiro programa não faz descodificação nenhuma, mas quando executado com o attachment do segundo programa os dados são des-cifrados.
Ficam aqui dois links muito interessantes sobre como usar o ptrace() que é uma System Call do Linux em Rust.
1º Como fazer o trace de System Calls e como ver o conteúdo de registos e memória.Implementing strace in Rusthttps://jakobwaibel.com/2022/06/06/ptrace/2º Como implementar um debugger programaticamente, como colocar breakpoints e alterar o conteúdo de variáveis.System programming in Rust, take 2https://carstein.github.io/2022/05/29/rust-system-programming-2.htmlCumprimentos,
João
