Kernel - Lançado o kernel 3.19.3 para Linux (Distros baseadas no Debian)

Fonte: Viva o Linux

Foi lançado essa semana a atualização para o kernel do unix/linux. Ela vem com uma série de melhorias de segurança, de gerenciamento de hardware, entre outras.

Atualizando

A atualização é bem simples, abra o terminal e digite

sudo apt-get update

Quando o processo finalizar digite

sudo apt-get dist-upgrade

Depois de finalizado você pode  instalar os demais updates digitando

sudo apt-get upgrade

Pronto seu sistema está pronto para voar...

OBS.: Pode ser necessário autorizar a instalação, quando perguntado somente responda "S" (ou "Y", em sistemas em inglês (sem aspas)) e depois ENTER.

Descrição completa dos recursos novos do kernel (em inglês): http://kernelnewbies.org/Linux_3.19

Fonte: Linux and Ubuntu (em inglês)

Read More

Acesso à memória do espaço do usuário a partir do kernel Linux

Neste artigo vamos explorar o gerenciamento de memória no Linux para entendermos como funciona a paginação e explorar as funções de acesso a memória do espaço do usuário que usam estes conceitos. Movimentar dados entre espaço de usuário e kernel. Vamos usar tmb APIs.

Liguem suas VMs!

Uma introdução à memória e APIs de espaço do usuário do Linux

Como o kernel e o espaço do usuário existem em espaços de endereço virtuais diferentes, existem considerações especiais para movimentar dados entre eles. Explore as ideias por trás dos espaços de endereço virtuais e as APIs do kernel para movimentar dados do e para o espaço do usuário, e aprenda algumas das outras técnicas de mapeamento usadas para mapear memória. Embora o byte seja a menor unidade de memória que pode ser endereçada no Linux, é a página que serve como a abstração gerenciada da memória. Este artigo começa com uma discussão sobre o gerenciamento da memória no Linux e, em seguida, explora os métodos para manipular o espaço de endereço a partir do kernel.

Memória no Linux

No Linux, a memória do usuário e a memória do kernel são independentes e implementadas em espaços de endereço separados. Os espaços de endereço são virtualizados, ou seja, os endereços são abstraídos da memória física (por meio de um processo que será detalhado mais adiante). Como os espaços de endereço são virtualizados, podem existir vários deles. Na verdade, o kernel reside em um espaço de endereço, e cada processo reside em seu próprio espaço. Esses espaços consistem em endereços de memória virtual, permitindo que vários processos com espaços de endereço independentes se refiram a um espaço de endereço físico consideravelmente menor (a memória física da máquina). Isso não é apenas conveniente, como também é seguro, pois cada espaço de endereço está isolado e, consequentemente, protegido.

Mas essa segurança tem um preço. Como cada processo (e o kernel) pode ter endereços idênticos que se referem a regiões diferentes da memória física, não é imediatamente possível compartilhar memória. Felizmente, existem algumas soluções. Processos do usuário podem compartilhar memória por meio do mecanismo de memória compartilhada da Portable Operating System Interface for UNIX® (POSIX) (shmem), com a advertência de que cada processo pode ter um endereço virtual diferente que se refere à mesma região da memória física.

O mapeamento da memória virtual para a memória física ocorre por meio de tabelas de página, implementadas no hardware subjacente. O próprio hardware fornece o mapeamento, mas é o kernel que gerencia as tabelas e sua configuração. Observe que, como mostrado aqui, um processo pode ter um grande espaço de endereço, mas é esparso, ou seja, pequenas regiões (páginas) do espaço se referem à memória física através das tabelas de página. Isso permite que um processo tenha um enorme espaço de endereço que é definido apenas para as páginas necessárias em um dado momento.

Figura 1. Tabelas de página fornecem o mapeamento de endereços virtuais para endereços físicos

A capacidade de definir memória para processos de maneira esparsa significa que a memória física subjacente pode ser confirmada em excesso. Por meio de um processo chamado paginação (embora, no Linux, seja geralmente chamado de troca), páginas pouco usadas são movidas dinamicamente para um dispositivo de armazenamento mais lento (por exemplo, um disco) para acomodar outras páginas que precisam ser acessadas (veja a Figura 2). Isso permite que a memória física do computador forneça páginas que um aplicativo precisa imediatamente, e migre páginas menos necessárias para o disco para melhor uso da memória física. Observe que algumas páginas podem se referir a arquivos, caso no qual os dados podem ser descarregados se a página estiver suja (por meio do cache de página) ou, se a página estiver limpa, simplesmente descartados.

 

