Forem: Márcio Scotuzzi Júnior

Virtualização, processos e fork bomb

Márcio Scotuzzi Júnior — Tue, 10 Jun 2025 14:41:59 +0000

Em maio de 2025, a OpenAI anunciou seu novo agente Codex, cujo diferencial é a execução paralela de tarefas, todas rodando diretamente na nuvem.

Lendo sobre o Codex, comecei a refletir sobre virtualização, processos, contêineres e sobre como, muitas vezes, não paramos para observar mais de perto como certos recursos que usamos no dia a dia funcionam.

A proposta deste texto, então, é "escovar bits" sobre alguns conceitos de sistemas operacionais, partindo da seguinte pergunta: rodar um fork bomb em uma máquina virtual pode comprometer os recursos da máquina hospedeira? E no caso de estarmos usando um contêiner Docker?

Vamos dar um passo atrás

Para alguns, a resposta à pergunta acima pode parecer óbvia. Para outros, nem tanto. Há ainda um terceiro grupo que talvez se pergunte: o que é um fork bomb?

Fork bomb é uma forma de gerar processos recursivamente. E, para garantirmos que estamos todos na mesma página, vamos recorrer ao Tanenbaum e sua definição de processo no livro Sistemas Operacionais Modernos:

O conceito mais central em qualquer sistema operacional é o processo: uma abstração de um programa em execução [...] A ideia principal é que um processo é uma atividade. Ele possui programa, entrada, saída e um estado.

Assim, ao criarmos processos de forma recursiva e indefinida, passamos a consumir os recursos do sistema operacional, o que leva eventualmente ao esgotamento desses recursos e, consequentemente, à "quebra" do sistema.

Para entendermos melhor como esse esgotamento acontece, precisamos detalhar como processos são criados.

Criação de processos

Tanenbaum descreve quatro formas pelas quais um processo pode ser criado:

Durante a inicialização do sistema;
Através da execução de uma chamada de sistema de criação de processo por um processo em execução (este é o ponto central para entender o fork bomb);
A partir de uma solicitação do usuário para criar um novo processo;
Pelo início de uma tarefa em lote (batch job).

Quando um sistema operacional é iniciado, diversos processos são carregados — alguns em primeiro plano, outros em segundo. Isso é necessário para o funcionamento adequado do sistema. A partir daí, todos os novos processos passam a ser criados a partir de processos já existentes. Cada processo possui informações importantes associadas, como endereçamento de memória.

O ponto crucial aqui é que, embora um processo filho compartilhe algumas informações com o processo pai (aquele que o criou), cada processo tem seu próprio espaço de memória para escrita, o que garante que não haverá interferência mútua na execução de suas tarefas. Portanto, a criação de novos processos consome cada vez mais memória da máquina.

E onde entra o fork? Em sistemas baseados em Unix, a chamada de sistema responsável pela criação de novos processos é justamente o fork().

Agora que entendemos como os processos são criados e como o fork bomb pode causar o esgotamento de recursos, vamos analisar se isso também se aplica ao executar o fork bomb em uma máquina virtualizada.

Máquinas virtuais

Uma máquina virtual (VM) é um ambiente isolado que simula um computador físico completo, permitindo a execução de múltiplos sistemas operacionais independentes em um único hardware.

O componente central da virtualização é o hipervisor (ou Virtual Machine Monitor – VMM), que é responsável por criar e gerenciar as VMs. Ele pode atuar diretamente sobre o hardware, sem necessidade de um sistema operacional intermediário, ou funcionar como uma aplicação instalada sobre um sistema operacional convencional. Neste segundo caso, o hipervisor depende do sistema operacional hospedeiro para acessar os recursos de hardware.

Essa segunda abordagem é adotada por softwares como o VirtualBox. Nesses casos, como o sistema hospedeiro intermedia o acesso aos recursos, podemos limitar seu uso por parte da VM. Logo, ao executarmos um fork bomb em uma máquina virtual, o consumo de recursos ficará restrito àqueles previamente configurados — o que impede o esgotamento dos recursos da máquina física.

E no caso do Docker?

Contêineres

