Minix 3 - Minix 3
 | |
| |
| Desenvolvedor | Andrew S. Tanenbaum et al. |
|---|---|
| Escrito em | C , linguagem assembly |
| Família OS | Tipo Unix |
| Estado de trabalho | Abandonado |
| Modelo fonte | Código aberto |
| lançamento inicial | 24 de outubro de 2005 |
| Repositório | |
| Alvo de marketing | Sistemas embarcados , educação |
| Disponível em | inglês |
| Plataformas | IA-32 , ARM |
| Tipo de kernel | Microkernel |
| Userland | MINIX, NetBSD |
Interface de usuário padrão |
cinza |
| Licença | 2005: BSD-3-Cláusula Original: BSD-3-Cláusula |
| Precedido por | Minix 1.0, 1.5 e 2.0 |
| Website oficial | www |
Minix 3 é um projeto para criar um sistema operacional semelhante ao Unix pequeno, de alta disponibilidade e alto funcionamento . É publicado sob uma licença BSD-3-Clause e é um projeto sucessor das versões anteriores, Minix 1 e 2.
O principal objetivo do projeto é que o sistema seja tolerante a falhas , detectando e reparando suas próprias falhas em tempo real, sem intervenção do usuário. Os principais usos do sistema são sistemas integrados e educação.
A partir de 2017, o MINIX 3 oferece suporte aos processadores de arquitetura IA-32 e ARM . Ele também pode ser executado em emuladores ou máquinas virtuais , como Bochs , VMware Workstation , Microsoft Virtual PC , Oracle VirtualBox e QEMU . Uma porta para a arquitetura PowerPC está em desenvolvimento.
A distribuição vem em um live CD e pode ser baixada como uma imagem de stick USB live . A versão mais recente é "minix_R3.4.0rc6-d5e4fc0.iso.bz2" (9 de maio de 2017).
Acredita-se que o MINIX 3 seja usado no Intel Management Engine (ME) encontrado no Platform Controller Hub da Intel, começando com a introdução do ME 11, que é usado com os processadores Skylake e Kaby Lake .
Seu uso no Intel ME pode torná-lo o sistema operacional mais usado em processadores x86 / AMD64 a partir de 2015, com mais instalações do que Microsoft Windows, Linux ou macOS.
Objetivos do projeto
Refletindo sobre a natureza dos sistemas monolíticos baseados em kernel , onde um driver (que tem, de acordo com o criador do MINIX Tanenbaum , aproximadamente 3-7 vezes mais bugs que um programa normal) pode derrubar todo o sistema, o MINIX 3 visa criar um sistema operacional sistema que é um "clone do Unix confiável, auto-reparador e multiservidor".
Para conseguir isso, o código em execução no kernel deve ser mínimo, com o servidor de arquivos, o servidor de processos e cada driver de dispositivo em execução como processos de modo de usuário separados. Cada driver é monitorado cuidadosamente por uma parte do sistema chamada servidor de reencarnação . Se um driver não responder aos pings desse servidor, ele será encerrado e substituído por uma nova cópia do driver.
Em um sistema monolítico, um bug em um driver pode facilmente travar todo o kernel. É muito menos provável que isso ocorra no MINIX 3.
História
| Versão | Data de lançamento | Descrição |
|---|---|---|
| 3.1.0 ( OSDI3 ) |
18/10/2005 |
|
| 3.1.1 (SOSP) |
24/10/2005 |
|
| 3.1.2 | 18/04/2006 |
|
| 3.1.2a | 29/05/2006 |
|
| 3.1.3 | 13/04/2007 |
|
| 3.1.3a | 08/06/2007 |
|
| 3.1.4 | 09/06/2009 |
|
| 3.1.5 | 05-11-2009 |
|
| 3.1.6 | 08/02/2010 |
|
| 3.1.7 | 16/06/2010 |
|
| 3.1.8 | 04/10/2010 | |
| 3.2.0 | 29/02/2012 |
|
| 3.2.1 | 21/02/2013 |
|
| 3.3.0 | 15/09/2014 |
|
| 3.4.0 rc6 | 09/05/2017 | ? |
|
||
O MINIX 3 foi anunciado publicamente em 24 de outubro de 2005 por Andrew Tanenbaum durante seu discurso principal na conferência de Princípios de Sistemas Operacionais do Simpósio da Association for Computing Machinery (ACM). Embora ainda sirva como um exemplo para a nova edição do livro de Tanenbaum e Woodhull, ele foi totalmente redesenhado para ser "utilizável como um sistema sério em computadores embarcados e com recursos limitados e para aplicativos que exigem alta confiabilidade".
Inicialmente lançado sob a mesma licença BSD-3-Clause que o MINIX foi licenciado desde 2000. No final de 2005, o proprietário dos direitos autorais foi alterado e uma quarta cláusula foi adicionada.
Políticas de confiabilidade
Um dos principais objetivos do MINIX 3 é a confiabilidade. Abaixo, alguns dos princípios mais importantes que aumentam sua confiabilidade são discutidos.
Reduza o tamanho do kernel
Sistemas operacionais monolíticos como Linux e FreeBSD e híbridos como Windows possuem milhões de linhas de código de kernel . Em contraste, o MINIX 3 tem cerca de 6.000 linhas de código de kernel executável, o que pode facilitar a localização de problemas no código.
Enjaular os insetos
Em kernels monolíticos, os drivers de dispositivo residem no kernel. Assim, quando um novo periférico é instalado, um código desconhecido e não confiável é inserido no kernel. Uma linha de código incorreta em um driver pode derrubar o sistema.
Em vez disso, no MINIX 3, cada driver de dispositivo é um processo de modo de usuário separado. Os drivers não podem executar instruções privilegiadas, alterar as tabelas da página , realizar entradas / saídas arbitrárias (E / S) ou gravar na memória absoluta. Eles devem fazer chamadas de kernel para esses serviços e o kernel verifica cada chamada de autoridade.
Limitar o acesso dos motoristas à memória
Em kernels monolíticos, um driver pode gravar em qualquer palavra da memória e, assim, corromper acidentalmente os programas do usuário.
No MINIX 3, quando um usuário espera dados, por exemplo, do sistema de arquivos, ele constrói um descritor informando quem tem acesso e em quais endereços. Em seguida, ele passa um índice para esse descritor para o sistema de arquivos, que pode passá-lo para um driver. O sistema de arquivos ou driver então pede ao kernel para escrever através do descritor, tornando impossível para eles escreverem em endereços fora do buffer.
Sobreviva a dicas ruins
A anulação da referência a um ponteiro inválido em um driver travará o processo do driver, mas não afetará o sistema como um todo. O servidor de reencarnação irá reiniciar o driver travado automaticamente. Os usuários não notarão a recuperação de alguns drivers (por exemplo, disco e rede), mas sim de outros (por exemplo, áudio e impressora). Em kernels monolíticos, desreferenciar um ponteiro inválido em um driver normalmente leva a uma falha do sistema.
Dome loops infinitos
Se um driver entrar em um loop infinito , o planejador diminuirá gradualmente sua prioridade até que fique ocioso. Eventualmente, o servidor de reencarnação verá que não está respondendo às solicitações de status, então ele irá matar e reiniciar o driver em loop. Em um kernel monolítico, um driver de loop pode travar o sistema.
Limite os danos de estouros de buffer
O MINIX 3 usa mensagens de comprimento fixo para comunicação interna, o que elimina certos estouros de buffer e problemas de gerenciamento de buffer. Além disso, muitos exploits funcionam saturando um buffer para enganar o programa para que ele retorne de uma chamada de função usando um endereço de retorno de pilha sobrescrito apontando para a memória controlada pelo invasor, geralmente o buffer de saturação. No MINIX 3, esse ataque é mitigado porque a instrução e o espaço de dados são divididos e apenas o código no espaço de instrução (somente leitura) pode ser executado, denominado proteção de espaço executável . No entanto, os ataques que dependem da execução de memória legitimamente executável de forma maliciosa ( retorno para libc , programação orientada para retorno ) não são evitados por esta mitigação.
Restringir o acesso às funções do kernel
Os drivers de dispositivo obtêm serviços do kernel (como copiar dados para os espaços de endereço dos usuários) fazendo chamadas ao kernel. O kernel do MINIX 3 tem um mapa de bits para cada driver especificando quais chamadas ele está autorizado a fazer. Em kernels monolíticos, cada driver pode chamar todas as funções do kernel, autorizadas ou não.
Restringir o acesso às portas de E / S
O kernel também mantém uma tabela informando quais portas de E / S cada driver pode acessar. Portanto, um driver só pode tocar em suas próprias portas de E / S. Em kernels monolíticos, um driver com erros pode acessar portas de E / S pertencentes a outro dispositivo.
Restrinja a comunicação com os componentes do sistema operacional
Nem todo driver e servidor precisa se comunicar com todos os outros drivers e servidores. Consequentemente, um mapa de bits por processo determina para quais destinos cada processo pode enviar.
Reencarnar motoristas mortos ou doentes
Um processo especial, chamado servidor de reencarnação, executa ping periodicamente em cada driver de dispositivo. Se o driver morre ou não responde corretamente aos pings, o servidor de reencarnação o substitui automaticamente por uma nova cópia. A detecção e substituição de drivers que não funcionam é automática, sem a necessidade de ação do usuário. Este recurso não funciona para drivers de disco no momento, mas na próxima versão o sistema será capaz de recuperar até mesmo drivers de disco, que serão ocultados na memória de acesso aleatório (RAM). A recuperação do driver não afeta os processos em execução.
Integre interrupções e mensagens
Quando ocorre uma interrupção , ela é convertida em um nível baixo em uma notificação enviada ao driver apropriado. Se o driver estiver esperando por uma mensagem, ele obtém a interrupção imediatamente; caso contrário, ele receberá a notificação na próxima vez que fizer um RECEIVEpara receber uma mensagem. Este esquema elimina interrupções aninhadas e torna a programação do driver mais fácil.
Arquitetura
Como pode ser visto, no nível inferior está o microkernel , que tem cerca de 4.000 linhas de código (principalmente em C , mais uma pequena quantidade de linguagem assembly ). Ele lida com interrupções , agendamento e passagem de mensagens. Ele também oferece suporte a uma interface de programação de aplicativo (API) de cerca de 30 chamadas de kernel que servidores e drivers autorizados podem fazer. Os programas do usuário não podem fazer essas chamadas. Em vez disso, eles podem emitir chamadas de sistema POSIX que enviam mensagens aos servidores. As chamadas de kernel executam funções como definir interrupções e copiar dados entre espaços de endereço.
No próximo nível acima, existem os drivers de dispositivo , cada um sendo executado como um processo de usuário separado . Cada um controla algum dispositivo de E / S, como um disco ou impressora. Os drivers não têm acesso ao espaço da porta de E / S e não podem emitir instruções de E / S diretamente. Em vez disso, eles devem fazer chamadas de kernel fornecendo uma lista de portas de E / S para gravar e os valores a serem gravados. Embora exista uma pequena sobrecarga ao fazer isso (normalmente 500 ns), este esquema torna possível para o kernel verificar a autorização, de forma que, por exemplo, o driver de áudio não possa gravar no disco.
No próximo nível, estão os servidores . É aqui que quase todas as funcionalidades do sistema operacional estão localizadas. Os processos do usuário obtêm serviço de arquivo, por exemplo, enviando mensagens ao servidor de arquivos para abrir, fechar, ler e gravar arquivos. Por sua vez, o servidor de arquivos obtém a E / S de disco, enviando mensagens para o driver de disco, que controla o disco.
Um dos servidores principais é o servidor de reencarnação. Sua função é pesquisar todos os outros servidores e drivers para verificar sua integridade periodicamente. Se um componente não responder corretamente, sair ou entrar em um loop infinito , o servidor de reencarnação (que é o processo pai dos drivers e servidores) elimina o componente defeituoso e o substitui por uma nova cópia. Desta forma, o sistema é automaticamente autocorrigido, sem interferir nos programas em execução.
Atualmente, o servidor de reencarnação, o servidor de processo e o microkernel fazem parte da base de computação confiável . Se algum deles falhar, o sistema trava. No entanto, reduzir a base de computação confiável de 3 a 5 milhões de linhas de código, como nos sistemas Linux e Windows, para cerca de 20.000 linhas aumenta muito a confiabilidade do sistema.
Diferenças entre MINIX 3 e versões anteriores
MINIX 1.0, 1.5 e 2.0 foram desenvolvidos como ferramentas para ajudar as pessoas a aprender sobre o design de sistemas operacionais.
O MINIX 1.0, lançado em 1987, tinha 12.000 linhas de C e alguma linguagem assembly x86 . O código-fonte do kernel, gerenciador de memória e sistema de arquivos do MINIX 1.0 estão impressos no livro. Tanenbaum originalmente desenvolvido MINIX para compatibilidade com o IBM PC e IBM PC / AT microcomputadores disponíveis no momento.
O MINIX 1.5, lançado em 1991, incluía suporte para sistemas MicroChannel IBM PS / 2 e também foi portado para as arquiteturas Motorola 68000 e SPARC , suportando as plataformas de computador Atari ST , Commodore Amiga , Apple Macintosh e Sun Microsystems SPARCstation . Uma versão do MINIX rodando como um processo de usuário sob SunOS também estava disponível.
O MINIX 2.0, lançado em 1997, estava disponível apenas para as arquiteturas SPARC hospedadas em x86 e Solaris . O Minix-vmd foi criado por dois pesquisadores da Vrije Universiteit e adicionou memória virtual e suporte para o X Window System .
O MINIX 3 faz o mesmo e fornece um sistema operacional moderno com muitas ferramentas novas e muitos aplicativos Unix . O Prof. Tanenbaum disse uma vez:
Esteja ciente de que o MINIX 3 não é o MINIX do seu avô ... O MINIX 1 foi escrito como uma ferramenta educacional ... O MINIX 3 é mais um começo na construção de um sistema operacional altamente confiável, autocurativo e sem inchaço ... MINIX 1 e MINIX 3 estão relacionados da mesma forma que o Windows 3.1 e o Windows XP são: o mesmo nome.
Muitas melhorias também foram feitas na estrutura do kernel desde o lançamento do MINIX 2, tornando o sistema mais confiável. A versão 3.1.5 do MINIX foi lançada em 5 de novembro de 2009. Ele contém X11 , Emacs , vi , cc, GCC , Perl , Python , shell Almquist , Bash , shell Z , cliente FTP , cliente SSH , cliente Telnet , Pine e mais de 400 outros programas utilitários comuns do Unix. Com a adição do X11, esta versão marca a transição de um sistema somente texto. Outra característica desta versão, que será aprimorada em versões futuras, é a capacidade do sistema de resistir a travamentos de driver de dispositivo e, em muitos casos, substituí-los automaticamente sem afetar os processos em execução. Desta forma, o MINIX é autorrecuperável e pode ser usado em aplicações que exigem alta confiabilidade.
MINIX 3.2.0 foi lançado em fevereiro de 2012. Esta versão tem muitos recursos novos, incluindo o compilador Clang , suporte experimental a multiprocessamento simétrico , suporte a sistemas de arquivos procfs e ext2fs e GNU Debugger (GDB). Várias partes do NetBSD também estão integradas ao lançamento, incluindo o bootloader, libc e vários utilitários e outras bibliotecas .
O MINIX 3.3.0 foi lançado em setembro de 2014. Este é a primeira versão a oferecer suporte à arquitetura ARM além do x86. Ele também oferece suporte a um ambiente de usuário do NetBSD , com milhares de pacotes do NetBSD sendo executados imediatamente.
Mascote
Rocky Raccoon é o mascote do MINIX 3.
MINIXCon
MINIXCon é uma conferência sobre o compartilhamento de conversas, esforços e pesquisas relacionadas ao MINIX.
Foi realizada uma vez em 2016. MINIXCon2017 foi cancelada devido à falta de palestras enviadas.
Veja também
- Comparação de kernels do sistema operacional
- Sistema de arquivos MINIX
- Lista de mascotes de computação
- Categoria: Mascotes de informática
Notas
Referências
Leitura adicional
- Tanenbaum, Andrew S ; Woodhull, Albert S. (14 de janeiro de 2006). Sistemas Operacionais: Design e Implementação (3ª ed.). Prentice Hall . ISBN 0-13-142938-8.
- Construindo um sistema operacional confiável: tolerância a falhas no MINIX 3 por Jorrit N. Herder (PDF)
- Reorganizando o Unix para confiabilidade por Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg e Andrew S. Tanenbaum (PDF)
- Programação de sistema modular no MINIX 3 por Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg e Andrew S Tanenbaum (PDF)
- JN Herder et al., Modular System Programming in MINIX 3 ,; Login, abril de 2006 (PDF)
- Pablo A Pessolani. MINIX4RT: um sistema operacional em tempo real baseado no MINIX
- Construindo Ferramentas de Medição de Desempenho para o Sistema Operacional MINIX 3 , por Rogier Meurs (PDF)
- Projeto e implementação do sistema de arquivos virtual MINIX (PDF)
- Manual de referência para MINIX 3 Kernel API (PDF)
- Rumo a um verdadeiro sistema operacional microkernel (PDF)
- Construção de um sistema operacional altamente confiável (PDF)
- Minix 3 e a experiência do microkernel: Smart Kernel de Rüdiger Weis (PDF)
- Atualização segura e automática ao vivo por Cristiano Giuffrida (PDF)
links externos
- Website oficial
- MINIX 3: um sistema operacional modular e autocurável compatível com POSIX no YouTube
- minix3.ru (em russo)
- comp.os.minix - fórum oficial (desde 1987)
- Descrição do Minix 3 por Andy Tanenbaum
- MINIX: o que é e por que ainda é relevante? Uma entrevista com Andy Tanenbaum
- Documentação do serviço de rede Minix
- Podemos tornar os sistemas operacionais confiáveis e seguros?
- Instalação do Minix3 no YouTube
- Uma reimplementação do NetBSD com base em um microkernel
- MINIX 3 no ARM de Kees Jongenburger
- Lições aprendidas com 30 anos de MINIX por Andrew S. Tanenbaum