Figura 2. A troca permite melhor uso do espaço da memória física ao migrar páginas pouco usadas para armazenamento mais lento e menos caro

O processo pelo qual uma página é selecionada para ser descarregada para o armazenamento é chamado de algoritmo de substituição de página e pode ser implementado usando alguns algoritmos diferentes (como, por exemplo, usado menos recentemente). Esse processo pode ocorrer quando é solicitado um local de memória cuja página não está na memória (não há mapeamento presente na memory management unit [MMU]). Esse evento é chamado de falha de página e é detectado pelo hardware (a MMU) e gerenciado pelo firmware após uma interrupção de falha de página ocorrer. A Figura 3 contém uma ilustração dessa pilha.

O Linux apresenta uma implementação interessante da troca, que oferece algumas características úteis. O sistema de troca do Linux permite a criação e uso de várias partições e prioridades de troca, o que permite uma hierarquia de troca para dispositivos de armazenamento que fornecem diferentes características de desempenho (por exemplo, uma troca de primeiro nível em uma unidade de estado sólido [SSD] e um espaço de troca maior, de segundo nível, em um dispositivo de armazenamento mais lento). Designar uma prioridade maior à troca em SSD permite que ele seja usado até estar cheio; só então as páginas seriam gravadas na partição de troca de baixa prioridade (mais lenta).

Figura 3. Espaços de endereço e elementos de mapeamento de endereço virtual para físico

Nem todas as páginas podem ser descarregadas para a área de troca. Por exemplo, código do kernel que responde a interrupções, ou código que gerencia as tabelas de página e a lógica de troca. Essas são páginas que, obviamente, não devem ser descarregadas para a área de troca, e portanto são fixadas, ou residentes permanentemente na memória. Embora páginas do kernel não possam ser descarregadas, páginas do espaço do usuário podem, mas é possível fixá-las através da função mlock (ou mlockall) para bloquear a página. Esse é o propósito das funções de acesso à memória do espaço do usuário. Se o kernel achasse que um endereço passado por um usuário é válido e acessível, ocorreria por fim um pânico do kernel (por exemplo, porque a página do usuário foi descarregada para a área de troca, resultando em uma falha de página no kernel). Essa interface de programação de aplicativo (API) assegura que tais casos sejam tratados corretamente.

APIs do Kernel

Agora, vamos explorar as APIs do kernel para manipular a memória do usuário. Observe que esta seção cobre a interface do kernel e do espaço do usuário, mas a próxima explora mais algumas APIs de memória. As funções de acesso à memória do espaço do usuário que iremos explorar estão listadas na Tabela 1.

Tabela 1. A API de acesso à memória do espaço do usuário

Função Descrição

access_ok             Verifica a validade do ponteiro de memória do espaço do usuário

get_user                 Obtém uma variável simples do espaço do usuário

put_user              Envia uma variável simples para o espaço do usuário

clear_user              Limpa ou zera um bloco no espaço do usuário

copy_to_user      Copia um bloco de dados do kernel para o espaço do usuário

copy_from_user      Copia um bloco de dados do espaço do usuário para o kernel

strnlen_user      Obtém o tamanho de um buffer de cadeia de caractere no espaço do usuário

strncpy_from_user    Copia uma cadeia de caractere do espaço de usuário para o kernel



Como seria de se esperar, a implementação dessas funções depende da arquitetura. Em arquiteturas x86, é possível achar essas funções e símbolos definidos em ./linux/arch/x86/include/asm/uaccess.h, com origem em ./linux/arch/x86/lib/usercopy_32.c e usercopy_64.c.

O papel das funções de movimentação de dados é mostrado na Figura 4 em relação aos tipos envolvidos na cópia (simples vs. agregado). 

Figura 4. Movimentação de dados usando a API de acesso à memória do espaço do usuário

A função access_ok

A função access_ok é usada para verificar a validade do ponteiro no espaço do usuário que deverá ser acessado. O responsável pela chamada fornece o ponteiro (que se refere ao início do bloco de dados), o tamanho do bloco e o tipo de acesso (se a área deve ser lida ou gravada). O protótipo de função é definido como:

access_ok( type, addr, size );