O Docker não utiliza hipervisor — e esse é justamente o seu diferencial. Enquanto as VMs simulam um computador completo em um ambiente isolado, os contêineres Docker isolam apenas os processos, utilizando o mesmo kernel da máquina hospedeira e seus recursos (abordagem bare metal).

Portanto, um fork bomb executado dentro de um contêiner Docker pode sim consumir os recursos da máquina hospedeira e causar seu esgotamento.

É o fim?

A explicação acima simplifica a questão ao propor a seguinte dicotomia: fork bomb em VM não é perigoso, mas em contêiner sim.

A realidade, porém, é que em ambos os cenários podemos permitir ou impedir os efeitos de um fork bomb — pois tanto VMs quanto contêineres permitem configurar limites de uso de recursos.

No fundo, o objetivo principal aqui era entender melhor os conceitos por trás da virtualização e dos processos.

Para aprender como criar e se proteger de fork bombs, recomendo este texto.

Embora tenha havido consulta a livros e outros materiais sobre o tema, erros conceituais podem eventualmente aparecer. Fique à vontade para deixar um comentário caso identifique algum equívoco :)

Aprenda padrões de projeto, mas não se apegue às implementações

Márcio Scotuzzi Júnior — Fri, 23 May 2025 14:50:58 +0000

A máxima "você não é o primeiro a passar por isso" se aplica muito bem à programação e, por isso, um bom ponto de partida para resolver um problema é ver como outras pessoas o solucionaram antes de você.

Antes das IAs generativas, o lugar para onde todo dev corria ao pedir ajuda na internet era o Stack Overflow. Em todo o tempo que uso esse site, publiquei pouquíssimas perguntas lá — não por ter lidado com poucos bugs, mas porque a grande maioria das dores de cabeça que tive foram dores de cabeça que outras pessoas já tinham tido, e isso estava muito bem documentado, tanto no Stack Overflow quanto em outros fóruns.

Na engenharia de software, a necessidade de documentar problemas recorrentes e as boas formas de resolvê-los deu origem aos padrões de projeto.

Citando o site Refactoring Guru:

Design patterns are typical solutions to common problems in software design.

Aqui é importante destacar que tais soluções são abordagens comuns para resolver esses problemas, mas não devemos nos apegar à implementação exata. O ideal é avaliar como podemos usar esses padrões para resolver os problemas específicos dos sistemas que desenvolvemos.

Um exemplo real

Atuando como desenvolvedor em uma empresa de crédito, precisei implementar uma funcionalidade de simulação de crédito rural. Sem entrar em detalhes das regras de negócio, o cenário era o seguinte:

O frontend enviava três informações: o tipo de simulação (mensal, trimestral, semestral), o valor simulado e uma taxa opcional (caso não fosse fornecida, cada tipo de simulação tinha uma taxa padrão definida);
Meu backend realizava o cálculo e retornava as informações necessárias, como o ID da simulação, valor da parcela etc.

Meu primeiro pensamento foi usar uma factory, um padrão creacional em que subclasses herdam de uma classe pai que define uma estrutura geral (como métodos), sem se preocupar com a implementação específica de cada uma.

No caso das simulações, a classe pai poderia definir um método para o cálculo das parcelas, e cada uma das três subclasses implementaria esse método de acordo com suas especificações.

Como um bom júnior, caí de cabeça no código e, em pouco tempo, percebi que estava usando Ctrl+C e Ctrl+V demais.

O problema era que a lógica para calcular o valor das parcelas era a mesma; eu só mudava os parâmetros de taxa e prazo com base no tipo de simulação. Ou seja, não precisava de três subclasses implementando o mesmo método da mesma forma. O que eu realmente precisava era instanciar uma única classe com parâmetros diferentes.

Essa foi a solução a que cheguei. Talvez exista uma forma melhor de resolver esse problema — mas o fato é que meus testes passaram, a comunicação com o frontend funcionou, e eu precisava entregar a task. Então subi assim mesmo.

Em resumo, a mensagem que fica é: devemos sim estudar os padrões de projeto, mas é sempre importante parar um minuto para aplicá-los da forma que melhor se encaixe no nosso código — caso contrário, eles mais atrapalham do que ajudam.

Recriando o comando cat do Linux em C

Márcio Scotuzzi Júnior — Tue, 27 Feb 2024 12:25:21 +0000

