A revista Linux Magazine de fevereiro publicou uma review do Minix 3 contando a história do sistema, diferenças entre o Minix e o Linux, como o sistema funciona basicamente e ainda, juntamente com a review, um artigo do autor do sistema, Andrew S. Tanenbaum, sobre o uso do computador hoje em dia e como a estrutura do Minix pode fazer a diferença levando-se em conta os objetivos dos usuários comuns. A matéria é bem longa - como eu gosto - mas vale à pena cada frase. No fim do post estão os arquivos em PDF da matéria original e da versão traduzida.
Kernel Inteligente
por Rüdiger Weis / Tradução: Luiz Martins
O Linux tem uma longa e tempestuosa relação com outro sistema operacional Unix-like conhecido como Minix. Adrew S. Tanenbaum, notável autor e cientista da computação, lançou a primeira versão do Minix em 1987 como uma ferramenta para ensinar estudantes sobre sistemas operacionais, e esse pequeno e bem documentado sistema rapidamente se tornou popular entre os entusiastas. Numa postagem ao grupo de notícias Minix, um ambicioso graduando finlandês, Linus Torvalds, anunciou o seu próprio sistema experimental em 1991 e contribuidores rapidamente vieram dos postos da comunidade Minix.
Mas Tanenbaum e Torvalds de imediato não se entenderam sobre questões do design. Tanenbaum sem foi favorável à arquitetura de microkernel, uma característica diferente do Minix até hoje (veja o texto "Por que os computadores não conseguem funcionar o tempo todo?"). Linus, por outro lado, fez o Linux com um kernel monolítico, com sistemas de arquivos, drivers e outros componentes incorporados dentro do kernel. Numa famosa postagem ao grupo Minix, o criador do Minix se referiu ao Linux como "... um gigante retrocesso ao anos 70", e uma confiante resposta do jovem Torvalds para esse experiente líder no campo dos sistemas operacionais é a primeira evidência da sua hoje legendária integridade. Apesar de tudo, Linus reconheceu a importância do trabalho de Tanenbaum para a formação de suas próprias idéias. Em sua autobiografia "Just for Fun", Linus se refere ao livro de Tanenbaum "Operating Systems: Design and Implementation" como um livro que mudou sua vida.
O debate entre microkerneis e kerneis monolíticos continua hoje em dia, e assim como o Linux não desapareceu, o Minix muito menos. A versão 3 do sistema operacional Minix foi projetado com o objetivo de criar um sistema que seja mais seguro e confiável do que os sistemas POSIX semelhantes, e uma licença livre estilo BSD faz do último Minix um forte candidato não só para o uso de produção, como também para o uso educacional. O Minix está atraindo até mesmo a atenção de alguns grandes patrocinadores. A União Européia está patrocinando o projeto com vários milhões de euros, e o Google tem uma quantidade de projetos relacionados ao Minix em seu programa "Summer of Code".
O Minix 3 roda tanto em processadores x86 32-bits quanto em várias máquinas virtuais, incluindo Qemu, Xen e VMWare. O sistema operacional inclui um sistema gráfico de janelas (X11), vários editores (Emacs e Vi), shells (incluindo o bash e o Zsh), GCC, linguagens de script, como Python e Perl, e ferramentas de rede - como o SSH. Com um design diminuto e resistente a erros, o Minix é um bom candidato para sistemas embarcados e a sua estabilidade superior tem conduzido a um novo e promissor papel como um sistema de firewall.
Inseguro pelo Design
Os problemas de segurança à frente da atual safra de sistemas operacionais, incluindo o Windows, mas também incluindo o Linux, são resultado de erros de design. Os erros foram herdados, em sua maior parte, de seus predecessores dos anos 60. A maioria desses problemas podem ser atribuídos ao fato de que os desenvolvedores não são perfeitos. Os humanos cometem erros. Claro, seria bom reduzir os números e mitigar os efeitos; entretanto, os programadores frequentemente estão dispostos a comprometer a segurança e um design limpo pela velocidade. Tanenbaum se refere a isso como um "pacto faustiano".
Além dessas questões relacionadas à dimensão, designs monolíticos também estão propensos a problemas estruturais inerentes: qualquer erro é capaz de comprometer o sistema como um todo. Um erro de design fundamental é que os sistemas operacionais atuais não seguem o Princípio da Menor Autoridade (POLA em inglês). Para esclarece isso, o POLA afirma que os desenvolvedores devem distribuir os sistemas sobre uma quantidade de módulos a fim de que um erro num módulo não comprometa a segurança e estabilidade dos outros módulos. Eles também devem garantir que cada módulo tenha apenas os direitos que ele realmente necessite para finalizar as funções designadas.
O contínuo crescimento do sistema operacional vem com a integração de novos drivers. Sistemas monolíticos incorporam drivers de dispositivos dentro do kernel, o que significa que um erro de driver pode comprometer todo o sistema. Drivers de código fonte fechado em particular colocam em risco a segurança do sistema. De acordo com Tanenbaum, incorporar um driver fechado no kernel é como aceitar um pacote lacrado de um estranho e levá-lo à cabine do avião.
Figura 1: O microkernel do Minix encapsula vários subsitemas na Área do Ususário, incluindo drivers, o sistema de arquivos e a pilha de rede. O kernel roda apenas funções críticas como operações de I/O, agendadores e gerenciamento de memória.
Arquitetura Transparente
O Minix é, provavelmente, o sistema operacional existente mais bem documentado. O "The Minix Book" de Tanenbaum e Woodhull é a referência principal. Inúmeras publicações sobre novas funções e pesquisas em andamento são encontradas na página principal do Minix. O Minix obedece ao padrãoPSIX IEEE 1003.2-1996 e os desenvolvedores já portaram muitos programas Unix para o Minix.
A Diferença do Minix
O Minix 3 está nos currículos de muitas universidades e muitas gerações de estudante já examinaram os poucos milhares de linhas do código do Minix e consertaram muitos erros. A arquitetura em microkernel implementa os drivers como processos de modos de usuários separados que não permitem executar comandos privilegiados ou operações de I/O (Entrada e Saída) ou escrever diretamente na memória. Em vez disso, essas operações são feitas por chamadas fiscalizáveis do kernel (ver Figura 1).
O Minix 3 utiliza mensagens de largura definida para a comunicação de processos. Esse design simplifica a estrutura do código e ajuda a mitigar o perigo de transbordamento de dados. O sistema de arquivos do Minix é executado como um simples processo de usuário. Já que ocupa cerca de 8.200 linhas do código da área de usuário, mas sem código do kernel, odebug nele é feito facilmente.
Um componente inovador, o "servidor de reincarnação", aumenta a confiabilidade do sistema Minix de servir como responsável por todos os servidores e drivers. Ele detecta erros muito rapidamente e monitora continuamente a função de processo críticos, reiniciando processos inoperantes quando necessário para manter o sistema rodando.
O Projeto Minix Firewall
Filtros de pacotes são um componente do sistema em risco. Apesar da excelente qualidade do Linux em implementações Nelfilter, várias questões de segurança surgiram no passado. Se um subsistema desse tipo está rodando no kernel Linux, ele estará colocando em risco a segurança do sistema. Com base no trabalho do grupo de Tanenbaum, a Universidade Técnica em Ciência Aplicada de Berlim portou o famosoframework Netfilter para o Minix 3.
Novamente, a estabilidade da arquitetura em microkernel oferece benefícios adicionais. No Linux, um invasor que tenha sucesso em provocar um erro - por exemplo, explorando um transbordamento de dados na função do_replace () - pode deixar um firewall Linux de joelhos. No Minix 3, um único processo de usuário poderia colapsar sem comprometer a segurança do sistema. O servidor de reincarnação poderia simplesmente reiniciar o processo.
As diferenças se tornam ainda mais aparente se um invasor tem sucesso ao executar um código. No Minix, um processo de usuário seqüestrado ainda é um problema. mas o efeito é muito mais brando graças à isolação.
Até a Microsoft está explorando o próprio sistema em microkernel, chamado Singularity. Embora o Minix tenha jogado o jogo do microkernel por anos, o seu maior obstáculo para se tornar mais conhecido sempre foi as suas licenças não livres. Agora que o Minix 3 está sendo distribuído sob uma licença BSD e as extensões de firewall estão disponíveis sob GPL, os pesquisadores daTFH Berlin estão trabalhando na exploração do potencial do Minix como um firewall virtualizado. Estabilidade, um design diminuto e um novo modelo de licenciamento deram ao Minix 3 um grande potencial de crescimento, especialmente em sistemas embarcados.
Figura 2: O Minix é bastante espartano na inicialização. Dito isso, a versão 3.1.2a incluí uma interface X11 e ferramentas para desenvolvedores.
Por que os computadores não conseguem funcionar o tempo todo?
Por Andrew S. Tanenbaum
Os usuários de computador estão mudando. Dez anos atrás, a maioria dos usuários de computador eram pessoas jovens ou profissionais com muita experiência técnica. Quando as coisas davam errado - e frequentemente davam -, eles sabiam como consertar as coisas. Hoje em dia, o usuário comum é muito menos sofisticado, talvez um garotinha de 12 anos ou um vovô. A maioria deles sabe tanto sobre arrumar computadores quando umnerd de computadores sabe sobre consertar o próprio carro. O que eles querem mais do que qualquer outra coisa é um computador que funcione o tempo todo, sem falhas ou erros.
Muitos usuários comparam automaticamente seus computadores com seus aparelhos de televisão. Ambos estão repletos de eletrônicos mágicos e têm telas grandes. A maioria dos usuários tem um modelo implícito de um aparelho de televisão: 1) você compra o aparelho; 2) o conecta; 3) ele funciona perfeitamente sem qualquer falha pelos próximos 10 anos. Eles esperam isso de um computador e quando não conseguem isso, ficam frustrados. Quando pessoas com alguma experiência em computação diz a eles: "Se Deus quisesse que os computadores funcionassem todo o tempo, Ele não teria inventado o botão RESET". Eles não se impressionam.
Na falta de uma definição melhor de confiabilidade, vamos adotar a seguinte: Um dispositivo é dito ser confiável se 99% dos usuários nunca experimentar qualquer falha durante o período de vida do próprio dispositivo. Por essa definição, virtualmente, nenhum computador é confiável, enquanto a maioria dasTV's, iPods , câmeras digitais, câmeras de vídeo, etc são. Viciados em tecnologia estão dispostos a perdoar um computador que falhe uma ou duas vezes por ano; usuários comuns não.
Usuários domésticos não são os únicos incomodados pela pobre confiabilidade dos computadores. Até mesmo em configurações altamente técnicas, a baixa confiabilidade dos computadores é um problema. Empresas como Google eAmazon , com centenas de servidores, experimentam várias falhas todos os dias. Eles aprenderam a conviver com isso, mas certamente iriam preferir sistemas que simplesmente funcionassem o tempo todo. Infelizmente, os softwares atuais os deixam na mão.
O problema básico é que o software contém bugs, e quanto mais softwares existem, mais bugs irão existir. Vários estudos têm mostrado que o número de bugs por milhar de linhas de código (KLoC) variam de 1 a 10 em grandes sistemas de produção. Um pedaço de um software bem escrito pode ter 2 bugs por KLoC com o passar do tempo, mas não menos. Um sistema operacional com, digamos, 4 milhões de linhas de código é, portanto, suscetível a ter ao menos 8000 bugs. Nem todos são fatais, mas alguns serão. Um estudo da Universidade de Stanford mostrou que drivers de dispositivos - que compõem 70% da base de códigos de um típico sistema operacional - têm taxas de bugs de 3 a 7 vezes maiores do que o resto do sistema. Drivers de dispositivos tem uma alta taxa de bugs porque (1) são mais complexos e (2) são menos examinados. Enquanto muitas pessoas estudam o agendador, poucas observam o driver da impressora.
A Solução: Kerneis Menores
A solução para esse problema é tirar o código do kernel, onde ele pode causar o máximo de estrago, e colocá-lo nos processos da área de usuário, onde bugs não conseguem causar falhas no sistema. É assim que o Minix foi projetado. O atual sistema Minix é o [segundo] sucessor do Minix original, que foi lançado originalmente em 1987 como um sistema operacional educacional mas tem sido corrigido desde então a fim de se tornar um sistema altamente confiável e auto-imune. O que segue é um breve descrição da arquitetura do Minix; você pode encontrar mais detalhes em http://www.minix3.org.
O Minix 3 foi projetado para rodar com o menor código possível no modo kernel, onde os bugs podem ser facilmente fatais. Em vez de 3 ou 4 milhões de linhas de código no kernel, o Minix 3 tem cerca de 5000 linhas de código no kernel. Às vezes kerneis tão pequenos são chamados de microkerneis. Eles lidam com o gerenciamento de processo de baixo nível - agendamento, interrupções e o relógio - e fornecem alguns serviços de baixo nível para componente da área de usuário.
O volume do sistema operacional roda como uma coleção de drivers e servidores de dispositivo, cada um rodando como um processo comum na área de usuário com privilégios restritos. Nenhum desses servidores e drivers rodam como super-usuário ou equivalente. Eles não podem nem mesmo acessar os dispositivos de entrada e saída ou a unidade de gerenciamento de memória diretamente (MMU).
Eles têm de usar os serviços do kernel para ler e escrever no hardware. A camada de processos rodando no modo de usuário acima do kernel consiste de drivers de dispositivos - com drivers de discos, drivers de rede e todos os outros drivers - rodando como processos separados protegidos pelaMMU do hardware a fim de que eles não possam executar quaisquer instruções privilegiadas e não possam escrever ou ler qualquer memória, exceto a própria.
Acima da camada de drivers vem a camada de servidores - com um servidor de arquivos, um servidor de processos e outros servidores. Os servidores fazem uso tanto dos drivers quanto dos serviços do kernel. Por exemplo, para ler de um arquivo, um processo de usuário manda uma mensagem para o servidor de arquivos, que então manda uma mensagem para o driver do disco buscar os blocos necessários. Quando o sistema de arquivos os tem no cache de dados, ele chama o kernel para movê-los para o espaço do endereço do usuário.
Além desses servidores, há um outro servidor chamado de servidor de reincarnação. O servidor de reincarnação é o responsável por todos processos de drivers e servidores e monitora o comportamento deles. Se ele descobre um processo que não está respondendo a seus pings, ele inicia uma nova copia pelo disco (exceto para o driver de disco, que é vigiado na RAM). O sistema foi projetado para que muitos (mas não todos) dos drivers e servidores críticos possam ser substituídos automaticamente enquanto o sistema está operante, sem perturbar os processos de usuário ou mesmo notificar o usuário. Dessa maneira, o sistema é auto-imune.
Para testar se essas idéias funcionam na prática, fizemos o seguinte experimento. Iniciamos um processo defeituoso por injection que sobrescreveu 100 instruções no binário do driver da rede para ver o que aconteceria se um deles fosse executado. Se nada acontecesse por alguns segundos, outras 100 instruções seriam introduzidas e assim por diante. Ao todo, injetamos 800.000 processos defeituosos em cada um dos três drivers de rede diferentes e causou 18.000 erros de driver. Em todos os casos, o driver foi substituído pelo servidor de reincarnação. Apesar de injetar 2.4 milhões de processos defeituosos no sistema, nenhuma vez sistema operacional falhou. Não precisa dizer que se um erro faltal ocorre num driver Linux ou Windows rodando no kernel, o sistema operacional por falharia completo instantaneamente.
Existe uma desvantagem nessa abordagem? Sim. Há uma meta de desempenho. Nós não medimos isso extensivamente, mas o grupo de pesquisa em Karlshure (Universidade de Karlshure, Alemanha), que desenvolveu o próprio microkernel, o L4, e depois rodou Linux sobre ele como um simples processo de usuário, foi capaz de atingir uma meta de desempenho de 5%. Acreditamos que, se colocarmos alguns esforços nele, poderemos alcançar a taxa entre 5% e 10% também. A performance não tem sido uma prioridade para nós, assim como a maioria dos usuários que lêem seus emails e entram no Facebook não estão limitados pela performance do CPU. O que eles querem, no entanto, é um sistema que funcione o tempo todo.
Se os microkerneis são tão confiáveis, por que todos não os usam?
Na verdade, todos usam. Provavelmente, você roda vários deles. O seu telefone celular, por exemplo, é um pequeno computador normal e há uma boa chance dele rodar o L4 ou o Symbian ou outro microkernel. Os roteadores de alta performance da Cisco usam. Nos mercados aeroespacial e militar, onde a confiabilidade é primordial, o Green Hills, outro microkernel, é amplamente usado. O PikeOS e o QNX também são microkerneis amplamente usados em sistemas embarcados e industriais. Em outras palavras, quando se trata de sistemas que "funcionem o tempo todo", as pessoas se voltam para os microkerneis. Para saber mais sobre esse assunto, acesse www.cs.vu.nl/~ast/reliable-os/.
Sendo assim, é o que acreditamos, baseado em várias conversas com usuário não técnicos, que o que eles querem acima de qualquer coisa é um sistema que funcione perfeitamente todo o tempo. Eles têm uma baixa tolerância para sistemas não confiáveis mas atualmente eles não têm escolhas. Acreditamos que sistemas baseados em microkerneis podem indicar o caminho para sistemas mais confiáveis.
Rüdiger Weis é professor de programação de sistemas na THF Berlin. Entre 2002 e 2005, ele esteve envolvido com uma pesquisa de pós-doutorado sistemas operacionais seguros sob a supervisão do Professor Andrew S. Tanenbaum na Vrije Universiteit, Amsterdã.
PDF (Português)
Pablo Hess, editor da Linux Magazine brasileira, me informou pelos comentário que o artigo do Tanenbaum já tinha sido traduzido pela revista. Não tinha conhecimento. Se você não entendeu alguma parte da minha tradução ou simplesmente não gostou, acesse AQUI a versão oficial do artigo publicado pela própria Linux Magazine Brasil.
-*-*-*-*-*-*-*-*-*-*-*-*-
Kernel Inteligente
por Rüdiger Weis / Tradução: Luiz Martins
O Linux tem uma longa e tempestuosa relação com outro sistema operacional Unix-like conhecido como Minix. Adrew S. Tanenbaum, notável autor e cientista da computação, lançou a primeira versão do Minix em 1987 como uma ferramenta para ensinar estudantes sobre sistemas operacionais, e esse pequeno e bem documentado sistema rapidamente se tornou popular entre os entusiastas. Numa postagem ao grupo de notícias Minix, um ambicioso graduando finlandês, Linus Torvalds, anunciou o seu próprio sistema experimental em 1991 e contribuidores rapidamente vieram dos postos da comunidade Minix.
Mas Tanenbaum e Torvalds de imediato não se entenderam sobre questões do design. Tanenbaum sem foi favorável à arquitetura de microkernel, uma característica diferente do Minix até hoje (veja o texto "Por que os computadores não conseguem funcionar o tempo todo?"). Linus, por outro lado, fez o Linux com um kernel monolítico, com sistemas de arquivos, drivers e outros componentes incorporados dentro do kernel. Numa famosa postagem ao grupo Minix, o criador do Minix se referiu ao Linux como "... um gigante retrocesso ao anos 70", e uma confiante resposta do jovem Torvalds para esse experiente líder no campo dos sistemas operacionais é a primeira evidência da sua hoje legendária integridade. Apesar de tudo, Linus reconheceu a importância do trabalho de Tanenbaum para a formação de suas próprias idéias. Em sua autobiografia "Just for Fun", Linus se refere ao livro de Tanenbaum "Operating Systems: Design and Implementation" como um livro que mudou sua vida.
O debate entre microkerneis e kerneis monolíticos continua hoje em dia, e assim como o Linux não desapareceu, o Minix muito menos. A versão 3 do sistema operacional Minix foi projetado com o objetivo de criar um sistema que seja mais seguro e confiável do que os sistemas POSIX semelhantes, e uma licença livre estilo BSD faz do último Minix um forte candidato não só para o uso de produção, como também para o uso educacional. O Minix está atraindo até mesmo a atenção de alguns grandes patrocinadores. A União Européia está patrocinando o projeto com vários milhões de euros, e o Google tem uma quantidade de projetos relacionados ao Minix em seu programa "Summer of Code".
O Minix 3 roda tanto em processadores x86 32-bits quanto em várias máquinas virtuais, incluindo Qemu, Xen e VMWare. O sistema operacional inclui um sistema gráfico de janelas (X11), vários editores (Emacs e Vi), shells (incluindo o bash e o Zsh), GCC, linguagens de script, como Python e Perl, e ferramentas de rede - como o SSH. Com um design diminuto e resistente a erros, o Minix é um bom candidato para sistemas embarcados e a sua estabilidade superior tem conduzido a um novo e promissor papel como um sistema de firewall.
Inseguro pelo Design
Os problemas de segurança à frente da atual safra de sistemas operacionais, incluindo o Windows, mas também incluindo o Linux, são resultado de erros de design. Os erros foram herdados, em sua maior parte, de seus predecessores dos anos 60. A maioria desses problemas podem ser atribuídos ao fato de que os desenvolvedores não são perfeitos. Os humanos cometem erros. Claro, seria bom reduzir os números e mitigar os efeitos; entretanto, os programadores frequentemente estão dispostos a comprometer a segurança e um design limpo pela velocidade. Tanenbaum se refere a isso como um "pacto faustiano".
Além dessas questões relacionadas à dimensão, designs monolíticos também estão propensos a problemas estruturais inerentes: qualquer erro é capaz de comprometer o sistema como um todo. Um erro de design fundamental é que os sistemas operacionais atuais não seguem o Princípio da Menor Autoridade (POLA em inglês). Para esclarece isso, o POLA afirma que os desenvolvedores devem distribuir os sistemas sobre uma quantidade de módulos a fim de que um erro num módulo não comprometa a segurança e estabilidade dos outros módulos. Eles também devem garantir que cada módulo tenha apenas os direitos que ele realmente necessite para finalizar as funções designadas.
O contínuo crescimento do sistema operacional vem com a integração de novos drivers. Sistemas monolíticos incorporam drivers de dispositivos dentro do kernel, o que significa que um erro de driver pode comprometer todo o sistema. Drivers de código fonte fechado em particular colocam em risco a segurança do sistema. De acordo com Tanenbaum, incorporar um driver fechado no kernel é como aceitar um pacote lacrado de um estranho e levá-lo à cabine do avião.
Figura 1: O microkernel do Minix encapsula vários subsitemas na Área do Ususário, incluindo drivers, o sistema de arquivos e a pilha de rede. O kernel roda apenas funções críticas como operações de I/O, agendadores e gerenciamento de memória.
Arquitetura Transparente
O Minix é, provavelmente, o sistema operacional existente mais bem documentado. O "The Minix Book" de Tanenbaum e Woodhull é a referência principal. Inúmeras publicações sobre novas funções e pesquisas em andamento são encontradas na página principal do Minix. O Minix obedece ao padrãoPSIX IEEE 1003.2-1996 e os desenvolvedores já portaram muitos programas Unix para o Minix.
A Diferença do Minix
O Minix 3 está nos currículos de muitas universidades e muitas gerações de estudante já examinaram os poucos milhares de linhas do código do Minix e consertaram muitos erros. A arquitetura em microkernel implementa os drivers como processos de modos de usuários separados que não permitem executar comandos privilegiados ou operações de I/O (Entrada e Saída) ou escrever diretamente na memória. Em vez disso, essas operações são feitas por chamadas fiscalizáveis do kernel (ver Figura 1).
O Minix 3 utiliza mensagens de largura definida para a comunicação de processos. Esse design simplifica a estrutura do código e ajuda a mitigar o perigo de transbordamento de dados. O sistema de arquivos do Minix é executado como um simples processo de usuário. Já que ocupa cerca de 8.200 linhas do código da área de usuário, mas sem código do kernel, odebug nele é feito facilmente.
Um componente inovador, o "servidor de reincarnação", aumenta a confiabilidade do sistema Minix de servir como responsável por todos os servidores e drivers. Ele detecta erros muito rapidamente e monitora continuamente a função de processo críticos, reiniciando processos inoperantes quando necessário para manter o sistema rodando.
O Projeto Minix Firewall
Filtros de pacotes são um componente do sistema em risco. Apesar da excelente qualidade do Linux em implementações Nelfilter, várias questões de segurança surgiram no passado. Se um subsistema desse tipo está rodando no kernel Linux, ele estará colocando em risco a segurança do sistema. Com base no trabalho do grupo de Tanenbaum, a Universidade Técnica em Ciência Aplicada de Berlim portou o famosoframework Netfilter para o Minix 3.
Novamente, a estabilidade da arquitetura em microkernel oferece benefícios adicionais. No Linux, um invasor que tenha sucesso em provocar um erro - por exemplo, explorando um transbordamento de dados na função do_replace () - pode deixar um firewall Linux de joelhos. No Minix 3, um único processo de usuário poderia colapsar sem comprometer a segurança do sistema. O servidor de reincarnação poderia simplesmente reiniciar o processo.
As diferenças se tornam ainda mais aparente se um invasor tem sucesso ao executar um código. No Minix, um processo de usuário seqüestrado ainda é um problema. mas o efeito é muito mais brando graças à isolação.
Até a Microsoft está explorando o próprio sistema em microkernel, chamado Singularity. Embora o Minix tenha jogado o jogo do microkernel por anos, o seu maior obstáculo para se tornar mais conhecido sempre foi as suas licenças não livres. Agora que o Minix 3 está sendo distribuído sob uma licença BSD e as extensões de firewall estão disponíveis sob GPL, os pesquisadores daTFH Berlin estão trabalhando na exploração do potencial do Minix como um firewall virtualizado. Estabilidade, um design diminuto e um novo modelo de licenciamento deram ao Minix 3 um grande potencial de crescimento, especialmente em sistemas embarcados.
Figura 2: O Minix é bastante espartano na inicialização. Dito isso, a versão 3.1.2a incluí uma interface X11 e ferramentas para desenvolvedores.
Por que os computadores não conseguem funcionar o tempo todo?
Por Andrew S. Tanenbaum
Os usuários de computador estão mudando. Dez anos atrás, a maioria dos usuários de computador eram pessoas jovens ou profissionais com muita experiência técnica. Quando as coisas davam errado - e frequentemente davam -, eles sabiam como consertar as coisas. Hoje em dia, o usuário comum é muito menos sofisticado, talvez um garotinha de 12 anos ou um vovô. A maioria deles sabe tanto sobre arrumar computadores quando umnerd de computadores sabe sobre consertar o próprio carro. O que eles querem mais do que qualquer outra coisa é um computador que funcione o tempo todo, sem falhas ou erros.
Muitos usuários comparam automaticamente seus computadores com seus aparelhos de televisão. Ambos estão repletos de eletrônicos mágicos e têm telas grandes. A maioria dos usuários tem um modelo implícito de um aparelho de televisão: 1) você compra o aparelho; 2) o conecta; 3) ele funciona perfeitamente sem qualquer falha pelos próximos 10 anos. Eles esperam isso de um computador e quando não conseguem isso, ficam frustrados. Quando pessoas com alguma experiência em computação diz a eles: "Se Deus quisesse que os computadores funcionassem todo o tempo, Ele não teria inventado o botão RESET". Eles não se impressionam.
Na falta de uma definição melhor de confiabilidade, vamos adotar a seguinte: Um dispositivo é dito ser confiável se 99% dos usuários nunca experimentar qualquer falha durante o período de vida do próprio dispositivo. Por essa definição, virtualmente, nenhum computador é confiável, enquanto a maioria dasTV's, iPods , câmeras digitais, câmeras de vídeo, etc são. Viciados em tecnologia estão dispostos a perdoar um computador que falhe uma ou duas vezes por ano; usuários comuns não.
Usuários domésticos não são os únicos incomodados pela pobre confiabilidade dos computadores. Até mesmo em configurações altamente técnicas, a baixa confiabilidade dos computadores é um problema. Empresas como Google eAmazon , com centenas de servidores, experimentam várias falhas todos os dias. Eles aprenderam a conviver com isso, mas certamente iriam preferir sistemas que simplesmente funcionassem o tempo todo. Infelizmente, os softwares atuais os deixam na mão.
O problema básico é que o software contém bugs, e quanto mais softwares existem, mais bugs irão existir. Vários estudos têm mostrado que o número de bugs por milhar de linhas de código (KLoC) variam de 1 a 10 em grandes sistemas de produção. Um pedaço de um software bem escrito pode ter 2 bugs por KLoC com o passar do tempo, mas não menos. Um sistema operacional com, digamos, 4 milhões de linhas de código é, portanto, suscetível a ter ao menos 8000 bugs. Nem todos são fatais, mas alguns serão. Um estudo da Universidade de Stanford mostrou que drivers de dispositivos - que compõem 70% da base de códigos de um típico sistema operacional - têm taxas de bugs de 3 a 7 vezes maiores do que o resto do sistema. Drivers de dispositivos tem uma alta taxa de bugs porque (1) são mais complexos e (2) são menos examinados. Enquanto muitas pessoas estudam o agendador, poucas observam o driver da impressora.
A Solução: Kerneis Menores
A solução para esse problema é tirar o código do kernel, onde ele pode causar o máximo de estrago, e colocá-lo nos processos da área de usuário, onde bugs não conseguem causar falhas no sistema. É assim que o Minix foi projetado. O atual sistema Minix é o [segundo] sucessor do Minix original, que foi lançado originalmente em 1987 como um sistema operacional educacional mas tem sido corrigido desde então a fim de se tornar um sistema altamente confiável e auto-imune. O que segue é um breve descrição da arquitetura do Minix; você pode encontrar mais detalhes em http://www.minix3.org.
O Minix 3 foi projetado para rodar com o menor código possível no modo kernel, onde os bugs podem ser facilmente fatais. Em vez de 3 ou 4 milhões de linhas de código no kernel, o Minix 3 tem cerca de 5000 linhas de código no kernel. Às vezes kerneis tão pequenos são chamados de microkerneis. Eles lidam com o gerenciamento de processo de baixo nível - agendamento, interrupções e o relógio - e fornecem alguns serviços de baixo nível para componente da área de usuário.
O volume do sistema operacional roda como uma coleção de drivers e servidores de dispositivo, cada um rodando como um processo comum na área de usuário com privilégios restritos. Nenhum desses servidores e drivers rodam como super-usuário ou equivalente. Eles não podem nem mesmo acessar os dispositivos de entrada e saída ou a unidade de gerenciamento de memória diretamente (MMU).
Eles têm de usar os serviços do kernel para ler e escrever no hardware. A camada de processos rodando no modo de usuário acima do kernel consiste de drivers de dispositivos - com drivers de discos, drivers de rede e todos os outros drivers - rodando como processos separados protegidos pelaMMU do hardware a fim de que eles não possam executar quaisquer instruções privilegiadas e não possam escrever ou ler qualquer memória, exceto a própria.
Acima da camada de drivers vem a camada de servidores - com um servidor de arquivos, um servidor de processos e outros servidores. Os servidores fazem uso tanto dos drivers quanto dos serviços do kernel. Por exemplo, para ler de um arquivo, um processo de usuário manda uma mensagem para o servidor de arquivos, que então manda uma mensagem para o driver do disco buscar os blocos necessários. Quando o sistema de arquivos os tem no cache de dados, ele chama o kernel para movê-los para o espaço do endereço do usuário.
Além desses servidores, há um outro servidor chamado de servidor de reincarnação. O servidor de reincarnação é o responsável por todos processos de drivers e servidores e monitora o comportamento deles. Se ele descobre um processo que não está respondendo a seus pings, ele inicia uma nova copia pelo disco (exceto para o driver de disco, que é vigiado na RAM). O sistema foi projetado para que muitos (mas não todos) dos drivers e servidores críticos possam ser substituídos automaticamente enquanto o sistema está operante, sem perturbar os processos de usuário ou mesmo notificar o usuário. Dessa maneira, o sistema é auto-imune.
Para testar se essas idéias funcionam na prática, fizemos o seguinte experimento. Iniciamos um processo defeituoso por injection que sobrescreveu 100 instruções no binário do driver da rede para ver o que aconteceria se um deles fosse executado. Se nada acontecesse por alguns segundos, outras 100 instruções seriam introduzidas e assim por diante. Ao todo, injetamos 800.000 processos defeituosos em cada um dos três drivers de rede diferentes e causou 18.000 erros de driver. Em todos os casos, o driver foi substituído pelo servidor de reincarnação. Apesar de injetar 2.4 milhões de processos defeituosos no sistema, nenhuma vez sistema operacional falhou. Não precisa dizer que se um erro faltal ocorre num driver Linux ou Windows rodando no kernel, o sistema operacional por falharia completo instantaneamente.
Existe uma desvantagem nessa abordagem? Sim. Há uma meta de desempenho. Nós não medimos isso extensivamente, mas o grupo de pesquisa em Karlshure (Universidade de Karlshure, Alemanha), que desenvolveu o próprio microkernel, o L4, e depois rodou Linux sobre ele como um simples processo de usuário, foi capaz de atingir uma meta de desempenho de 5%. Acreditamos que, se colocarmos alguns esforços nele, poderemos alcançar a taxa entre 5% e 10% também. A performance não tem sido uma prioridade para nós, assim como a maioria dos usuários que lêem seus emails e entram no Facebook não estão limitados pela performance do CPU. O que eles querem, no entanto, é um sistema que funcione o tempo todo.
Se os microkerneis são tão confiáveis, por que todos não os usam?
Na verdade, todos usam. Provavelmente, você roda vários deles. O seu telefone celular, por exemplo, é um pequeno computador normal e há uma boa chance dele rodar o L4 ou o Symbian ou outro microkernel. Os roteadores de alta performance da Cisco usam. Nos mercados aeroespacial e militar, onde a confiabilidade é primordial, o Green Hills, outro microkernel, é amplamente usado. O PikeOS e o QNX também são microkerneis amplamente usados em sistemas embarcados e industriais. Em outras palavras, quando se trata de sistemas que "funcionem o tempo todo", as pessoas se voltam para os microkerneis. Para saber mais sobre esse assunto, acesse www.cs.vu.nl/~ast/reliable-os/.
Sendo assim, é o que acreditamos, baseado em várias conversas com usuário não técnicos, que o que eles querem acima de qualquer coisa é um sistema que funcione perfeitamente todo o tempo. Eles têm uma baixa tolerância para sistemas não confiáveis mas atualmente eles não têm escolhas. Acreditamos que sistemas baseados em microkerneis podem indicar o caminho para sistemas mais confiáveis.
Rüdiger Weis é professor de programação de sistemas na THF Berlin. Entre 2002 e 2005, ele esteve envolvido com uma pesquisa de pós-doutorado sistemas operacionais seguros sob a supervisão do Professor Andrew S. Tanenbaum na Vrije Universiteit, Amsterdã.
-*-*-*-*-*-*-*-*-*-*-*-*-
PDF (Inglês)PDF (Português)
-*-*-*-*-*-*-*-*-*-*-*-*-
Pablo Hess, editor da Linux Magazine brasileira, me informou pelos comentário que o artigo do Tanenbaum já tinha sido traduzido pela revista. Não tinha conhecimento. Se você não entendeu alguma parte da minha tradução ou simplesmente não gostou, acesse AQUI a versão oficial do artigo publicado pela própria Linux Magazine Brasil.