O argumento type pode ser especificado como VERIFY_READ ou VERIFY_WRITE. O simbólico VERIFY_WRITE também identifica se a região da memória é legível, além de gravável. A função retorna diferente de zero se a região for provavelmente acessível (mas o acesso ainda pode resultar em -EFAULT). Essa função simplesmente verifica se o endereço é provável no espaço do usuário, não no kernel.

A função get_user

Para ler uma variável simples do espaço do usuário, usa-se a função get_user. Ela é usada para tipos simples, tais como char e int, mas tipos de dados maiores, como estruturas, devem usar a função copy_from_user. O protótipo aceita uma variável (para armazenar os dados) e um endereço no espaço do usuário para a operação de leitura:

get_user( x, ptr );

A função put_user

A função put_user é usada para gravar uma variável simples do kernel para o espaço do usuário. Assim como get_user, ela aceita uma variável (que contém o valor a ser escrito) e um endereço no espaço do usuário como destino da gravação: 

put_user( x, ptr );            

Assim como get_user, a função put_user é mapeada internamente para a função put_user_x, e retorna 0 em caso de sucesso ou -EFAULT em caso de erro.

A função clear_user

A função clear_user é usada para zerar um bloco de memória no espaço do usuário. Ela toma um ponteiro no espaço do usuário e um tamanho para zerar, definido em bytes:

clear_user( ptr, n );

Internamente, a função clear_user verifica primeiramente se o ponteiro do espaço do usuário é gravável (via access_ok), e em seguida chama uma função interna (escrita em assembly sequencial) para realizar a operação de Limpeza. Essa função está otimizada como um loop muito rígido usando instruções de cadeia de caractere com o prefixo de repetição. Ela retorna o número de bytes que não puderam ser limpos, ou zero caso a operação tenha tido sucesso.

A função copy_to_user

A função copy_to_user copia um bloco de dados do kernel para o espaço do usuário. Ela aceita um ponteiro para um buffer no espaço do usuário, um ponteiro para um buffer no kernel e um comprimento definido em bytes. A função retorna zero em caso de sucesso, ou diferente de zero para indicar o número de bytes que não foram transferidos.

copy_to_user( to, from, n );

Após verificar a possibilidade de gravar no buffer do usuário (através de access_ok), é chamada a função interna __copy_to_user, que, por sua vez, chama __copy_from_user_inatomic (em ./linux/arch/x86/include/asm/uaccess_XX.h, no qual XX é 32 ou 64, dependendo da arquitetura). A função (depois de determinar deve-se realizar cópias de 1, 2 ou 4 bytes) chama por fim __copy_to_user_ll, que é responsável pelo trabalho de verdade. Em hardware quebrado (antes do i486, quando o bit WP não era honrado em modo de supervisor), as tabelas de página podiam mudar a qualquer momento, exigindo que as páginas desejadas fossem fixadas na memória, de modo que não fossem descarregadas para a área de troca enquanto estavam sendo endereçadas. Depois do i486, o processo nada mais é que uma cópia otimizada.

A função copy_from_user

 A função copy_from_user copia um bloco de dados do espaço do usuário para um buffer do kernel. Ela aceita um buffer de destino (no espaço do kernel), um buffer de origem (no espaço do usuário) e um comprimento definido em bytes. Assim como copy_to_user, a função retorna zero em caso de sucesso, e diferente de zero para indicar o fracasso em copiar certo número de bytes.

copy_from_user( to, from, n );

A função começa por verificar a possibilidade de ler o buffer de origem no espaço do usuário (via access_ok), e em seguida chama __copy_from_user e, por fim, __copy_from_user_ll. A partir daí, dependendo da arquitetura, uma chamada é feita para copiar do buffer do usuário para um buffer do kernel zerando (os bytes indisponíveis). As funções de assembly otimizadas incluem a capacidade de gerenciar.

A função strnlen_user

A função strnlen_user é usada da mesma maneira que strnlen, mas ela considera que o buffer está disponível no espaço do usuário. A função strnlen_user aceita dois parâmetros: o endereço do buffer no espaço do usuário e o comprimento máximo a ser verificado.

strnlen_user( src, n );

A função strnlen_user verifica primeiramente se o buffer do usuário é legível, por meio de uma chamada para access_ok. Se for acessível, a função strlen é chamada, e o argumento max length é ignorado.

A função strncpy_from_user

A função strncpy_from_user copia uma cadeia de caractere do espaço do usuário para um buffer do kernel, dados um endereço de origem no espaço do usuário e um comprimento máximo.

