Linus Jumps Kernel Ahead to 3.0

Last week it looked like we were, finally, going to get a version bump from 2.6 to 2.8. Instead, Linus Torvalds has bitten the bullet and tagged the first release candidate of the next kernel to 3.0.

That’s right — it looks like the next kernel release is going to go all the way to 11, er, 3.0. If you missed the discussion last week, this isn’t because the kernel is gaining massive new functionality (as it did from the 1.x to 2.0.x series), but because “it will get released close enough to the 20-year mark, which is excuse enough for me.” Sounds like a good enough reason here, too.

To be clear, 3.0 will not be a radical change. According to Torvalds, “Sure, we have the usual two thirds driver changes, and a lot of random fixes, but the point is that 3.0 is *just* about renumbering, we are very much *not* doing a KDE-4 or a Gnome-3 here. No breakage, no special scary new features, nothing at all like that. We’ve been doing time-based releases for many years now, this is in no way about features. If you want an excuse for the renumbering, you really should look at the time-based one (“20 years”) instead.”

Want to test the new kernel, check for it in the /pub/linux/kernel/v3.0 directory, though the git tree is still linux-2.6.git for now.

If we follow the “once per decade” model, it looks like we’ll have Linux 4.0 sometime in 2020.

 

As novidades do kernel 2.6.36

No dia 20 de outubro de 2010, o finlandês agora cidadão americano Linus Torvalds apresentou ao mundo a versão mais recente de seu kernel livre, o Linux 2.6.36. Com o codinome Flesh-Eating Bats with Fangs em homenagem a um morcego que recentemente invadiu a residência dos Torvalds — alguém comentou no blog de Linus que “o Batman finalmente invadiu a casa do Pinguim” — esta nova versão do Linux foi completada em 80 dias, precisamente a duração média dos últimos lançamentos de versões estáveis do kernel. Porém, com uma versão -rc a mais — recentemente, essas versões só chegavam até -rc7, mas alcançaram -rc8 desta vez — a versão estável “pareceu demorar mais do que de costume”, alegaram alguns desenvolvedores.

O kernel encolheu??? Que bom!

Pela primeira vez nos últimos vários anos, uma nova versão do kernel Linux traz menos linhas de código do que a anterior: 13,49 milhões, contra 13,54 milhões na versão 2.6.35 e 13,32 milhões no Linux 2.6.34. Curiosamente, o número de arquivos aumentou de 33,3 mil na versão anterior para 34,3 mil no Flesh-Eating Bats. Além disso, pela terceira vez consecutiva o número de commits que compõem o kernel ficou abaixo dos 10 mil, mais precisamente em 9501.

A redução no tamanho do kernel se explica pelo admirável trabalho de faxina que vem sendo feito na base de código em constante evolução. Os avanços na remoção da BKL (Big Kernel Lock), por exemplo, foram significativos nesta versão.

Vamos às novidades!

AppArmor, finalmente

AppArmor é um sistema de “controle de acesso obrigatório” (Mandatory Access Control ou simplesmente MAC). Desenvolvido pela empresa Immunix nos idos de 1998, ele foi mantido pela Novell — que adquiriu a Immunix — de 2005 a 2007, quando a fabricante do SUSE Linux Enterprise dispensou seus desenvolvedores.

O AppArmor é ativado por padrão em diversas distribuições, sendo os principais exemplos Ubuntu e SUSE Linux Enterprise (Desktop e Server). Incluído no kernel, ele passa a fazer companhia aos demais residentes SELinuxTOMOYOSMACK.

Desktops mais rápidos, mesmo sob pressão

