domingo, 29 de abril de 2012

OS e FS



... quem vem primeiro? O ovo ou o pinguim?

Realmente, a questão de quando o kernel sabe sobre o sistema de arquivos (FS) é um paradoxo. O SO precisa estar carregado para iniciar o FS (File Sistem). Mas o SO está no FS... e então? Como fica?

Em outro artigo deste blog ( 0-1 ou On/Off) expliquei que, depois de carregado o firmware e o sistema está pronto, "o programa procura pela palavra 0xAA55 (assinatura de boot) no primeiro setor de um periférico do tipo disco (Floppy, HD, CD/DVD etc.) ou cartão de memória (pen drive, cartão SD etc.)". E aí tem que carregar um FS para poder ler a imagem do kernel, as configurações e os módulos.

Existem duas maneiras de inicar o FS. Uma delas é criando um disco inicial na memória (RAM Disk). A outra é usando um "bootloader" ou boot manager na trilha zero do device de boot que contém o marcador 0x55AA (lembre-se que o x86 é little endian). O primeiro método é, geralmente, usado pelo kernel linux enquanto o segundo é utilizado pelo kernel BSD.

Em ambos os casos é necessário criar um FS mínimo com o kernel e os módulos, o suficiente para permitir a continuidade do processo de boot. No caso do boot manager na trilha zero, este segmento não pode passar de 446 bytes, uma vez que está limitado pela tabela da partição e do setor marcado 0x55AA.

Somente depois de carregado o kernel e o sistema inicial de arquivos é que a raíz do sistema de arquivos (root file system) é montada. No kernel FreeBSD, o boot (man 8 boot) é responsável por iniciar o FS e, posteriormente o loader (man 8 loader) toma o controle do processo.

No kernel Linux, tanto o initramfs (initial ram disk file system) como o initrd (initial ram disk) são responsáveis pelo processo de iniciar um sistema de arquivo na memória para o boot inicial do SO (man 8 init). O initramfs é um sistema interno do kernel e o initrd é a raíz do FS que contém os arquivos no /boot e é passado para o kernel via bootloader.

Somente depois disto que o kernel do SO monta o sistema de arquivos real. No FreeBSD é fácil identificar este momento. Quando as mensagens do boot passam de negrito para sem negrito.

Referências.

Mais informação pode ser obtida na própria fonte do kernel, em:

...linux-x.x.x/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Veja, também, o excelente artigo:

Day, R. The Kernel Newbie Corner: "initrd" and "initramfs"--Some Unfinished Business, in https://www.linux.com/learn/linux-career-center/114923-the-kernel-newbie-corner-qinitrdq-and-qinitramfsq-some-unfinished-business

Crédito da imagem: http://www.h-online.com/imgs/43/3/6/8/3/5/2/a345f5e7c547062f.jpg

sexta-feira, 20 de abril de 2012

Linux e processamento paralelo


SIMD e Extensões de código de CPU no Linux

O cálculo com ponto flutuante sempre foi o nó górdio para os sistemas operacionais. Sua importância se revela na própria unidade de medida de velocidade de processamento: FLOPS (FLoating-points Operations Per Second) ou número de operações de ponto flutuante por segundo. 1997 foi um ano decisivo para os sistemas operacionais. Os fabricantes de chips para CPU disputavam nas raias da velocidade de processamento e implementavam registros de 64 e 128 bits para cálculos com ponto flutuante (Floating Point). Os 3 principais fabricantes (Intel, AMD e Cyrix) disputavam ombro a ombro no ranking de velocidade.

 A AMD disparou na frente com o seu processador K6-2 e, posteriormente o Athlon, que utilizavam a tecnologia apelidada de 3DNow, além do suporte a MMX, memória cache secundária e Accelerated Graphics Port (AGP). A tecnologia 3DNow permitia o cálculo com números de ponto flutuante em registros de 64/80 bits, com instruções específicas para o processador que permitiam a operação no mesmo registro.

 A resposta da Intel foi rápida. Quando a Intel lançou os Pentium III foram criadas 70 novas instruções de código e 8 registros para estes processadores, com a finalidade de incrementar o desempenho do processamento de ponto flutuante (Floating-Point Unity - FPU). Estas instruções extendidas do conjunto de instruções do processador foi denominada de Streaming SIMD Extensions (SSE). A tecnologia SSE implementava os registradores XMM de 128 bits. A vantagem da tecnologia da Intel é que a operação podia ser feita com até 4 números no mesmo registro.