strncpy_from_user( dest, src, n );

Como se trata de uma cópia do espaço do usuário, a função primeiramente verifica se o buffer é gravável por meio de access_ok. De forma semelhante a copy_from_user, essa função é implementada como uma função assembly otimizada (em ./linux/arch/x86/lib/usercopy_XX.c).

Outros esquemas para mapeamento de memória

A seção anterior explorou métodos para movimentar dados entre o kernel e o espaço do usuário (com o kernel iniciando a operação). O Linux oferece outros métodos que podem ser usados para movimentação de dados, tanto no kernel como no espaço do usuário. Embora esses métodos possam não apresentar funcionalidade igual à das funções de acesso à memória do espaço do usuário, eles são semelhantes em sua capacidade de mapear memória entre os espaços de endereço.

Observe que, no espaço do usuário, como os processos do usuário aparecem em espaços de endereço separados, a movimentação de dados entre eles deve ocorrer por meio de algum tipo de mecanismo de comunicação interprocessos. O Linux oferece vários esquemas (tais como filas de mensagens), mas o mais notável é a memória compartilhada POSIX (shmem). Esse mecanismo permite que um processo crie uma área de memória e compartilhe essa região com um ou mais processos. Observe que cada processo pode mapear a região de memória compartilhada para diferentes endereços em seus respectivos espaços de endereços. Portanto é necessário um certo deslocamento de endereços.

A função mmap permite que um aplicativo do espaço do usuário crie um mapeamento no espaço de endereço virtual. Essa funcionalidade é comum em algumas classes de drivers de dispositivo (para desempenho), permitindo que a memória física do dispositivo seja mapeada para o espaço de endereço virtual do processo. Em um driver, a função mmap é implementada através da função do kernel remap_pfn_range, que fornece um mapeamento linear da memória do dispositivo para o espaço de endereço do usuário.



Conteúdo retirado do developerworks da IBM.

Publicado no Fórum da Brutal Security por Natan

Read More

Windows 8: Acabando com a festa dos hackers

Este foi o tema do painel apresentado pelos profissionais de segurança Chris Valasek e Tarjei Mandt na Black Hat USA de Las Vegas deste ano.

Valasek e Mandt são hackers White Hat, profissionais de segurança que testam vulnerabilidade em sistemas e componentes Windows, como o kernel do Windows.

De acordo com Valasek, pesquisador de segurança sênior da Coverity, uma empresa especializada em desenvolvimento de softwares de testes e hardening, o seu trabalho está para se tornar cada vez mais difícil.

Isso porque a Microsoft mudou diversas coisas no seu novo sistema o Windows 8 que vai parar vários ataques já conhecidos. "Se você tem algum exploit de transbordo da pilha que funciona no Windows 7, provavelmente ele não vai funcionar no Windows 8", disse Valasek na sua apresentação.

Nos últimos anos, white hats desenvolveram diversas novas técnicas para comprometer a pilha e o kernel do Windows.

Um dos últimos, por exemplo, refere ao modo de como o Windows distribui dinamicamente a memória. Este é um dos alvos favoritos dos hackers, ou crackers, que tentam exploitar essas vulnerabilidades para causar um overflow de memória, que poderia causar um DoS, ou na pior das hipóteses execução de código.

Um resultado esperado era que estas vulnerabilidades do kernel e da pilha seriam o alvo maior dos malwares. Lá em 2008, por exemplo, o pesquisador de segurança e white hat Ben Hawkes identificou uma falha na pilha do Windows Vista. Hawkes criou um POC (Prova de conceito) que foi capaz de corromper a pilha do Vista e expo-la a execução de código.

Já naquele tempo, Hawkes pode notar que ataques desse tipo antes comuns agora estão ficando mais difíceis e complexos, como o teste dele por exemplo.

O exploit do Hawkes funcionava também no Windows 7, mas não no Windows 8, de acordo com Valasek, a Microsoft fechou a porta na cara do exploit do Hawkes.

E não para por ai. Valasek mostrou um slide comparando o pontencial de exploitabilidade de cada um dos sistemas, entre eles Windows 7, Vista e 8. O que pode-se notar é que no último pode se encontrar muito mais "X" vermelhos do que "√" verdes.