Na área dos desktops, uma série de patches tornam o escalonador mais competente com relação à redução da latência máxima dos processos — nenhuma relação com os patches de Con Kolivas. Juntamente com as novas workqueues implementadas no kernel, o uso de múltiplas tarefas concorrentes num único sistema poderá ser significativamente mais rápido. Por último, um conjunto de patches finalmente dá alento aos pobres coitados que possuem dispositivos de bloco muito lentos. A partir do kernel 2.6.36, os sistemas conectados a esses dispositivos não mais ficarão praticamente incapacitados de reagir quando seus dispositivos — mesmo os USB — demorarem a responder.

Vídeo

Se você possui uma GPU integrada a seu processador Core i3 ou i5, poderá utilizar todos os benefícios do suporte ao Intel Intelligent Power Sharing, recurso presente nesses hardwares que permite um melhor uso — compartilhado, como sempre deveria ser — entre esses dois componentes do “pacote” presente na pastilha de silício. Os benefícios são uma espécie de “overclock” automático da GPU quando a CPU não está a todo vapor, ou então CPU e GPU mais frias e economia de energia quando não estiverem ambas sendo usadas ao máximo.

Ao trabalhar com GPUs AMD Radeon, o Linux enfim se tornou capaz de ler os sensores de temperatura dessas GPUs, entre outras novidades.

Já no campo da concorrente Nvidia, o driver KMS Nouveau passa a incluir suporte — embora ainda básico — às GPUs Fermi presentes na recente série GeForce 400.

Controle remoto via infravermelho

O uso de dispositivos infravermelhos no Linux é, historicamente, trabalhoso. Porém, isto finalmente está mudando. Com os avanços iniciados no Linux 2.6.35, o kernel agora oferece interfaces utilizáveis pelo utilitário LIRC, que por sua vez faz a interface com transmissores e receptores infravermelhos. Com isso, os drivers, antes mantidos no espaço do usuário junto ao próprio LIRC, estão sendo migrados, pouco a pouco, para dentro do kernel.

Compressão de memória mudou de nome novamente

Compcache? Não, o nome mudou para Ramzswap. E quando finalmente foi incorporado ao kernel 2.6.36, o dispositivos de blocos compactado na memória RAM recebeu um novo nome: Zram.

Para usar o Zram, basta ativá-lo nos drivers staging e carregá-lo (chama-se zram). Com isso, cria-se ao menos um dispositivo de blocos compactado, em /dev/zram0. É possível encomendar mais dispositivos por meio de uma opção de carregamento do módulo zram. Para definir seu tamanho, não é mais necessário um utilitário, pois seus controles mudaram dos ioctls para o sysfs. O resultado: basta usar echo 100000 > /sys/block/zram0/size para definir um tamanho de 100 MB para o dispositivo zram0.

Nota: em testes na minha própria máquina, este método não funcionou, pois o sysfs não permitiu a gravação de novos dados no arquivo /sys/block/zram0/size.

Matador mais competente

Quando seu sistema utiliza toda a memória RAM disponível, ele passa a recorrer ao espaço de swap. Quando acaba o swap… alguém (algum processo, é claro!) precisa morrer. O matador de processos se chama OOM (out-of-memory) Killer, e não é sempre tão inteligente. Porém, seus desenvolvedores perceberam que é sempre bom ter um pouco mais de inteligência, mesmo que seu trabalho seja apenas apertar um gatilho. O OOM Killer agora é capaz de tomar melhores decisões a respeito de quais processos matar a fim de liberar a tão valiosa memória.

Novos processadores, nova arquitetura

Uma nova arquitetura de CPU, que ainda nem existe na prática, chamada Tilera, já conta com suporte oficial do Linux. É mais um caso que demonstra a rapidez de evolução e adoção de novas tecnologias típica do Software Livre e, em particular, do kernel Linux. Se a Tilera entregar o que promete, poderemos ter um salto interessante no poder computacional disponível em máquinas comuns.

Já nas arquiteturas tradicionalmente suportadas, o Linux agora funciona com CPUs Tegra da Nvidia, baseadas em ARM.

Novas opções de compilação