As extensões foram sendo otimizadas e os processadores passaram a disponibilizar 8 registros de 128 bits (XMM0 ... XMM7 nos processadores com suporte a SSE) e depois 16 registros de 128 bits (XMM0 ... XMM15 nas CPUs com suporte a SSE2 em diante). Atualmente, o suporte é de até 16 registros de 256 bits (YMM0 ... YMM15 nas CPUs com suporte a AVX). Nas CPUs com suporte a AVX os bits de 0-127 dos registros YMM0 ... YMM15 funcionam como registros XMM.


A tecnologia AVX (Advanced Vector Extensions) implementa novas instruções do processador para operar sobre os registros YMM, usando até 3 endereços de fonte de dados e um endereçamento de destino de dados em uma única instrução do tipo Single Instruction Multiple Data (SIMD).

Em um sistema multitarefa preemptivo como o Linux o uso destas extensões de SIMD requer uma habilidade adicional no controle dos registradores. Por isto o kernel do SO tem que estar preparado para lidar com registros extendidos. Por exemplo, quando o sistema passa o controle de um processo para outro, os registros SIMD do processo anterior têm que ser salvos e o novo conjunto de registros SIMD do processo que entra para rodar é carregado no processador. O SO tem que estar pronto para lidar com estes registros extendidos e gerenciá-los apropriadamente.

No kernel do linux (3.x) o suporte a este tipo de processamento é fundamental para a paralelização de algorítmos e o suporte a SMP (Symetric MultiProcessing) em processadores dualcore, quadricore, i5, i7 etc. e isto depende do suporte no kernel a instruções extendidas SSE / SSE5 e AVX do processador.

Para ver o suporte do processador a estas extensões, use o comando:

cat /proc/cpuinfo |grep flags
 O comando retorna o campo "flags" de cada núcleo ou processador.

Allternativamente, pode-se usar o nome do flag da extensão. Por exemplo:

cat /proc/cpuinfo |grep sse

Normalmente, os sistemas operacionais mais modernos já são configurados para o suporte às extensões da CPU. No kernel, fica tudo definido nos arquivos:

/src/linux-.../arch/x86/include/asm/processor.h
/src/linux-.../arch/x86/include/asm/sigcontext.h
/src/linux-.../arch/x86/include/asm/xsave.h
/src/linux-.../arch/x86/kernel/cpu/common.c
/src/linux-.../arch/x86/kernel/xsave.c

O processamento paralelo é vantajoso para cálculos matemáticos de alto desempenho tanto para processamento em computação científica como em processamento de sinais de áudio e imagem para execução, em tempo real, de aplicativos multimedia. No entanto, o rendimento é dependente da fração do programa que pode ser paralelizada e do número de núcleos envolvidos no algorítmo em paralelo. A relação é de

`V=frac{n}{(n-1)f + 1}`

onde V é a velocidade de processamento, n é o número de processos paralelos e f é um fator de paralelismo (veja lei de Amdahl).

Normalmente, programas que utilizam as bibliotecas do BLAS (Basic Linear Algebra Subprograms), LAPACK (Linear Algebra PACKage) e ATLAS (Automatically Tuned Linear Algebra Software) podem usar o processamento vetorial avançado provido por estas extensões da CPU.