O que a Microsoft mudou na memória que deixou tudo mais difícil, basicamente foi o modo de distribuição em memória, agora sendo aleatório e com alguns outros detalhes mais complexos, como por exemplo, diversos métodos para os programadores encerrarem seus programas caso algo seja modificado de maneira incorreta.

Valasek ainda comenta, "A Microsoft trabalhou duro para cuidar disso e prever problemas antes de ter que reagir e corrigir falhas já expostas".

Ele também adicionou que falhas ainda existem, já com alguns exploits hipotéticos em sua cabeça e confirma que alguns deles irão funcionar.

E o kernel não foi diferente, como Tarjei Mandt comentou, "o kernel continua o mesmo, nenhuma mudança significativa na estrutura foi feita, mas tem alguma camadas de segurança a mais, algo similar a hardening".

Fonte: Redmond Magazine

Read More

Primeiras Impressões do ODROID-XU

    É difícil hoje no cenário hobbyista de embarcados alguém não conhecer a hardkernel, empresa sul-coreana responsável pelos produtos “ODROID U” e “ODROID X”, e seus sucessores “ODROID U2″ e “ODROID X2″, todos de grande sucesso comercial não só pelo seu preço como pela ótima configuração de hardware que permite o uso até como pequenos desktops.

    A empresa ataca novamente agora sendo a primeira a lançar comercialmente um dispositivo de desenvolvimento que tem o já controverso octacore da Samsung (Exynos 5410), o primeiro SoC do mercado implementando a estratégia big.LITTLE da ARM – quatro velozes processadores Cortex-A15 funcionando em conjunção com outros quatro processadores Cortex-A7, mais lentos mas muito mais eficientes em utilização de energia. É inclusive curioso perceber que um integrador não tão ligado ao mercado corporativo esteja na frente das inovações – será uma mudança de direção do mercado?

    ODROID-XU é o nome do dispositivo e vem em duas versões: a simples – chamada simplesmente deODROID-XU, e disponível pelo preço-base de US$ 169 (que aumenta em pelo menos US$ 30 com o frete e é razoável comprar pelo menos uma eMMC de 16 GB pra usá-lo, o que sai mais US$ 39,90), e o mais sofisticado ODROID XU+E, que se diferencia por ter ferramenta de análise de energia integrada com quatro sensores de corrente e voltagem. Para os interessados na análise de desempenho e consumo do dispositivo sob diversas condições de stress, a versão XU+E é essencial (e não há jeito de atualizar um XU para se tornar XU+E, é preciso comprar novo dispositivo).

    Dado que os produtos ODROID já são amplamente conhecidos, nada mais justo que apresentar o ODROID-XU comparando-o a uma versão anterior de grande sucesso. Para isso foi escolhido seu antecessor ODROID-X2.

ODROID-X2 (esquerda) e ODROID-XU (direita)

    O X2 (que diga-se de passagem, ainda está à venda por US$ 135) tem o Exynos 4412, um SoC competente, com quatro cores Cortex-A9 de 1.7 GHz, 2 GB de RAM DDR2 e GPU Mali400 quad. O ODROID-XU tem o SoC Exynos 5410 com quatro cores Cortex-A7 de 1.2GHz (LITTLE) e quatro cores Cortex-A15 de 1.6 GHz, 2GB de RAM LPDDR3 e GPU PowerVR SGX544MP3.

    Enquanto seu antecessor tem 6 conectores USB 2.0 e uma MicroUSB para adb/mass storage, o ODROID-XU tem 4 conectores USB 2.0, um conector Host USB 3.0 e um conector USB 3.0 OTG tipo A-B. Esse conector talvez seja o mais insólito do XU, pois é (ainda) pouco conhecido.