No dia a dia, nós usuários de Linux costumamos utilizar uma série de programas simples, porém extremamente úteis. Um que eu utilizo com frequência é o cat - que nos permite exibir no terminal o conteúdo de um arquivo. Porém, você já parou para pensar em como esse programinha funciona?

Suponhamos que eu queira conferir o conteúdo do arquivo toc_toc.txt:

Ao chamar o comando cat eu forneço como argumento o arquivo que eu quero exibir e, como resposta, no terminal é exibido o que o tal arquivo contem. Portanto, se quisermos recriar esse comando, o primeiro passo será receber um argumento por linha de comando.

Na linha 5 nós estamos definindo dois parâmetros para a função main:

argc: conta quantos argumentos foram passados pela linha de comando na hora que o programa foi executado;
argv: é um vetor com todos os argumentos passados

Note que todo programa terá, no mínimo, um argumento - o nome do programa. Por isso checamos se o argc é menor do que 2, pois caso seja isso é um sinal de que o nome do arquivo que o cat deverá exibir o conteúdo não foi fornecido. Nesse caso, exibimos uma mensagem informando a maneira correta de utilizar o programa e encerramos a execução com um código de erro.

Se o programa recebeu os devidos argumentos quando foi executado, o próximo passo é abrirmos o arquivo cujo o nome foi informado.

Fazemos isso declarando um ponteiro para um arquivo e abrindo ele em seguida.

Na linha 15 nós checamos se tudo ocorreu de forma adequada na abertura do arquivo. Caso algum problema tenha ocorrido, exibimos uma mensagem de erro e encerramos a exceução do programa.

Por fim, temos um loop que irá ler caracter por caracter do nosso arquivo até chegar ao final - exibindo esses caracteres no terminal.

Após finalizarmos a leitura e exibição do conteúdo do arquivo, nós fechamos o arquivo e encerramos o programa.

Agora é só compilar e testar.

Funciona!!!

Uma coisa importante a dizer é que a implementação do cat original é bem mais complexa (código fonte aqui) e tem 800 linhas. Porém, a ideia dessa implementação que fizemos é apenas entender como certos programas que utilizamos no dia a dia funcionam na sua forma mais básica. Aliás, apesar da nossa implementação ser muito mais simples que a original, se compararmos as saídas do nosso programa e do cat do Linux, vamos ver que ambos produzem a mesma saída.

Tentar recriar esses utilitários de sistema operacional é uma ótima forma de dar os primeiros passos no desenvolvimento baixo nível e aprofundar os conhecimentos em linguagens como C. Por falar em baixo nível, como seria implementar o cat em Assembly? Eu vou fazer os meus testes e volto para te contar.

Fique bem até lá :)

Por que a soma de um int com um float resulta em um float?

Márcio Scotuzzi Júnior — Sun, 18 Feb 2024 23:00:24 +0000

Introdução

Dentro da computação, compiladores é um dos meus assuntos favoritos. Eles são programas responsáveis por traduzir um código escrito em certa linguagem fonte para uma outra linguagem alvo. Geralmente, a linguagem alvo é o conjunto de instruções que o processador da sua máquina é capaz de executar. Além disso, o compilador é o cara responsável por exibir mensagens de erro horrorosas toda vez que a gente faz alguma merda no nosso código (e não adianta mentir, eu sei que você já passou por isso).

Compiladores são fascinantes por si só, mas uma coisa legal sobre estudar esses softwares é o fato de precisarmos resgatar ou aprender sobre conceitos de arquitetura de computadores, sistemas operacionais, estruturas de dados etc. Não só isso, nós nos vemos obrigados e pensar sobre algumas coisas que no dia a dia costumam passar batido. Por exemplo: por que somar um inteiro com um número de ponto flutuante sempre resulta em um número de ponto flutuante?

Entendendo tipos de dados

Você já deve ter estudado os tipos de dados de alguma linguagem: int, float, char, boolean, entre outros. Porém, você já se perguntou o que exatamente são os tipos de dados?

Um tipo de dado nada mais é do que um conjunto de valores que uma variável pode assumir e esse conjunto de valores, por sua vez, compartilham de operações comuns entre eles. Logo, dizer que os valores 17 e 42 são do tipo inteiro, significa que eles pertencem ao mesmo conjunto de valores que uma variável inteira poderá assumir justamente por eles compartilharem as mesmas operações - por exemplo, a soma.