Além disso, existem outras aplicações que podem usar estas extensões para processamento, tais como: funções transformadas FFT, Wavelet e outras aplicações para sistemas lineares; algoritmos de RNG (Random Number Generator) para funções de distribuição estatística; aplicações para criptografia; e, ainda, rotinas numéricas em FORTRAN e C/C++ de software como (Octave, Scilab, Matlab e Matematica).


...
Dave Bowman: Yes, I'd like to hear it, HAL. Sing it for me.
HAL: It's called "Daisy."
[sings while slowing down]
HAL: Daisy, Daisy, give me your answer do. I'm half crazy all for the love of you. It won't be a stylish marriage, I can't afford a carriage. But you'll look sweet upon the seat of a bicycle built for two.

Referências:

http://pt.scribd.com/dbrunecz/d/57793168-Optimizing-Assembly

http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011/compiler_c/intref_cls/common/intref_avx_details.htm

http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

http://en.wikipedia.org/wiki/Advanced_Vector_Extensions


terça-feira, 10 de abril de 2012

Chromium OS






... simples assim, mas não é para nós escovadores de bits!

O Chromium OS, sistema operacional do Google está aí... prontinho e funcionando. Mas é um sistema para quem faz tudo na Web, ou seja: email, editor de texto, slides, imagens, vídeos e música.

O código do Chromium é baseado em um kernel Linux e é de código aberto. Portanto, muito pode ser estudado e feito desde já e, se o sistema realmente decolar, muito poderá ser desenvolvido para este novo ambiente. Uma nova fatia de mercado para programadores e pessoal de TI? Acho que sim.

A arquitetura dos sistema é baseada em alguns cortes de testes de redundância feitos pela BIOS, pelo Kernel e pelo SO como, por exemplo, deixar a ativação do hardware toda por conta do SO ou diminuir o tempo de teste e ativação de hardware feito pela BIOS. A BIOS, por sua vez, tem que ser "customizada" para cada tipo de hardware. Mesmo o Power-On Self Test (POST) deve ser adequado para uma otimização do tempo.

Trocando em miúdos a hirearquia é exemplificada na imagem abaixo:

Fig. 1 Arquitetura do Chromium OS

O POST inicia o hardware mas deixa os testes para o Kernel, ou seja, o sistema inicia sem saber se os endereços das memórias estão todos operacionais. A BIOS deve ser um firmware específico e customizado para cada hardware e ter os endereços e interrupções pré-fixados. Aí sim, o Kernel poderá fazer os testes de hardware. Imagino que deva checar a veracidade dos endereços e interrupções da BIOS (ainda não li o código deste kernel).

Primeiro, o hardware tem que ser bem confiável, pois a ativação pelo kernel não mais verifica apenas os endereços dos dispositivos (devices) disponibilizados pela BIOS. Ele tem que verificar a integridade e tempo de resposta dos mesmos. Segundo, fabricantes de hardware vão ter que entrar em um esquema de padronização que ainda não está totalmente resolvida.

Depois disso o SO carrega o X-Windows, as bibliotecas do xorg e as bibliotecas do sistema para então carregar o Gerenciador de Janelas (Window Mannager) e o Chromium propriamente dito. Como é um sistema cujos aplicativos são tipo Web Applications, o Chromium fica como o "shell" para estes aplicativos, para páginas web e extensões.

Na verdade podemos dizer que o Chromium é um Linux otimizado para Aplicativos Web. Enquanto a "propaganda" do Google [2] diz que várias etapas do processo de carregamento do sistema foram eliminadas (veja fig. 2), eu diria que podem ter sido otimizadas e automatizadas, mas todas elas estão lá [3].

Fig. 2 Comparação de um Boot normal de SO e do Chromium

O que é interessante, realmente, é a organização do Gerenciador de Janelas, que cria uma hierarquia totalmente voltada para a Internet e não mais centrada no modelo desktop.

Fig. 3 Hierarquia do Gerenciamento de Janelas