USB OTG 3.0, MicroUSB A-B, MicroSD e MicroHDMI

    O XU pode bootar tanto pelo cartão MicroSD quanto por uma memória NAND “eMMC” opcional, sendo isso configurável por dip switches na placa.

    O XU possui várias características herdadas do seu antecessor X2. Se conecta ao vídeo por uma interface MicroHDMI, jogando a porta MIPI LCD para a parte inferior da placa; tem uma porta serial (conector Molex5268-04, que aceita um conversor USB CP2104) e vem com ethernet 10/100. O áudio pode sair pelo MicroHDMI ou pelo conector de 3,5mm e como uma diferença a se notar, não há conector para microfone. Como o XU tem USB 3.0 que tem alta velocidade, você pode utilizar esta saída para um adaptador de gigabit ethernet ou SATA3, ambos vendidos pela hardkernel.

    Uma novidade é o dispositivo vir envolto em um case de plástico que era algo que faltava ao X2 (na foto, em um case de acrílico comprado separadamente). O dispositivo também se diferencia por vir com cooler, diferente do dissipador anterior. Ambos os dispositivos têm um led para “ligado” e outro para indicar o estado de boot/operação.

    Enquanto o ODROID-X2 tem 50 GPIOs, o ODROID-XU vem com 30 (com a pinagem descrita na página de uso inicial, tendo 15 pinos digitais de uso geral e um analógico de 12 bits). Se você planeja usar o dispositivo para microeletrônica, fique atento que ele trabalha com níveis lógicos de 1.8 Volts, diferente dos 5V de um Arduino ou dos 3.3V de outros dispositivos ARM.

    Por fim, o conector de energia usado é de 5V/4A e já vem incluído.

    Com seu foco no mercado hobbyista, o que mais interessa à hardkernel é ter o hardware pronto primeiro com mínimo software para depois expandi-lo, tanto em funcionalidade quanto em documentação e suporte. Sendo assim, o BSP do ODROID-XU consiste do Android 4.2.2 com aceleração de hardware funcionando e, no momento de redação deste artigo, também já existe um BSP do Ubuntu 13.04 com kernel 3.4, com modo gráfico mas ainda sem aceleração de hardware. Uma curiosidade interessante sobre a hardkernel é que um de seus desenvolvedores é um brasileiro – Mauro Ribeiro – e você o verá frequentemente anunciando releases e ajudando usuários nos fóruns.

    O boot é feito em quatro etapas explicadas na página de uso inicial – cuja referência pode ser meio difícil de achar, e que tem também a valiosa informação de como configurar os dip switches de boot. Este modo de boot utiliza o software U-boot e caso se deseje modificar para uso próprio, é preciso utilizar fontes diferentes para cada etapa; a primeira etapa é um blob fechado provido pela Samsung e a segunda etapa, uma vez compilada, precisa ser enviada à hardkernel para que ela assine com sua chave privada para torná-la bootável.

    Toda a documentação restante, os softwares e o processo de suporte da hardkernel são feitos pelos fóruns da empresa. Navegando pelos fóruns específicos do XU você poderá encontrar tópicos anunciando novos BSP (Android, Ubuntu, Fedora e outros que vão aparecendo com o amadurecimento da plataforma e também contribuições de seus usuários) e documentações, assim como muita discussão geral sobre o dispositivo. Quando houver instruções detalhadas sobre uso dos GPIO do ODROID-XU, por exemplo, elas aparecerão em um tópico fixo promovido pelos administradores, assim como o post contendo novas versões do kernel.

    O kernel Linux usado tanto pelo Android quanto o Ubuntu atualmente liberado para o XU é o 3.4.5 e como tal ainda não tem o modo de Global Task Scheduling, também conhecido como MP, que permite usar os 8 cores simultaneamente (e tratá-los separadamente, ao invés de em pares). Ao fazer o clássico cat /proc/cpuinfo você verá somente 4 cores, cujo processamento pode estar ocorrendo em um Cortex-A7 ou Cortex-A15 no momento – algo somente visível atualmente pelas ferramentas de análise do ODROID XU+E.

    A gravação de BSP para uso inicial do dispositivo pode ser um pouco complicada para novatos. Em especial, o método de gravação do Android terá variações caso seja feito na eMMC ou em um cartão MicroSD (isso não ocorre com o Ubuntu). Caso se compre a eMMC, ela já vem gravada com o Android pronto para bootar; a compra da eMMC inclui um adaptador para conectá-la ao computador como se fosse um MicroSD, conforme se vê na foto.

A eMMC sendo removida e conectada ao gravador de eMMC (incluso na compra dela)

    Embora no caso de uso do Ubuntu a aceleração por hardware ainda não esteja funcionando, é esperado que isso esteja pronto em poucas semanas com a receita para isso disponível nos fóruns, em novas versões da BSP — como ocorreu com os outros modelos de ODROID.