Quando computamos a expressão 17 + 42 estamos somando esses dois valores (e obtendo o resultado 59). Vale dizer que um mesmo operador **(nesse caso, +) **pode representar diferentes operações. Ao computar "olá, " + "mundo!" nós não estamos realizando uma soma, mas sim uma concatenação - embora o operador seja o mesmo, a operação é outra. Como resultado teríamos "olá, mundo!". E se tentarmos usar o operador + com um inteiro e uma string? Obtemos um erro.

No exemplo acima estamos trabalhando com a linguagem Python e você pode reproduzir esse exemplo no próprio IDLE do Python. Note que quando uma string é o primeiro argumento fornecido para o operador +, o erro diz que só é permitido concatenar uma string com outra string. Já quando o primeiro argumento é um inteiro, o erro diz que o tipo de dado dos operandos não são suportados pelo operador. Em ambos os casos, a nossa tentativa é falha, justamente porque, sendo de tipos diferentes, inteiros e strings não compartilham das mesmas operações.

Agora você deve estar pensando, se inteiros e números de ponto flutuante são de tipos diferentes, por que conseguimos somá-los?

Entendendo type casting

Se você já estudou os tipos de dados de alguma linguagem, então deve ter estudado também sobre type casting (ou conversão momentânea de tipos). Basicamente, é quando nós convertemos o tipo de um dado por um instante. Se você já estudou Python, deve ter se deparado com isso:

O que aconteceu aqui? Simples! Por padrão, a função input trata todos os dados como string (exatamente o que eu faço quando vou modelar uma tabela no banco de dados e fico com preguiça de definir o tipo certo para cada coluna). Como já vimos antes, o operador + quando aplicado sobre strings realiza a operação de concatenação, logo, "17" + "42" só pode resultar em 1742. E como lidar com isso? Assim:

Nós usamos a função int para converter o tipo de dado de string para inteiro. Note que isso só foi possível porque a string continha uma representação numérica - experimenta digitar uma letra para ver se o interpretador não grita com você.

Outra coisa importante a se dizer: a conversão de tipos é momentânea e, caso queira persisti-la, deve-se armazenar o dado em uma variável ao realizar a conversão.

Portanto, quando somamos um número inteiro com um número de ponto flutuante, o que acontece é um type casting do int para float. A imagem abaixo mostra um exemplo de como os tipos de dados seguem os mesmos e o casting só ocorre na hora da operação.

Repara em como x se mantem sendo um int, mesmo que para computar o valor de z ele tenha sido convertido para um float.

E sim, eu sei que você já chegou nessa conclusão do type casting sozinho, mas o que talvez não tenha ficado evidente é: por que isso acontece?

Sejamos precisos (tanto quanto se pode)

Eu pretendo escrever um texto só para discutir representação de números de ponto flutuante, mas a densidade desse assunto é proporcional a sua beleza. Portanto, vamos definir algumas coisas mais triviais apenas para podermos responder a pergunta inicial.

Operações com números inteiros são realizadas em uma região diferente das com números reais. Para a primeira, temos a ALU e para a segunda temos a FPU. Isso acontece porque nós não representamos números inteiros da mesma forma que representamos números de ponto flutuante. Quando a conversão de tipos ocorre ao somamrmos um int e um float, a escolha de converter o int para um float e não o contrário, está relacionada justamente com manter a precisão dos valores - pois representar um inteiro como um número real é mais propenso a manter a precisão do que representar um número real como inteiro. Loucura né?

Em resumo, quando somamos 17 + 42.0 a ALU vai se encarregar de transformar essa representação inteira para uma representação de ponto flutuante e irá chamar a FPU para realizar a operação. O resultado final acaba sendo um float porque quem computou o valor foi a FPU - que só trabalha com números de ponto flutuante.

Conclusão

Ufa! Parece que chegamos ao fim. Talvez a minha explicação não tenha sido a melhor ou a mais completa. Além disso, talvez eu tenha cometido algum erro conceitual no caminho. Para ambos os casos, sinta-se livre para deixar um comentário.

No mais, estou indo embora.

Fique bem e até :)