Bem, imagine o tanto de código (QT, GTK, etc.) e ambientes (LXDE, Gnome, KDE etc.) que não mais existirão num sistema assim. A idéia do Google é ousada e muito interessante para o usuário que vai utilizar a máquina como um gadget tipo tablet ou smartphone. Mesmo um thin, ultra ou netbook poderiam tirar vantagem de um sistema simples assim.

É claro que muitos dos programas que usamos, tais como, editores de áudio e vídeo, editoração de texto (TeX/LaTeX), sistemas especializados de CAD etc. não vão funcionar (pelo menos dentro do ambiente do Chromium). Para isto teriam que ser reprogramadas mas no futuro muita coisa vai mudar. Até nossos óculos!



Referências:

[1] http://www.chromium.org/chromium-os

[2] http://www.youtube.com/watch?v=mTFfl7AjNfI

[3] http://www.chromium.org/chromium-os/chromiumos-design-docs/software-architecture

sábado, 7 de abril de 2012

Flashback



... Não, não é hit de música, é virus de MacOS!

Já ouviram falar no Flashback? Bem, é um ataque aos computadores da Apple, rodando MacOS X que se aproveita de uma vulnerabilidade do Java para instalar um malware com a ajuda do usuário. Costumo dizer que é virus de "enter" ("enter" o teclado e a cadeira) aquele que diz assim: "Isto é um virus, clique aqui para instalá-lo". Mas o usuário clica! Afinal... "é de grátis". Dãrrr!!!

"When a computer incident happens on Apple’s Mac OS X, it’s a headline-making event. When it happens on Windows, it’s just another day." [1]

Quando se encontra uma vulnerabilidade no Mac, vira notícia de primeira página em todos os meios da área de TI, quando se trata do Windows é coisa do dia-a-dia (tradução minha).

Eu não sou fanzoca do Steve Jobs nem da Apple mas, justiça seja feita, a culpa, desta vez, é da Oracle. O ataque do Flashback usa uma vulnerabilidade do Java... o Java é da Oracle... culpa da Oracle... ponto. Ah minhas "professias" (profecias de professor). Eu sempre disse que esta coisa de máquina java ia dar com os burros n'água (pra não dizer outra coisa)!

Mas, o que é o Flashback? O software malicioso usa um applet java que tenta, primeiro pegar a senha do usuário simulando que é para instalar uma atualização do Flash da Adobe. Se não consegue enganar o usuário ele parte para outro tipo de ataque. Ele então verifica em todo o disco do usuário se existe certos softwares de segurança. Se existir ele se auto destroi. Se não encontra nada ele passa a instalar mais malware que usa o sistema para gerar tráfego Web para gerar ganhos para alguém em sites "pay-per-click", tipo adsense.

A Apple já corrigiu o "furo" do java e patch da Adobe [2]. Uma explicação também foi dada em seus fóruns de discussão e a Oracle não se manifestou oficialmente.

No entanto o público que comprou um Mac porque não tinha virus vai continuar achando que a culpa é da Apple. Tipo, aquele sentimento de fui enganado! Mesmo assim, 600.000 computadores infectados não representam mais que 1% dos vendidos pela Apple.

Porque a Apple? Oras, enquanto assistimos ao crescimento da Apple e da utilização de computadores com MacOS X nos últimos dois anos, o interesse em atacá-los também cresceu.

Dica: preste atenção ao clique do mouse... ele pode te detonar!

Referências:

[1] Hesseldahl, A. "What’s This? A Mac Virus? No, Actually It’s a Weakness in Java." in: http://allthingsd.com/20120406/whats-this-a-mac-virus-no-actually-its-a-weakness-in-java/

[2] Lowensohn, J. e Rosenblatt, S. "Flashback the largest Mac malware threat yet, experts say" in http://news.cnet.com/8301-1009_3-57410702-83/flashback-the-largest-mac-malware-threat-yet-experts-say/

Crédito da imagem: digitaltrends.com
http://cdn2.digitaltrends.com/wp-content/uploads/2012/04/dr-web-flasback-map2_en.png