ODROID-XU sendo usado como desktop comum rodando Ubuntu 13.04, com interface XFCE (visto que o Unity não funciona devido à falta do OpenGL)

    O ODROID-XU é um dispositivo acessível e poderoso, e sendo representante de uma tecnologia tão promissora como a big.LITTLE, é uma ferramenta valiosa para uso educacional. Seu poder de processamento e sistemas operacionais disponíveis também o torna mais que adequado para exploração do uso como desktop, media center ou ainda central de jogos. Para a redação deste artigo, preparamos um pequeno benchmark – que não leva em conta a GPU – em relação a outros dispositivos ARM e um PC. Usamos o Unixbench 5.1.3, baseado na suíte de benchmarks da revista Byte. A tabela está ordenada do menos veloz ao mais veloz, com o PC (um Athlon quad-core de 3 GHz) representando 100%.

Dispositivo	Distribuição	SoC (CPUs)	MHz	Placar	%
CuBox	Ubuntu 12.10 (com memória reservada para Vídeo RAM)	Marvell Armada 510 (1x Cortex-A9)	800	88.7	03.57
Raspberry Pi	Debian GNU/Linux 7.1 (Raspbian)	Broadcom BCM2835 (1xARM1176JZF-S)	700	100.8	04.05
Beaglebone Black	Ubuntu 13.04	TI Sitara AM3359 (1 x Cortex-A8)	1000	133.1	05.35
Cubieboard	Linaro 12.11 / Ubuntu 12.04	Allwinner A10 (1 x Cortex-A8)	1000	166.1	06.68
CuBox	Ubuntu 12.10 (sem vídeo RAM)	Marvell Armada 510 (1x Cortex-A9)	800	168.7	06.79
PCDuino	Linaro 12.11 / Ubuntu 12.04	Allwinner A10 (1 x Cortex-A8)	1000	188.2	07.57
UG802	Ubuntu 12.10	RK3066 (2 x Cortex-A9)	1200	413.8	16.64
Nexus 4	Ubuntu Touch 13.10	Qualcomm Snapdragon S4 Pro APQ8064 (4 x Krait-200)	1700	436.2	17.54
Chromebook	Ubuntu 13.04	Exynos 5250 (2 x Cortex-A15)	1700	558.1	22.45
ESBC-3200	Linaro 12.03 / Ubuntu 11.10	i.MX6 Quad (4 x Cortex-A9)	1000	594.8	23.92
Nexus 7 (v.2012)	Ubuntu 13.04	Nvidia Tegra 3 (4 x Cortex-A9)	1300	624.3	25.11
Tronsmart T428*	Ubuntu 12.04	RK3188 (4 x Cortex-A9)	1600	675.0	27.15
GK802*	Ubuntu 12.04 ARMEL	i.MX6 Quad (4 x Cortex-A9)	1000	688.7	27.70
ODROID X2	Linaro 12.11 / Ubuntu 12.04	Exynos 4412 (4 x Cortex-A9)	1700	706.0	28.40
ODROID XU	Ubuntu 13.04	Exynos 5410 (4 x Cortex-A15 + 4 x Cortex-A7)	1600 & 1200	909.5	36.58
PC Comum	Ubuntu 13.04	AMD Athlon II X4	3000	2486.3	100.00

Fonte:  Embarcados

Read More

Kernel Linux 3.10 será a próxima versão com suporte de longo prazo

Segundo Kroah-Hartman, membro da Linux Foundation e responsável pelas versões estáveis ​​do kernel do Linux, o Kernel Linux 3.10 será a próxima versão com suporte de longo prazo.

Normalmente, uma distribuição Linux precisa apenas de uma versão do kernel que se enquadre às suas necessidades. Mas as empresas de Linux, como Canonical, Red Hat e SUSE, precisam de mais. Quando elas empresas constroem distribuições Linux comerciais, precisam saber que o kernel Linux de base terá suporte de longo prazo. E é exatamente isso que Greg Kroah-Hartman está dando a eles.

Kroah-Hartman explicou que escolheu o kernel 3.10, porque acredita que ele encaixa o maior conjunto de grupos que dependem dos releases de kernel de longo prazo.

A ideia de uma junção formal para um kernel do Linux “oficial” começou a existir realmente em 2011. Após alguma discussão no Google+ e na Linux Kernel Mailing List   (LKML), a ideia foi aperfeiçoada e ganhou o apoio popular na comunidade de desenvolvimento. Agora, dois anos depois, o plano tem está sendo concretizado. Nos próximos anos, empresas e distribuições Linux comerciais se basearão no kernel Linux 3.10.

Referências:

Read More

Guia LPI: Um Pouco de Teoria sobre Linux

Sempre quando se fala de linux se vem o argumento “software livre”, mas você sabia que por trás disso existe uma instituição e algumas normas reguladoras para essa liberdade?