Os novos alvos de compilação oldnoconfiglistnewconfigalldefconfigsavedefconfig já foram usados pelos desenvolvedores para eliminar mais de 200 mil linhas de código referentes a arquivos de configuração padrão para as várias arquiteturas suportadas pelo Linux. De certa forma, é como se eles pudessem agora usar um diff dos arquivos de configuração padrão, em vez de uma cópia completa do arquivo de configuração padrão somada às configurações padrão daquela arquitetura específica. Viu como a redução do código foi boa? 🙂

Virtualização

KVM e Xen são grandes concorrentes, mas cada vez mais semelhantes. Os desenvolvedores do KVM acrescentaram alguns recursos que permitem uma espécie de suporte reduzido à execução do Linux como Dom0. Seria este o começo da união entre os dois principais tipos de hypervisors do kernel Linux? Resultados das atuais discussões na LKML poderão ser vistos em uma versão bem próxima do kernel.

Fanotify

A tão prometida e desejada varredura de arquivos sob demanda — imagine isso num sistema antivírus — está mais próxima: o novo sistema Fanotify entrou, embora “de leve”, no kernel. No entanto, vem desativado por padrão em virtude de discordâncias quanto à sua API. A tendência é que o Fanotify substitua as duas “gambiarras” usadas até o momento (sem grande sucesso) para esse mesmo propósito, fsnotifydnotify. O Fanotify é uma estrutura do subsistema de sistemas de arquivos capaz de enviar mensagens ao espaço de usuário (por exemplo, a um software antivírus) informando sobre a abertura, alteração ou fechamento de arquivos. Assim que ela ficar pronta, podemos esperar que seja muito usada em diversos tipos de programas.

Sistemas de arquivos

Quem acessa compartilhamentos remotos via NFS já testemunhou, a partir do kernel 2.6.30, os benefícios do cache local de sistemas de arquivos remotos. A boa notícia: se você usa CIFS para isso, finalmente sua hora chegou. Sistemas de arquivos CIFS agora já têm suporte a essa estrutura, chamada FS-Cache.

No campo do já antigo sistema de arquivos Ext3, a onda retrô levou os desenvolvedores a tornar padrão, novamente, a opção de montagem data=ordered. Ela oferece maior segurança e menor desempenho do que o “antigo novo padrão”, data=writeback.

De forma genérica, o XFS também recebeu vários patches destinados a “melhorar seu desempenho em vários trechos”.

A redundância de subsistemas para lidar com RAID também está finalmente diminuindo. Enquanto o Btrfs recebeu grandes trechos de código do subsistema MD para acrescentar ao futuro sistema de arquivos padrão recursos de RAID 6, o subsistema DM (device mapper) começa a ceder seu código de RAID 5 para outros trechos, de forma a permitir, no futuro, que o utilitário dmraid gerencie também implementações de RAID em drivers de controladoras etc.

Quem usa discos SSD agora também terá mais uma ajuda do subsistema DM, que ganha suporte ao comando discard, capaz de informar que determinada área de dados está disponível — economizando assim um novo ciclo de leitura em todos os blocos que a compõem e estendendo a vida útil dos dispositivos. Tudo isso depende, todavia, da existência de suporte ao comando discard por parte do disco e de sua respectiva controladora.

KGDB + KDB + KMS

Esta sopa de letrinhas tem um significado especial para os desenvolvedores do kernel. O depurador do kernel, KDB (kernel debugger), agora trabalha em parceria com o driver Intel KMS. Isso significa que, na presença de uma GPU Intel que use esse driver, o KDB pode ser acessado a qualquer momento pressionando as teclas SysRqG(confira o resultado neste vídeo).

Futuro

Está em andamento uma iniciativa para aumentar a escalabilidade do VFS (Virtual Filesystem Switch), que já mostrou frutos nesta atual versão do Linux. Espera-se que haja ainda mais novidades no kernel 2.6.37. Da mesma forma, os grandes e contínuos avanços na remoção da BKL (Big Kernel Lock) sinalizam que o kernel inteiro deve ganhar mais desempenho, tanto na versão 2.6.36 quanto nas próximas.