terça-feira, 3 de abril de 2012

Linux e FSF


... sem ressentimentos Mr. Stallman

Ok, fazia tempo que eu não acessava a página da GNU... mas hoje tomei um susto! O Stallman se converteu... Linux na página da GNU? #WTF?

Bem, preciso explicar a surpresa!

No final dos anos 80, tínhamos poucas escolhas de SOs que rodassem nos ainda caros PCs. Um PC-XT custava o equivalente a $2500 dólares no Brasil e, montando nossos hardwares conseguíamos baixar uns $500 dólares. A comunidade científica ficava a mercê do DOS da IBM ou da Microsoft e, uns poucos illuminati tinham acesso ao Minix (que rodava em PC-AT 386).

Nós sabíamos que um tal de Stallman estava desenvolvendo um kernel Unix na Free Software Foundation (FSF), e esperávamos que o mesmo fosse liberado para nos tirar deste domínio feroz da MS e IBM. Apesar de muitos tentarem obter o código do Hurd (como é chamado o kernel da GNU) o Stallman o guardava a sete chaves.

Foi uma benção, o fato de um estudante da Finlândia, chamado Linus Torvalds, pegar o kernel do Minix e criar o kernel do Linux. "God bless Linus Torvalds". O que "emputeceu" o Stallman foi o fato de que a comunidade, ávida por uma mudança, adotou o Linux com uma rapidez impressionante. Além disso, um número significativo de aplicativos que rodavam sobre o Linux eram da GNU; e ele queria o nome GNU vinculado ao novo kernel. Algo como: GNU/Linux.

O Linus Torvalds e o Jon "Maddog" Hall não concordavam por dois motivos que o próprio Maddog me explicou. Primeiro, porque nem todo software que rodava no Linux era da GNU (X Windows, sendmail, vi, vários shells, OpenOffice etc. conforme ele mesmo cita). Em segundo lugar, porque, perante a legislação dos Estados Unidos, colocar duas trademarks juntas enfraquece a ambas. Mas isto não convenceu o "dono" da discórdia e o nome Linux passou a ser quase um tabu para o Stallman.

Explicada minha surpresa, em uma análise mais detalhada do site da GNU encontrei várias distros chamadas de GNU/Linux [1] (para testar e comentar no futuro) e uma explicação de porque as outras distros são excluídas [2]. Segundo o Stallman, são distribuições que trazem em si ou permitem instalação de programas não open source. Errr... qual o problema? Se eu quiser comprar um programa que rode no Linux ou no FreeBSD não vejo nenhum!

Mas, sinceramente, parece haver um erro de interpretação do Stallman. Hoje não temos mais apenas PCs. Temos laptops, smartphones, tablets etc. que precisam de drivers proprietários para rodar os diversos SOs. Esta "turronice" do Stallman não tem sentido. Mas ele é complicado mesmo. Ele é tão radical que não participa de conferências onde o nome Linux não esteja associado ao GNU, como GNU/Linux. Ainda por cima, diferentemente do Maddog que é super "gente fina", o Stallman não faz nenhum esforço para ser simpático (veja neste blog um comentário: http://stulzer.net/blog/2008/03/18/a-terrivel-semana-que-richard-stallman-ficou-na-minha-casa/).

Acho que ele devia acabar o GNU/Hurd no lugar de ficar reclamando, mas parece que ele mesmo já se desencantou:

Stallman said that he was "not very optimistic about the GNU Hurd. It makes some progress, but to be really superior it would require solving a lot of deep problems" [3]

Pode ser que nesta era de novos gadgets achem um lugar para o Hurd também!

... E viva a diversidade!

Referências

[1] http://www.gnu.org/distros/free-distros.html

[2] http://www.gnu.org/distros/common-distros.html

[3] http://en.wikipedia.org/wiki/GNU_Hurd

Crédito da imagem: http://www.gnu.org