Sim, existe! Richard Stallman fundou a “FSF - Free Software Foundation” que criou e mantém a licença “GNU GPL - GNU General Public License”. Acredito que se você está estudando linux já deve ter ouvido algo sobre esses nomes e siglas, se não ouviu, ouvirá muito por ai. :)

Então vamos lá, essas normas são divididas em 4, veja-as abaixo:

0- Liberdade para rodar o programa para quaisquer propósitos;

1- Liberdade para estudar como o programa trabalha e adaptá-lo às suas necessidades. Ter acesso ao código fonte é essencial para isso;

2- Liberdade de redistribuir cópias de forma que você possa ajudar outras pessoas;

3- liberdade para melhorar o programa e disponibilizar as melhorias para o público, de forma que toda a comunidade possa se beneficiar. Ter acesso ao código fonte é essencial também para isso.

Para mais informações sobre as GPL’s visite os sites dos mantenedores.

Outra coisa muito importante. Vamos ver, de um jeito bem simples, como funciona um linux de baixo do capô. Veja na imagem abaixo como é dividido e organizado o sistema linux e suas variantes.

Começando de baixo para cima, temos a primeira camada que é o Hardware. Acredito que não preciso explicar que o hardware são as todas aquelas plaquinhas, chips e circuitos de dentro da sua máquina.

Subindo um pouco mais temos os drivers de dispositivos. Se você vem do Windows sem dúvida que já teve problemas com esses carinhas. A função dos drivers é realizar a comunicação entre o Hardware e o Kernel (já chegaremos lá), são basicamente instruções para que o sistema consiga entender e operar alguma coisa que você espetou na sua máquina, como se fosse um pequeno manual para o sistema saber como aquilo funciona e como e quando ele deve se comunicar com a peça em questão.

Mais um passo a cima, temos o famoso Kernel. O Kernel é o núcleo do sistema. É o responsável por interpretar todas requisições feitas a partir de uma aplicação, e com essas requisições feitas interagir com o hardware, desempenhando alguma função em todas as operações que rolam num computador, por menor que sejam.

Mas só o kernel não é o suficiente para termos um sistema operacional. Ainda precisamos de alguma artimanha para o usuário poder interagir com esse tal de kernel. Para isso temos o Sistema Operacional de fato, e dentro dele algumas coisas bem interessantes que vamos ver a seguir. Essa camada tem como função auxiliar e abrigar todos os aplicativos das camadas superiores. Segundo Linus Torvalds essa “layer” não deve ser notada pelo usuário final. Algumas coisas que temos que levar em conta quando falamos de sistema operacional: tty’s, DM’s e Desktop Environment’s. Neste ponto já sabemos (ou deveríamos saber) que o linux é um sistema multi usuario. Podemos ter vários usuarios conectados no mesmo servidor, cada um desempenhando suas funções independentemente do que os outros estão fazendo. Para isso usamos os tty’s. Cada usuario que se conecta abrirá uma sessão. Esse seção é conhecida como Terminal Virtual (tty). As ”tty’s” interpretam os comandos dados por um humano e convertem os mesmos para uma linguagem que a máquina entenda.

Próximo tópico dentro do sistema que deve ser levado em conta é a DM. Não, não é as Direct Messages do Twitter, DM quer dizer Display Manager. A função do DM é gerenciar os logins no sistema e escolher qual ambiente gráfico deve ser executado para cada usuario. Os mais conhecidos são o KDM (KDE Display Manager), GDM (GNOME Display Manager) e o XDM (X Display Manager).

Seguindo a linha de raciocínio, vamos para o último ponto relevante de hoje. Vamos falar de Desktop Environment, ou em português, Ambiente de Trabalho. Esse é a carinha bonita que o usuario final vai ver. É onde todos os programas e aplicativos que necessitam de interface gráfica são abrigados.

Estamos quase chegando no final da nossa teoria. Você pode lembrar da época de escola onde dizia “mas para que eu ou usar isso tudo?” e deve ter feito essa pergunta em quanto lia todo esse texto. Eu lhes digo porque saber isso, para a prova. Esses conceitos podem cair no seu teste então fique ligado. Outro motivo é que entendendo como a coisa funciona fica mais fácil de assimilar os próximos conteúdos.

Eu fico por aqui hoje. Prometo que os próximos posts terão algo de prática.

Read More