Pode-se esperar também que a integração do KDB, neste momento restrita ao driver KMS Intel, seja incorporada aos concorrentes Nouveau e Radeon.

Este foi o último lançamento de kernel estável em 2010. A versão 2.6.37 do kernel Linux deve ser lançada em janeiro de 2011.

Post original aqui.

Hole in Linux kernel provides root rights

A flaw in the implementation of the Reliable Datagram Sockets protocol (RDS) in the Linux kernel can be exploited to gain root (also known as superuser) rights or permissions on a victim’s system. Attackers can exploit the hole to get complete control remotely once they have broken into the system. Dan Rosenberg, who discovered the vulnerability, has published an exploit for demonstration purposes; in a test conducted by The H’s associates at heise Security on Ubuntu 10.04 (64-bit), it opened a root shell.

Kernel versions 2.6.30 to 2.6.36-rc8 are said to be affected. Linux developers have already provided a patch, in the Git repository, that solves the problem. Distributors will probably be publishing new kernel versions soon. As a workaround, Rosenberg recommends preventing the kernel module from loading: echo “alias net-pf-21 off” > /etc/modprobe.d/disable-rds (as root). Most systems will not be affected as they do not use the protocol anyway.

Rosenberg says the problem came about because the kernel functions in the RDS protocol do not correctly check the addresses given when data are copied from kernel memory and user memory. As a result, local users can indicate a basic address within the kernel for a socket structure. Code can then be written into kernel memory and launched with kernel rights when certain sockets are called.

Just a few days ago, a hole in the GNU-C library’s loader was made public that also allows attackers to expand their rights on the system.

HOWTO build the RaLink RT3090 driver on Ubuntu 10.04 LTS Lucid Lynx

* This HOWTO document is placed under the public domain.
* You are free to copy, mirror, link to, or duplicate it.

This HOWTO is mirrored in two places:

* http://www.halibutdepot.org/how_to_build_rt3090_for_ubuntu_lucid/
* http://stat.case.edu/~jrt32/how_to_build_rt3090_for_ubuntu_lucid/

I have an MSI Wind U230 laptop.  The built-in wireless NIC identifies itself
as an "RaLink RT3090 Wireless 802.11n 1T/1R PCIe".  This NIC is not supported
out-of-the-box under Ubuntu 10.04 LTS (Lucid Lynx) because there is no
driver for it in the 2.6.32-22-generic kernel tree.

I searched for a solution and found that other people who are running
Lucid Lynx and using the same unsupported rt3090 NIC are getting it to work
by using the old version of the rt3090 driver packaged by Markus Heberling
in his PPA (https://launchpad.net/~markus-tisoft/+archive/rt3090).

I'm grateful to Markus Heberling for doing all of the hard work
to package RaLink's driver for Ubuntu.  But because his PPA for
the rt3090 has not been updated since Ubuntu 9.10 (Karmic Koala),
and because RaLink has released a newer version 2.3.1.4 that no one
has packaged, I don't feel comfortable relying on the old rt3090
package built for Karmic, even though it does work fine on Lucid.

Below I describe the procedure I used in order to build an rt3090-dkms
package just like the one that Markus Heberling built for Karmic Koala.
The process involves downloading the newest rt3090 driver from RaLink
(version 2.3.1.4 at the time of this writing), applying Markus Heberling's
patches against it, and building a package from the source.

Here is the procedure:

 (1) Install packages required to build packages.
     (a) sudo apt-get install build-essential
     (b) sudo apt-get install devscripts
     (c) sudo apt-get install cdbs

 (2) Define a root directory in which to download files.
     (a) cd /path/to/some/download/directory/
     (b) export DOWNLOAD=`pwd`

 (3) Get the rt3090 drivers from the manufacturer's website.
     (a) Option 1: Use the pre-saved RaLink tarball from
         http://stat.case.edu/~jrt32/how_to_build_rt3090_for_ubuntu_lucid/RT3090_LinuxSTA_V2.3.1.4_20100222.tar.bz2
     (b) Option 2: Download the tarball directly from RaLink:
         Go to http://eng.ralinktech.com.tw/support.php?s=2
     (c) Download the file "RT3090PCIe".
         (RT3090_LinuxSTA_V2.3.1.4_20100222.tar.bz2)

 (4) Get Markus Heberling's Ubuntu-friendly patches against RaLink's driver tarball.
     (a) Option 1: Download a mirrored copy of Markus Heberling's patch:
         http://stat.case.edu/~jrt32/how_to_build_rt3090_for_ubuntu_lucid/rt3090_2.3.1.3-0ubuntu0~ppa1.diff.gz
     (b) Option 2: Download the patches from Markus Heberling's PPA:
         Browse to https://launchpad.net/~markus-tisoft/+archive/rt3090/+packages
     (c) Expand the release "rt3090 - 1:2.3.1.3-0ubuntu0~ppa1".
     (d) Download the patch "rt3090_2.3.1.3-0ubuntu0~ppa1.diff.gz"

 (5) Get my patch to bump the packaged version number to 2.3.1.4 .
     (a) Download this patch:
         http://stat.case.edu/~jrt32/how_to_build_rt3090_for_ubuntu_lucid/rt3090-2.3.1.3-2.3.1.4.diff

 (6) Apply patches against RaLink's drivers.
     (a) Create a staging directory:
         mkdir -p /path/to/some/staging/directory
         cd /path/to/some/staging/directory
         export STAGING=`pwd`

     (b) Extract RaLink's drivers to the staging directory.
         cd $STAGING
         tar xfj $DOWNLOAD/RT3090_LinuxSTA_V2.3.1.4_20100222.tar.bz2
         cd $STAGING/RT3090_LinuxSTA_V2.3.1.4_20100222/

     (c) Apply Markus' patches to the extracted sources.
         cd $STAGING/RT3090_LinuxSTA_V2.3.1.4_20100222/
         gzip -dc $DOWNLOAD/rt3090_2.3.1.3-0ubuntu0~ppa1.diff.gz | patch -p1

     (d) Update the version number from 2.3.1.3 to 2.3.1.4 .
         cd $STAGING/RT3090_LinuxSTA_V2.3.1.4_20100222/
         patch -p1 < $DOWNLOAD/rt3090-2.3.1.3-2.3.1.4.diff

 (7) Build a DKMS-friendly .deb package.
     (a) cd $STAGING/RT3090_LinuxSTA_V2.3.1.4_20100222/
     (b) dpkg-buildpackage -A -sa -us -uc
     (c) An installable .deb package gets created and stored as
         $STAGING/rt3090-dkms_2.3.1.4-0ubuntu0~ppa1_all.deb
     (d) Optional: You may download my pre-built rt3090-dkms package here:
         http://stat.case.edu/~jrt32/how_to_build_rt3090_for_ubuntu_lucid/rt3090-dkms_2.3.1.4-0ubuntu0~ppa1_all.deb

 (8) Install the newly-built package.
     (a) sudo dpkg -i $STAGING/rt3090-dkms_2.3.1.4-0ubuntu0~ppa1_all.deb
     (b) sudo reboot

 (9) Appendix: Automatically rebuilding the module via DKMS.
     Sometimes I switch to a different kernel (such as the one provided
     in the package "linux-rt").  This breaks the wireless NIC because
     the module hasn't yet been built and installed in the new kernel.
     Because we built a DKMS module, we can have it rebuilt automatically
     after we reboot into a new kernel:
     (a) sudo dkms build -m rt3090 -v 2.3.1.4
     (b) sudo dkms install -m rt3090 -v 2.3.1.4