Sério...
Seja o apt do Debian/Ubuntu, o yum do Fedora/RHEL, urpmi do Mandriva, portage do Gentoo, pacman do ArchLinux... todos me fazem ter um péssimo hábito:
O de simplesmente dar um update e ter todos os seus aplicativos atualizados (ok... nas distros não tão bleeding edge, não é tanto assim, mas com lançamentos de 6 em 6 meses é um bom ritmo).
Estava eu aqui no Windows depois de um pouquinho de Eve-Online... tentando usar meu VLC quando fui ver a versão dele... 0.8.6d =X
1 ano de idade... um simples "[gerenciador] update" seria muito mais fácil =]
PS: Recorde de post com mais links por m2.
Mostrando postagens com marcador linux. Mostrar todas as postagens
Mostrando postagens com marcador linux. Mostrar todas as postagens
sexta-feira, 30 de janeiro de 2009
terça-feira, 27 de janeiro de 2009
VMWare Server e seu registro...
Ontem estava eu querendo virtualizar um Scientific Linux como disse post anterior.
Então fui no site do VMWare Server 2, que é uma versão gratuita.
A primeiro coisa que fiz, foi clicar em "Forgot your password?" para ver se por algum milagre divino eu ja tinha uma conta nessa budega. Ok, no donuts for you.
Ok... coloco meu nome, sobre nome e e-mail e rezo para que isto seja tudo.
E como - quase - sempre estou redondamente enganado e eles podem somente mais alguns dados:
Puta que pariu! Só faltou o tipo sanguíneo (não... deve estar mais para baixo, já que tinha mais coisa para preencher).
Me revoltei... eu sabia que dava pra baixar a versão Server 1.x aqui, mas eu queria a versão 2 porcaria! (Sim, era birra.)
Então fui eu catar alternativas... ou seja, fui direto pro site do outro que eu lembrava... o VirtualBox. Baixei, instalei e ta funcionando que é uma beleza!
E quantos dados eu precisei colocar? Err... nenhum =]
Então fui no site do VMWare Server 2, que é uma versão gratuita.
A primeiro coisa que fiz, foi clicar em "Forgot your password?" para ver se por algum milagre divino eu ja tinha uma conta nessa budega. Ok, no donuts for you.
Ok... coloco meu nome, sobre nome e e-mail e rezo para que isto seja tudo.
E como - quase - sempre estou redondamente enganado e eles podem somente mais alguns dados:
Puta que pariu! Só faltou o tipo sanguíneo (não... deve estar mais para baixo, já que tinha mais coisa para preencher).
Me revoltei... eu sabia que dava pra baixar a versão Server 1.x aqui, mas eu queria a versão 2 porcaria! (Sim, era birra.)
Então fui eu catar alternativas... ou seja, fui direto pro site do outro que eu lembrava... o VirtualBox. Baixei, instalei e ta funcionando que é uma beleza!
E quantos dados eu precisei colocar? Err... nenhum =]
Gato do Scientific Linux
Estava eu instalando o Scientific Linux em uma VM utilizando o VirtualBox (que está *muito* bom na versão 2.1.2 que utilizei) em cima de um CentOS 5.x (sim... parece redundante...) quando no meio da instalação vejo isso:
Primeiro eu pensei em "WTF?!" até mostrei pro Davi e gastamos um pouco o SL... mas depois eu até achei legal :P
O SL tem várias imagens legais que ficam passando no instalador dele (o Anaconda... do RHEL/Fedora)... realmente ajudou a passar o tempo (até a hora que começou a repetir tudo :P)
PS: Detalhe, apenas estava utilizando o Gnome, pois nesta instalação do CentOS só estava esse ambiente instalado. Nada contra o Gnome... mas é fato que KDE >>> Gnome :P
PPS: Para quem ainda não viu, saiu o kde 4.2 como pode ser visto aqui, aqui, aqui, aqui... e já está disponível os ebuilds para Gentoo e os pacotes para o ArchLinux ;)
Primeiro eu pensei em "WTF?!" até mostrei pro Davi e gastamos um pouco o SL... mas depois eu até achei legal :P
O SL tem várias imagens legais que ficam passando no instalador dele (o Anaconda... do RHEL/Fedora)... realmente ajudou a passar o tempo (até a hora que começou a repetir tudo :P)
PS: Detalhe, apenas estava utilizando o Gnome, pois nesta instalação do CentOS só estava esse ambiente instalado. Nada contra o Gnome... mas é fato que KDE >>> Gnome :P
PPS: Para quem ainda não viu, saiu o kde 4.2 como pode ser visto aqui, aqui, aqui, aqui... e já está disponível os ebuilds para Gentoo e os pacotes para o ArchLinux ;)
domingo, 25 de janeiro de 2009
GPTS Week 3 (15/01/2009 - 21/01/2009)
Desculpem pela demora, esta foi uma semana cheio de aniversários e com pouco tempo livre :P
Vamos aos números:
Log completo das eclasses, pacotes e ebuilds em:
http://www.dcc.ufrj.br/~brunobuss/gpts/20090115_20090121.output
Vamos aos números:
- 1 eclasse adicionada (go-mono) e 6 modificadas.
- 41 pacotes adicionados e 11 removidos.
- 307 ebuilds adicionadas e 176 removidas.
Log completo das eclasses, pacotes e ebuilds em:
http://www.dcc.ufrj.br/~brunobuss/gpts/20090115_20090121.output
sexta-feira, 16 de janeiro de 2009
RTFM e JFGI tem hora e lugar...
Primeiro devo dizer que sou um dos adeptos mais ferrenhos do RTFM e do JFGI.
Mas faco quando sei acho que a pessoa tem o minimo de intimidade com o assunto a ser procurado. Quando por exemplo alguem do curso de CC me pergunta alguma coisa relativamente muito trivial a algum algoritmo relativamente simples.
(E sim... quando eu considero a pessoa inteligente eu costumo forcar que ela chegue na solução sozinha. Então caso eu tenha feito algo do tipo com alguem... não foi por mal, mas foi por acreditar no potencial.)
Eu espero que essa pessoa tenha capacidade de buscar, ler e entender a informação lida.
Apenas digo isso, pois recentemente vi 2 ou 3 posts comentando sobre um outro site, chamado letmegooglethatforyou.com. O que me incomodou foi o tipo do exemplo dado... no caso, alguem que tinha perguntado se "tem word para linux?" (sim word... microsoft word... editor de texto) e o autor do post recomenda enviar este link para a pessoa.
Pode ate parecer engraçado para quem entende do assunto, usa linux, etc... mas não eh para quem recebe o link.
Ainda por cima, quem faz uma pergunta nessa, pode ser apenas alguem como minha mãe, minha irma, meu tio, minha vó, que estão tentando usar o linux porque um parente mala (no caso eu) insistiu ou ate mesmo um caso extremo como isso aqui.
Sabe... eu não posso esperar que nenhuma dessas pessoas queira ler manual algum. Ainda mais de coisas relacionadas a informática.
Imagina que legal seria eu chegar e pedir para minha mãe - que e medica - um remédio para dor no músculo. Então ela vai ate o quarto, pega 4 livros de 900 paginas de medicina, me entrega, manda um RTFM e diz para eu procurar que ai nesses 4 "livrinhos" (que ela já leu, mas pra ela eh tao idiota que ela acha que consigo achar sozinho) o que causa esse tipo de dor e como curar.
WTF?! Porra... eu só queria uma indicação de remédio!
(Claro... eu curso CC, sei procurar no Google... então isso significa que eu devo me auto-medicar sempre que quiser?)
Acho que deve ser exatamente assim que alguem - fora do "mundo da informática" - deve se sentir quando leva um RTFM na cara ou um JFGI.
Alem disso.,.. essa atitude não ajuda em muito a incentivar as pessoas a trocarem o Windows por um SO livre... a menos que elas gostem da idéia de quem usa esse SO livre vire um completo babaca com os outros iniciantes.
Mas faco quando sei acho que a pessoa tem o minimo de intimidade com o assunto a ser procurado. Quando por exemplo alguem do curso de CC me pergunta alguma coisa relativamente muito trivial a algum algoritmo relativamente simples.
(E sim... quando eu considero a pessoa inteligente eu costumo forcar que ela chegue na solução sozinha. Então caso eu tenha feito algo do tipo com alguem... não foi por mal, mas foi por acreditar no potencial.)
Eu espero que essa pessoa tenha capacidade de buscar, ler e entender a informação lida.
Apenas digo isso, pois recentemente vi 2 ou 3 posts comentando sobre um outro site, chamado letmegooglethatforyou.com. O que me incomodou foi o tipo do exemplo dado... no caso, alguem que tinha perguntado se "tem word para linux?" (sim word... microsoft word... editor de texto) e o autor do post recomenda enviar este link para a pessoa.
Pode ate parecer engraçado para quem entende do assunto, usa linux, etc... mas não eh para quem recebe o link.
Ainda por cima, quem faz uma pergunta nessa, pode ser apenas alguem como minha mãe, minha irma, meu tio, minha vó, que estão tentando usar o linux porque um parente mala (no caso eu) insistiu ou ate mesmo um caso extremo como isso aqui.
Sabe... eu não posso esperar que nenhuma dessas pessoas queira ler manual algum. Ainda mais de coisas relacionadas a informática.
Imagina que legal seria eu chegar e pedir para minha mãe - que e medica - um remédio para dor no músculo. Então ela vai ate o quarto, pega 4 livros de 900 paginas de medicina, me entrega, manda um RTFM e diz para eu procurar que ai nesses 4 "livrinhos" (que ela já leu, mas pra ela eh tao idiota que ela acha que consigo achar sozinho) o que causa esse tipo de dor e como curar.
WTF?! Porra... eu só queria uma indicação de remédio!
(Claro... eu curso CC, sei procurar no Google... então isso significa que eu devo me auto-medicar sempre que quiser?)
Acho que deve ser exatamente assim que alguem - fora do "mundo da informática" - deve se sentir quando leva um RTFM na cara ou um JFGI.
Alem disso.,.. essa atitude não ajuda em muito a incentivar as pessoas a trocarem o Windows por um SO livre... a menos que elas gostem da idéia de quem usa esse SO livre vire um completo babaca com os outros iniciantes.
GPTS Week 2 (08/01/2009 - 14/01/2009)
Ainda não introduzi nenhuma feature nova na geração do relatório, então por enquanto apenas os dados de ebuilds/packages adicionados/removidos e eclasses adicionadas/removidas/alteradas estão sendo gerados.
Vamos aos números:
Log completo das eclasses, pacotes e ebuilds em:
http://www.dcc.ufrj.br/~brunobuss/gpts/20090108_20090114.output
Vamos aos números:
- 23 eclasses modificadas.
- 44 pacotes adicionados e 12 removidos.
- 626 ebuilds adicionadas e 864 removidas.
Log completo das eclasses, pacotes e ebuilds em:
http://www.dcc.ufrj.br/~brunobuss/gpts/20090108_20090114.output
quinta-feira, 8 de janeiro de 2009
GPTS Week 1 (01/01/2009 - 07/01/2009)
Vamos ao nosso "mini" relatório da primeira semana.
Tivemos:
Log completo das eclasses, pacotes e ebuilds em:
http://www.dcc.ufrj.br/~brunobuss/gpts/20081231_20090107.output
Tivemos:
- 14 eclasses modificadas.
- 29 pacotes adicionados e 8 removidos.
- 271 ebuilds adicionadas e 304 removidas.
Log completo das eclasses, pacotes e ebuilds em:
http://www.dcc.ufrj.br/~brunobuss/gpts/20081231_20090107.output
Novo Projeto: Gentoo Portage Tree Status
Gostaria de apresentar a todos o meu novo projeto pessoal, o GPTS (Gentoo Portage Tree Status).
Eh mais um projeto estatístico do que qualquer outra coisa... talvez por eu sentir um pouca a falta do GWN, ou por somente gostar de acompanhar a atividade no repositório oficial...
Bem, o projeto visa em fazer um relatório semanal e mensal sobre:
* Packages adicionados e removidos da arvore.
* Ebuild adicionados e removidos da arvore.
* Eclasses adicionadas, removidas e modificadas.
Claro, o projeto continuara avançando e pretendo adicionar:
* USE Flags novas, modificadas, removidas.
* Modificações nos profiles
* Modificações do p.mask
* Modificações, adições e remoções de patches dos ebuilds
* Gráficos para melhor demonstrar a atividade na arvore do portage.
Ainda não defini quais gráficos irei fazer, mas eles também serão mensais e semanais.
Provavelmente começarei a libera-los perto da quarta semana de 2009 (ou seja, no final de janeiro e inicio de fevereiro), onde já tenha algo melhor para mostrar.
Quem tiver mais sugestões pode deixar um comentário aqui ou enviar diretamente para:
bruno dot buss at gmail dot com.
A opinião, comentários e sugestão de todos e muito importante para mim.
Por enquanto, os relatórios serão apresentados aqui no blog, e terão sempre um link para um arquivo texto contendo as informações completas (como quais foram as ebuilds adicionas/removidas, separadas por pacotes, etc...)
Não consegui ainda uma formatação em html que fique de boa visualização, pelo menos não aqui no Blogger.
Eh mais um projeto estatístico do que qualquer outra coisa... talvez por eu sentir um pouca a falta do GWN, ou por somente gostar de acompanhar a atividade no repositório oficial...
Bem, o projeto visa em fazer um relatório semanal e mensal sobre:
* Packages adicionados e removidos da arvore.
* Ebuild adicionados e removidos da arvore.
* Eclasses adicionadas, removidas e modificadas.
Claro, o projeto continuara avançando e pretendo adicionar:
* USE Flags novas, modificadas, removidas.
* Modificações nos profiles
* Modificações do p.mask
* Modificações, adições e remoções de patches dos ebuilds
* Gráficos para melhor demonstrar a atividade na arvore do portage.
Ainda não defini quais gráficos irei fazer, mas eles também serão mensais e semanais.
Provavelmente começarei a libera-los perto da quarta semana de 2009 (ou seja, no final de janeiro e inicio de fevereiro), onde já tenha algo melhor para mostrar.
Quem tiver mais sugestões pode deixar um comentário aqui ou enviar diretamente para:
bruno dot buss at gmail dot com.
A opinião, comentários e sugestão de todos e muito importante para mim.
Por enquanto, os relatórios serão apresentados aqui no blog, e terão sempre um link para um arquivo texto contendo as informações completas (como quais foram as ebuilds adicionas/removidas, separadas por pacotes, etc...)
Não consegui ainda uma formatação em html que fique de boa visualização, pelo menos não aqui no Blogger.
quarta-feira, 7 de janeiro de 2009
OpenSuse, tempo de vida == 12 horas.
Sim... foi o tempo que a instalação do OpenSuse 11.1 durou no meu Desktop.
Novamente... simplesmente não consegui me acostumar a ele.
Voltei ao Sabayon 4.0 e ate agora, esta tudo bem :P
Novamente... simplesmente não consegui me acostumar a ele.
Voltei ao Sabayon 4.0 e ate agora, esta tudo bem :P
segunda-feira, 29 de dezembro de 2008
Portage 2.1.6.4 em processo de estabilização
Uma nova versão estável do Portage esta chegando, e apesar do changelog não ser muito grande, temos algumas mudanças interessantes desde a série 2.1.4.x:
Vale notar que este changelog são sobre novas features e mudanças no comportamentos do Portage e não engloba os bugfixes.
Para ver todos os bugs corrigidos desde o 2.1.4.x, basta ver esta entrada no Bugzilla. Como podem ver tivemos 140+ bugs consertados nesta nova versão do Portage.
Segundo zmedico, as únicas diferenças entre esta versão e a 2.2_rcX, é que a série 2.1.6.x não suporta:
1) package sets
2) preserve-libs
3) ACCEPT_LICENSE
Retirando estas 3 novas features, o 2.2_rcX (atualmente em hardmask para estimular o uso e teste da versão 2.1.6.x) é igual a esta nova versão.
Para a estabilização da versão 2.1.6.4, esta sendo necessário que o eselect-news versão 20080320 também fique estável. O eselect-news é uma ferramenta para a leitura de notícias do gentoo, como definido na GLEP 42 (Gentoo Linux Enhancement Proposals).
Até o momento as arquiteturas amd64 e sparc já marcaram os dois ebuilds como estáveis, muito em breve as outras arquiteturas deverão estar marcando também e assim teremos o lançamento oficial do Portage 2.1.6.4.
portage-2.1.6
==================================
* FEATURES=fixpackages is now enabled by default via make.globals. Set
FEATURES="-fixpackages" in make.conf if you'd like to disable it.
* File collision protection is now enabled by default via make.globals with
FEATURES=protect-owned. In order to protect files from be overwritten or
removed a inappropriate times, it is recommended to leave protect-owned
(or the similar collision-protect feature) enabled at all times.
* The python namespace for portage has been sanitized, all portage related code
is now contained within the portage namespace. External script should be
updated accordingly, though links exist for backward compability.
* -* support in package.keywords was changed as it was inconsistent with
ACCEPT_KEYWORDS behavior (also see
http://dev.gentoo.org/~genone/docs/KEYWORDS.stupid).
Previously having -* in package.keywords matched packages with KEYWORDS="-*",
now it resets the ACCEPT_KEYWORDS list for the given atom like it does when
used in ACCEPT_KEYWORDS.
For packages that don't specify any other KEYWORDS you can use the new **
token as documented in portage(5) to disable KEYWORDS filtering completely.
portage-2.1.5
==================================
* The pkg_postinst phase is now called after the previous version of a
package has been removed. As a consequence, it is no longer possible
to call has_version in pkg_postinst to detect whether the current
install operation is an upgrade or downgrade. If this information is
needed during the pkg_postinst phase, do the has_version call in an
earlier phase (such as pkg_preinst) and store the result in a global
variable to be accessed by pkg_postinst when it is called. Bug #226505
tracks all issues related to this phase execution order change.
* The metadata-transfer feature is now disabled by default. This disables the
"Updating Portage cache" routine that used to run at the tail end of each
`emerge --sync` operation. If you use something like the sqlite module and
want to keep all metadata in that format alone (useful for querying), enable
FEATURES="metadata-transfer" in make.conf. You should also enable
FEATURES="metadata-transfer" if you have any eclasses from PORTDIR_OVERLAY
that override eclasses from PORTDIR (in this case, you may have disabled
a relevant warning message by setting PORTAGE_ECLASS_WARNING_ENABLE="0" in
make.conf).
* The parallel-fetch feature is now enabled by default. It is optimized
to avoid doing redundant checksums for previously downloaded files that have
the correct size. Run `tail -f /var/log/emerge-fetch.log` in a
terminal to view parallel-fetch progress. Add FEATURES="-parallel-fetch"
to /etc/make.conf if you want to disable this feature.
Vale notar que este changelog são sobre novas features e mudanças no comportamentos do Portage e não engloba os bugfixes.
Para ver todos os bugs corrigidos desde o 2.1.4.x, basta ver esta entrada no Bugzilla. Como podem ver tivemos 140+ bugs consertados nesta nova versão do Portage.
Segundo zmedico, as únicas diferenças entre esta versão e a 2.2_rcX, é que a série 2.1.6.x não suporta:
1) package sets
2) preserve-libs
3) ACCEPT_LICENSE
Retirando estas 3 novas features, o 2.2_rcX (atualmente em hardmask para estimular o uso e teste da versão 2.1.6.x) é igual a esta nova versão.
Para a estabilização da versão 2.1.6.4, esta sendo necessário que o eselect-news versão 20080320 também fique estável. O eselect-news é uma ferramenta para a leitura de notícias do gentoo, como definido na GLEP 42 (Gentoo Linux Enhancement Proposals).
Até o momento as arquiteturas amd64 e sparc já marcaram os dois ebuilds como estáveis, muito em breve as outras arquiteturas deverão estar marcando também e assim teremos o lançamento oficial do Portage 2.1.6.4.
domingo, 28 de dezembro de 2008
É a hora da verdade... e como ficou a minha lista de coisas a fazer em 2008?
É pessoal... faltando 3 dias para o novo ano (ou ano novo :P), resolvi verificar a minha lista de coisas que eu gostaria de ter feito em 2008 e ver o que eu fiz, o que fiz mais ou menos ou o que chutei de vez :P
Para cada coisa eu irei me dar uma pontuação:
+1 => se eu fiz direitinho
0 => se eu fiz mais ou menos
-1 => se nem com muita boa vontade da para salvar :P
Então, here we go:
Vixe... acho que vou começar mal aqui.
Perl: Apesar de ter programado uma coisa ou outra... foi muita coisa no estilo "preciso de algo rápido para resolver um treco". Um dos casos foi quando fiz um programa em Perl para automatizar uns testes de alguns programas que rodaram em paralelo utilizando PVM, MPI e OpenMP.
C/C++: Bem... talvez a parte de C++ tenha sido a menos pior. Acabei estudando um pouquinho mais de C++ por alguns motivos... mas sinceramente, nada que eu considere perto de "estudo" mesmo.
C#: Não escrevi 1 linha de código. Nada...
Asm: O máximo que fiz, foi ler os programas da Taísa :P
Então... neste ponto eu estou me dando um -1.
Subtotal: -1.
Err... vamos lá.
Em 2008-1 se não fosse a maldita Física 3, eu teria conseguido fácil. Mas como consegui na verdade me estrepar de cara nela.. meu CRA acabou indo para 7.6 no primeiro semestre.
Agora em 2008-2 eu não tenho certeza, acho pouco provável. Porém das 7 matérias que fiz (30 créditos, um recorde no meu boletim), somente a nota de 4 entraram. Como espero passar nas outras 3 com uma nota boa também... então acho que este poderá ser o período onde meu CR (do período) voltará a subir :P (Essa coisa de ir caindo 1 décimo a cada período é muito triste)
Então assim que sair as outras 3 notas eu atualizo isso aqui.
De qualquer jeito, estou me dando um 0 aqui... pois acho que não conseguirei chegar no CRA = 8, porque dei muito mole com Física 3... mas também não deixei tudo ir pro buraco, e fui relativamente bem em tudo neste segundo semestre (nem fiz PF de Física 2 e Calculo 3 \o/).
Subtotal: -1.
Essa foi mal formulada :P
Enfim... não foi perfeito, mas não foi um completo desastre.
Percebi que as vezes fica muito complicado você ler tudo que quer quando tem que dividir o tempo com livros de Calculo, Física, apostilas, etc...
Não é impossível, mas requer uma organização melhor, que não tive esse ano.
Mas os livros off-facul que li durante o ano:
Não técnicos:
- Elite da Tropa
- The Art Of Intrusion
- Field Guide to The Apocalypse, Movie Survival Skills for the End of the World
- How to Argue & Win Every Time: At Home, At Work, In Court, Everywhere, Everyday
- Where's My Jetpack?: A Guide to the Amazing Science Fiction Future that Never Arrived
- O Universo Numa Casca de Noz
Técnicos:
- Rootkits: Subverting the Windows Kernel
- Buffer Overflow Attacks: Detect, Exploit, Prevent
- Hacking Exposed: Computer Forensics
Total: 9 livros.
Não foi um espetáculo realmente... mas com muita boa vontade, posso dizer que me esforcei. Então aqui também vou me dar um 0, neutro.
Subtotal: -1.
Ok... esse foi triste e nem vale comentários.
Merecia até um -2... anyway...
Subtotal: -2.
Há! Finalmente algo que eu consegui fazer!
Começou no Workshop I, teve continuidade com as apresentações na semana da Jornada de Iniciação Científica e que finalizaram com o Workshop II.
Todas as apresentações podem ser obtidas aqui:
http://www.gris.dcc.ufrj.br/apresentacoes.php
Aqui eu acho que posso me dar um +1 \o/
Subtotal: -1.
Sacanagem... quando eu ja tava ficando feliz.
Outra negação... -1.
Subtotal: -2.
Esse foi aos 35 do segundo tempo, as foi!
No início de janeiro, resolvi tomar vergonha na cara... e aceitei a um "chamado" por voluntários ao KernelTeam do Gentoo. Apesar disso, acabei me desviando bastante para o SecurityTeam :P
Pretendo continuar contribuindo com o SecurityTeam, mas voltar a ajudar o KernelTeam =]
Hoje, minha conta no Bugzilla, contem 14 bugs reportados (13 de segurança) =]
Acho que aqui... posso me dar um +1 também. Afinal, antes tarde do que nunca... e o negócio é continuar sempre para quem sabe, conseguir me tornar um Gentoo Developer!
Subtotal: -1.
Este e o de cima foram meus maiores orgulhos :P
Meu time DCC-Drunk C Coders, junto com o Felipe (Mascote) e o Leonardo Inácio... eu realmente não esperava formar time com eles. Afinal eles tinham feito TEP e sabiam um monte de macetes/dicas... mas que foram me passando tudo durante toda esse periodo de seletiva e na maratona mesmo.
Bem, nosso time foi para a fase carioca e acabou ficando na quinta colocação.
Mesmo com 5 vagas para o RJ, infelizmente, não fomos por causa do limite de 2 times por universidade, onde a UFRJ também ficou com o terceiro e quarto lugar da fase carioca.
A fase do RJ é uma das mais fortes e disputadas, junto com a de São Paulo emho.
Times bons da PUC, UERJ e IME disputam e foi bem legal colocarmos 3 times no Top5 da fase carioca =]
De qualquer modo, é apenas mais um incentivo a este ano de 2009, para treinarmos e irmos a fase brasileira... quem sabe mundial?!
É isso... Drunk C Coders estará de volta... e com 2 garrafas de vodka e 1 de amigo zé! :P
Então... resumindo tudo, acho que posso me dar +1 aqui =]
Score final: 0.
Este foi o diff entre meus planos para 2008 e o que realmente eu fiz.
Agora esta na hora de começar a pensar nos meus objetivos para 2009. Vamos ver... e que em 2009 eu consiga um score positivo =]
Para cada coisa eu irei me dar uma pontuação:
+1 => se eu fiz direitinho
0 => se eu fiz mais ou menos
-1 => se nem com muita boa vontade da para salvar :P
Então, here we go:
1 - Estudar (aprender ou me aprofundar em) as seguintes linguagens de programação: Perl, C/C++, C# e Assembly. De todas as existentes, quero dar mais ênfase nestas 4 este ano.
Vixe... acho que vou começar mal aqui.
Perl: Apesar de ter programado uma coisa ou outra... foi muita coisa no estilo "preciso de algo rápido para resolver um treco". Um dos casos foi quando fiz um programa em Perl para automatizar uns testes de alguns programas que rodaram em paralelo utilizando PVM, MPI e OpenMP.
C/C++: Bem... talvez a parte de C++ tenha sido a menos pior. Acabei estudando um pouquinho mais de C++ por alguns motivos... mas sinceramente, nada que eu considere perto de "estudo" mesmo.
C#: Não escrevi 1 linha de código. Nada...
Asm: O máximo que fiz, foi ler os programas da Taísa :P
Então... neste ponto eu estou me dando um -1.
Subtotal: -1.
2 - Elevar meu CRA na faculdade para > 8. Sim, não está dos piores, 7.7. Mas quero subir ele para acima de 8.
Err... vamos lá.
Em 2008-1 se não fosse a maldita Física 3, eu teria conseguido fácil. Mas como consegui na verdade me estrepar de cara nela.. meu CRA acabou indo para 7.6 no primeiro semestre.
Agora em 2008-2 eu não tenho certeza, acho pouco provável. Porém das 7 matérias que fiz (30 créditos, um recorde no meu boletim), somente a nota de 4 entraram. Como espero passar nas outras 3 com uma nota boa também... então acho que este poderá ser o período onde meu CR (do período) voltará a subir :P (Essa coisa de ir caindo 1 décimo a cada período é muito triste)
Então assim que sair as outras 3 notas eu atualizo isso aqui.
De qualquer jeito, estou me dando um 0 aqui... pois acho que não conseguirei chegar no CRA = 8, porque dei muito mole com Física 3... mas também não deixei tudo ir pro buraco, e fui relativamente bem em tudo neste segundo semestre (nem fiz PF de Física 2 e Calculo 3 \o/).
Subtotal: -1.
3 - Ler pelo menos 1 livro técnico por mês. Mais os que eu tenho e não li por inteiro até hoje.
Essa foi mal formulada :P
Enfim... não foi perfeito, mas não foi um completo desastre.
Percebi que as vezes fica muito complicado você ler tudo que quer quando tem que dividir o tempo com livros de Calculo, Física, apostilas, etc...
Não é impossível, mas requer uma organização melhor, que não tive esse ano.
Mas os livros off-facul que li durante o ano:
Não técnicos:
- Elite da Tropa
- The Art Of Intrusion
- Field Guide to The Apocalypse, Movie Survival Skills for the End of the World
- How to Argue & Win Every Time: At Home, At Work, In Court, Everywhere, Everyday
- Where's My Jetpack?: A Guide to the Amazing Science Fiction Future that Never Arrived
- O Universo Numa Casca de Noz
Técnicos:
- Rootkits: Subverting the Windows Kernel
- Buffer Overflow Attacks: Detect, Exploit, Prevent
- Hacking Exposed: Computer Forensics
Total: 9 livros.
Não foi um espetáculo realmente... mas com muita boa vontade, posso dizer que me esforcei. Então aqui também vou me dar um 0, neutro.
Subtotal: -1.
4 - Publicar pelo menos 4 artigos/how-to/tutoriais, documentos, pelo GRIS.
Ok... esse foi triste e nem vale comentários.
Merecia até um -2... anyway...
Subtotal: -2.
5 - Fazer com que o GRIS apresente trabalhos/pesquisas próprios em pelo menos 2 eventos.
Há! Finalmente algo que eu consegui fazer!
Começou no Workshop I, teve continuidade com as apresentações na semana da Jornada de Iniciação Científica e que finalizaram com o Workshop II.
Todas as apresentações podem ser obtidas aqui:
http://www.gris.dcc.ufrj.br/apresentacoes.php
Aqui eu acho que posso me dar um +1 \o/
Subtotal: -1.
6 - Bombar no desenvolvimento do Labrador =]
Sacanagem... quando eu ja tava ficando feliz.
Outra negação... -1.
Subtotal: -2.
7 - Contribuir com pelo menos 1 destes projetos, nem que seja com patch, bug-reports, etc...: KDE, Amarok, Linux(Kernel), Gentoo/Sabayon, Fedora, Kubuntu.
Esse foi aos 35 do segundo tempo, as foi!
No início de janeiro, resolvi tomar vergonha na cara... e aceitei a um "chamado" por voluntários ao KernelTeam do Gentoo. Apesar disso, acabei me desviando bastante para o SecurityTeam :P
Pretendo continuar contribuindo com o SecurityTeam, mas voltar a ajudar o KernelTeam =]
Hoje, minha conta no Bugzilla, contem 14 bugs reportados (13 de segurança) =]
Acho que aqui... posso me dar um +1 também. Afinal, antes tarde do que nunca... e o negócio é continuar sempre para quem sabe, conseguir me tornar um Gentoo Developer!
Subtotal: -1.
8 - Participar do torneio interno de programação da UFRJ. Montar um time, participar da seletiva da UFRJ e quem sabe da etapa do RJ.
Este e o de cima foram meus maiores orgulhos :P
Meu time DCC-Drunk C Coders, junto com o Felipe (Mascote) e o Leonardo Inácio... eu realmente não esperava formar time com eles. Afinal eles tinham feito TEP e sabiam um monte de macetes/dicas... mas que foram me passando tudo durante toda esse periodo de seletiva e na maratona mesmo.
Bem, nosso time foi para a fase carioca e acabou ficando na quinta colocação.
Mesmo com 5 vagas para o RJ, infelizmente, não fomos por causa do limite de 2 times por universidade, onde a UFRJ também ficou com o terceiro e quarto lugar da fase carioca.
A fase do RJ é uma das mais fortes e disputadas, junto com a de São Paulo emho.
Times bons da PUC, UERJ e IME disputam e foi bem legal colocarmos 3 times no Top5 da fase carioca =]
De qualquer modo, é apenas mais um incentivo a este ano de 2009, para treinarmos e irmos a fase brasileira... quem sabe mundial?!
É isso... Drunk C Coders estará de volta... e com 2 garrafas de vodka e 1 de amigo zé! :P
Então... resumindo tudo, acho que posso me dar +1 aqui =]
Score final: 0.
Este foi o diff entre meus planos para 2008 e o que realmente eu fiz.
Agora esta na hora de começar a pensar nos meus objetivos para 2009. Vamos ver... e que em 2009 eu consiga um score positivo =]
Voltando a falar de linux...
Depois de uma semana de fanfarronice, usando o meu desktop apenas no windows para jogar, vamos voltar a parte produtiva e útil da vida :P
Hoje voltei a brincar um pouco com o git. Acho que ele me ajudará bastante em um projeto que estou querendo começar... até o dia 8, 9 de janeiro vocês deverão ve-lo =]
Quanto a situação das minhas instalações linux.
A um tempo eu ja removi o Linux Mint Fluxbox CE do meu notebook e coloquei o Gentoo. Mas ele ainda esta muito pelado... não tem praticamente quase nada... pelo menos o boot esta a jato :P
Assim que virar o ano, vou começar a moldar ele exatamente do jeito que quero =]
Ja no meu desktop... ainda estou com esse frankstein de Kubuntu com Xubuntu (era um Kubuntu que agora virou um Xubuntu através do apt-get). Seguindo alguns comentários, resolvi que vou testar o OpenSUSE 11.1 aqui no meu Desktop.
Minha experiência prévia com o OpenSUSE não foi muito boa... tendo retirado ele em menos de 16 hrs após a instalação do meu notebook :P
Enfim... esta nova versão parece boa para uma máquina que funcionará primariamente como estação de trabalho/desenvolvimento.
Mas antes de colocar outra distro, vou antes comprar um hd novo. Provavelmente um de 500 Gb da Seagate, pois esta barato (perto dos 200 reais). A minha partição de jogos, só tem 9 GBs livres! :P
Hoje eu tenho a partição windows que deve ter uns 40 GBs, uma de jogos com 60 Gbs, uma de arquivos com 160 Gbs (50% utilizada... depois de uma *boa* limpeza :P).
Para o linux, meu / tem 30 Gb (com 20 livres) e meu home tem 70 Gb (com 12 livres).
Então eu realmente quero mais espaço para o meu linux mesmo... espaço inclusive para eu ter algumas máquinas virtuais com hds-virtuais de tamanhos decentes (10, 15 GBs... pq máquina virtual com hd de 4 GBs até dá... mas é foda...).
Bem, depois eu brinco de pensar em como vou dividir e reestruturar tudo :P
Também tivemos o lançamento do Sabayon 4.0.
E assim como o Gentoo, eu também gosto muito do Sabayon (apesar de que com o novo gerenciador de pacotes ele esta se afastando bastante do Gentoo-way-of-life... muita coisa pré-compilada. Não que seja ruim... mas tira um pouco do charme do Gentoo :P
Enfim... se eu não gostar do OpenSUSE posso colocar o Gentoo no desktop (ok, pretendo fazer isso de qualquer jeito... mesmo que eu goste do OpenSUSE :P) e talvez passar o Notebook para o Sabayon, onde é mais complicado deixar compilando tudo.
PS: Esse post foi salvo pelo "Recently Closed Tabs" do Firefox, depois que a besta aqui fechou sem querer a aba.
Hoje voltei a brincar um pouco com o git. Acho que ele me ajudará bastante em um projeto que estou querendo começar... até o dia 8, 9 de janeiro vocês deverão ve-lo =]
Quanto a situação das minhas instalações linux.
A um tempo eu ja removi o Linux Mint Fluxbox CE do meu notebook e coloquei o Gentoo. Mas ele ainda esta muito pelado... não tem praticamente quase nada... pelo menos o boot esta a jato :P
Assim que virar o ano, vou começar a moldar ele exatamente do jeito que quero =]
Ja no meu desktop... ainda estou com esse frankstein de Kubuntu com Xubuntu (era um Kubuntu que agora virou um Xubuntu através do apt-get). Seguindo alguns comentários, resolvi que vou testar o OpenSUSE 11.1 aqui no meu Desktop.
Minha experiência prévia com o OpenSUSE não foi muito boa... tendo retirado ele em menos de 16 hrs após a instalação do meu notebook :P
Enfim... esta nova versão parece boa para uma máquina que funcionará primariamente como estação de trabalho/desenvolvimento.
Mas antes de colocar outra distro, vou antes comprar um hd novo. Provavelmente um de 500 Gb da Seagate, pois esta barato (perto dos 200 reais). A minha partição de jogos, só tem 9 GBs livres! :P
Hoje eu tenho a partição windows que deve ter uns 40 GBs, uma de jogos com 60 Gbs, uma de arquivos com 160 Gbs (50% utilizada... depois de uma *boa* limpeza :P).
Para o linux, meu / tem 30 Gb (com 20 livres) e meu home tem 70 Gb (com 12 livres).
Então eu realmente quero mais espaço para o meu linux mesmo... espaço inclusive para eu ter algumas máquinas virtuais com hds-virtuais de tamanhos decentes (10, 15 GBs... pq máquina virtual com hd de 4 GBs até dá... mas é foda...).
Bem, depois eu brinco de pensar em como vou dividir e reestruturar tudo :P
Também tivemos o lançamento do Sabayon 4.0.
E assim como o Gentoo, eu também gosto muito do Sabayon (apesar de que com o novo gerenciador de pacotes ele esta se afastando bastante do Gentoo-way-of-life... muita coisa pré-compilada. Não que seja ruim... mas tira um pouco do charme do Gentoo :P
Enfim... se eu não gostar do OpenSUSE posso colocar o Gentoo no desktop (ok, pretendo fazer isso de qualquer jeito... mesmo que eu goste do OpenSUSE :P) e talvez passar o Notebook para o Sabayon, onde é mais complicado deixar compilando tudo.
PS: Esse post foi salvo pelo "Recently Closed Tabs" do Firefox, depois que a besta aqui fechou sem querer a aba.
quinta-feira, 4 de dezembro de 2008
Meu primeiro bugreport no Bugzilla do Gentoo *___*
Sempre dizem que o bom filho a casa torna (ou retorna, não sei :P).
Então, aqui vou eu =D
E hoje, enviei meu primeiro bug-report ao bugzilla do gentoo:
http://bugs.gentoo.org/show_bug.cgi?id=249878
Basicamente foi um repasse de uma falha que vi na Secunia.
Uma falha no rsyslog que afetas as duas versões que estão na árvore do portage, tanto a 3.18.4 (v-3 stable) quanto a 3.21.6 (v-3 beta).
Foram lançadas as versões 3.20.1 e 3.21.8 que corrigiram um bug de bypass descrito aqui:
http://www.rsyslog.com/Article322.phtml
Logo em seguida, estas duas versões foram retiradas do ar, e foram colocadas 2 outras a 3.20.2 e a 3.21.9 que corrigiam um DoS.
Aqui esta o anúncio da 3.20.2:
http://www.rsyslog.com/Article324.phtml
E aqui o da 3.21.9:
http://www.rsyslog.com/Article327.phtml
Foi bem legal reportar o bug, e o Stupendoussteve do canal #gentoo-security me ajudou pra caramba... espero que ninguém que siga a security@gentoo.org fique *muito* puto por 1 ou 2 edits a mais que tive que fazer :P
Na verdade eu voltei a acompanhar o bugzilla mais por causa do KernelTeam do Gentoo... estão precisando mais de gente do que o SecurityTeam. Mas nada impede que eu tente ajudar os dois e foi um bom para me acostumar com o funcionamento do Bugzilla =D
Será que o primeiro bug report, a gente nunca esquece? :P
Então, aqui vou eu =D
E hoje, enviei meu primeiro bug-report ao bugzilla do gentoo:
http://bugs.gentoo.org/show_bug.cgi?id=249878
Basicamente foi um repasse de uma falha que vi na Secunia.
Uma falha no rsyslog que afetas as duas versões que estão na árvore do portage, tanto a 3.18.4 (v-3 stable) quanto a 3.21.6 (v-3 beta).
Foram lançadas as versões 3.20.1 e 3.21.8 que corrigiram um bug de bypass descrito aqui:
http://www.rsyslog.com/Article322.phtml
Logo em seguida, estas duas versões foram retiradas do ar, e foram colocadas 2 outras a 3.20.2 e a 3.21.9 que corrigiam um DoS.
Aqui esta o anúncio da 3.20.2:
http://www.rsyslog.com/Article324.phtml
E aqui o da 3.21.9:
http://www.rsyslog.com/Article327.phtml
Foi bem legal reportar o bug, e o Stupendoussteve do canal #gentoo-security me ajudou pra caramba... espero que ninguém que siga a security@gentoo.org fique *muito* puto por 1 ou 2 edits a mais que tive que fazer :P
Na verdade eu voltei a acompanhar o bugzilla mais por causa do KernelTeam do Gentoo... estão precisando mais de gente do que o SecurityTeam. Mas nada impede que eu tente ajudar os dois e foi um bom para me acostumar com o funcionamento do Bugzilla =D
Será que o primeiro bug report, a gente nunca esquece? :P
domingo, 30 de novembro de 2008
GCC -Wpadded e alinhamento de dados em uma struct
Estou lendo a documentação do GCC (sim... só por esporte) sobre as opções de warning e entre umas e outras que quero testar (mas tenho que antes ler sobre as outras flags). Então agora vou falar sobre a -Wpadded.
Basicamente, ela diz ao GCC para imprimir warnings quando for necessário fazer padding para ajustar o alinhamento de alguma struct.
(Para dúvidas do que seria o alinhamento na memória: http://en.wikipedia.org/wiki/Data_structure_alignment)
Por exemplo:
Quando compilo com -Wpadded, ele avisa:
$ gcc -o struct_align.o struct_align.c -Wpadded
struct_align.c:4: warning: padding struct to align ‘res’
struct_align.c:6: warning: padding struct size to alignment boundary
Ou seja... ele teve que fazer um padding (basicamente, encher com 0 ou porcarias que não serão utilizadas) a região entre bchar[2] e res, para poder deixar res alinhado.
E novamente, teve que fazer um padding no final, para deixar a struct toda (o final dela) alinhada.
Para comprovar isto, vamos ver que através do sizeof() vamos pegar o tamanho dos dados:
Epa!
A struct era para ter 1 int, 2 vetores de 2 chars cada e 1 double.
Logo o total deveria ser 1x4 + 2x2x1 + 1x8 = 16 bytes.
Mas por que essa joça ficou ocupando 20 bytes? Exatamente por causa do padding.
Vamos criar um mapa de como a struct deveria ficar na memória, se não houvesse o padding:
(Vamos supor que nossa memória começa no 0x0000)
0x0000 - tam
0x0004 - bchar[0]
0x0005 - bchar[1]
0x0006 - res
0x000E - bcode[0]
0x000F - bcode[1]
Ou seja, num diagrama ficaria algo assim:
Eu tentei fazer o diagrama de modo a simplificar, com cada linha contendo 4 bytes, ou seja 32 bits... o tamanho de uma palavra de dados de um processador de 32 bits (ou um de 64 operando em modo de 32 ;).
Mas como dito antes (veja o link para a wikipedia mais acima), os dados devem estar alinhados na struct, de acordo com o maior (que ocupa mais espaço) tipo de dados utilizado na struct, então o GCC insere um padding, logo ficamos assim:
0x0000 - tam
0x0004 - bchar[0]
0x0005 - bchar[1]
0x0008 - res
0x0010 - bcode[0]
0x0011 - bcode[1]
E assim no diagrama:
Até aqui temos 18 bytes utilizados (16 que queremos e 2 de padding).
Então, o GCC preenche os 2 bytes finais também (ver OBS1 no final):
Logo, temos uma estrutura que utiliza 20 bytes, quando realmente desejamos utilizar 16... isso é um overhead de 25%!
Para corrigir este tipo de problema é simples, vamos agrupar os dados que estão quebrando o alinhamento, ou seja, nesse caso vamos deixar os dois vetores de char juntos:
Poderíamos também ter movido o bcode[] para antes do res... os dois modos irão arrumar o alinhamento da struct e com isso ela passará a ocupar os 16 bytes que desejávamos. Porém eu pessoalmente acho melhor colocar todos os char[] no final, pois se desejarmos alterar o tamanho de algum deles, não teremos que nos preocupar em reorganizar tudo.
Bem... espero que tenham gostado... e pensar que escrevi isso tudo, pois só queria comentar sobre a opção -Wpadded que não é ativada pelo -Wall nem pelo -Wextra :P
Para quem quiser, estou disponibilizando um fonte (struct_align.c) aqui:
http://www.dcc.ufrj.br/~brunobuss/code/struct_align.c
Todas os testes foram feitos com a seguinte versão do GCC:
$ gcc --version
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
OBS1:
Naquele caso, o gcc preencheu o final da struct, pois na mesma tínhamos dados que eram alinhados em 4 bytes (ou múltiplos de 4 bytes), em um caso de uma struct do tipo:
O GCC não irá incluir nenhum padding, pois não será necessário alinhar a estrutura. Logo esta struct irá ocupar 9 bytes como esperado.
Porem, caso tenhamos:
O GCC irá fazer padding no final da struct para alinha-la com o short, ou seja... caso o tamanho de b, não seja múltiplo de 2 (short == 2 bytes), então o GCC irá colocar um byte a mais para o alinhamento.
Basicamente, ela diz ao GCC para imprimir warnings quando for necessário fazer padding para ajustar o alinhamento de alguma struct.
(Para dúvidas do que seria o alinhamento na memória: http://en.wikipedia.org/wiki/Data_structure_alignment)
Por exemplo:
typedef struct _mystruct{
int tam;
char bchar[2];
double res;
char bcode[2];
} mystruct;Quando compilo com -Wpadded, ele avisa:
$ gcc -o struct_align.o struct_align.c -Wpadded
struct_align.c:4: warning: padding struct to align ‘res’
struct_align.c:6: warning: padding struct size to alignment boundary
Ou seja... ele teve que fazer um padding (basicamente, encher com 0 ou porcarias que não serão utilizadas) a região entre bchar[2] e res, para poder deixar res alinhado.
E novamente, teve que fazer um padding no final, para deixar a struct toda (o final dela) alinhada.
Para comprovar isto, vamos ver que através do sizeof() vamos pegar o tamanho dos dados:
Sizes:
-int = 4
-char = 1
-double = 8
-mystruct = 20
Epa!
A struct era para ter 1 int, 2 vetores de 2 chars cada e 1 double.
Logo o total deveria ser 1x4 + 2x2x1 + 1x8 = 16 bytes.
Mas por que essa joça ficou ocupando 20 bytes? Exatamente por causa do padding.
Vamos criar um mapa de como a struct deveria ficar na memória, se não houvesse o padding:
(Vamos supor que nossa memória começa no 0x0000)
0x0000 - tam
0x0004 - bchar[0]
0x0005 - bchar[1]
0x0006 - res
0x000E - bcode[0]
0x000F - bcode[1]
Ou seja, num diagrama ficaria algo assim:
|----------------------------------------------------|
| END | BYTE0 | BYTE1 | BYTE2 | BYTE3 |
|----------------------------------------------------|
| 0x0000 | tam | tam | tam | tam |
|----------------------------------------------------|
| 0x0004 | bchar[0] | bchar[1] | res | res |
|----------------------------------------------------|
| 0x0008 | res | res | res | res |
|----------------------------------------------------|
| 0x000C | res | res | bcode[0] | bcode[1] |
|----------------------------------------------------|
| 0x0010 | ........................................ |
|----------------------------------------------------|
Eu tentei fazer o diagrama de modo a simplificar, com cada linha contendo 4 bytes, ou seja 32 bits... o tamanho de uma palavra de dados de um processador de 32 bits (ou um de 64 operando em modo de 32 ;).
Mas como dito antes (veja o link para a wikipedia mais acima), os dados devem estar alinhados na struct, de acordo com o maior (que ocupa mais espaço) tipo de dados utilizado na struct, então o GCC insere um padding, logo ficamos assim:
0x0000 - tam
0x0004 - bchar[0]
0x0005 - bchar[1]
0x0008 - res
0x0010 - bcode[0]
0x0011 - bcode[1]
E assim no diagrama:
|----------------------------------------------------|
| END | BYTE0 | BYTE1 | BYTE2 | BYTE3 |
|----------------------------------------------------|
| 0x0000 | tam | tam | tam | tam |
|----------------------------------------------------|
| 0x0004 | bchar[0] | bchar[1] | PAD | PAD |
|----------------------------------------------------|
| 0x0008 | res | res | res | res |
|----------------------------------------------------|
| 0x000C | res | res | res | res |
|----------------------------------------------------|
| 0x0010 | bcode[0] | bcode[1] | ............... |
|----------------------------------------------------|
Até aqui temos 18 bytes utilizados (16 que queremos e 2 de padding).
Então, o GCC preenche os 2 bytes finais também (ver OBS1 no final):
|----------------------------------------------------|
| END | BYTE0 | BYTE1 | BYTE2 | BYTE3 |
|----------------------------------------------------|
| 0x0000 | tam | tam | tam | tam |
|----------------------------------------------------|
| 0x0004 | bchar[0] | bchar[1] | PAD | PAD |
|----------------------------------------------------|
| 0x0008 | res | res | res | res |
|----------------------------------------------------|
| 0x000C | res | res | res | res |
|----------------------------------------------------|
| 0x0010 | bcode[0] | bcode[1] | PAD | PAD |
|----------------------------------------------------|
| 0x0014 | ....................................... |
|----------------------------------------------------|
Logo, temos uma estrutura que utiliza 20 bytes, quando realmente desejamos utilizar 16... isso é um overhead de 25%!
Para corrigir este tipo de problema é simples, vamos agrupar os dados que estão quebrando o alinhamento, ou seja, nesse caso vamos deixar os dois vetores de char juntos:
typedef struct _mystruct_fixed{
int tam;
double res;
char bchar[2];
char bcode[2];
} mystruct_fixed;
Poderíamos também ter movido o bcode[] para antes do res... os dois modos irão arrumar o alinhamento da struct e com isso ela passará a ocupar os 16 bytes que desejávamos. Porém eu pessoalmente acho melhor colocar todos os char[] no final, pois se desejarmos alterar o tamanho de algum deles, não teremos que nos preocupar em reorganizar tudo.
Bem... espero que tenham gostado... e pensar que escrevi isso tudo, pois só queria comentar sobre a opção -Wpadded que não é ativada pelo -Wall nem pelo -Wextra :P
Para quem quiser, estou disponibilizando um fonte (struct_align.c) aqui:
http://www.dcc.ufrj.br/~brunobuss/code/struct_align.c
Todas os testes foram feitos com a seguinte versão do GCC:
$ gcc --version
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
OBS1:
Naquele caso, o gcc preencheu o final da struct, pois na mesma tínhamos dados que eram alinhados em 4 bytes (ou múltiplos de 4 bytes), em um caso de uma struct do tipo:
typedef struct _mycharstruct{
char bchar[5];
char bcode[4];
} mycharstruct;
O GCC não irá incluir nenhum padding, pois não será necessário alinhar a estrutura. Logo esta struct irá ocupar 9 bytes como esperado.
Porem, caso tenhamos:
typedef struct _myshortcharstruct{
short a;
char b[1];
} myshortcharstruct;
O GCC irá fazer padding no final da struct para alinha-la com o short, ou seja... caso o tamanho de b, não seja múltiplo de 2 (short == 2 bytes), então o GCC irá colocar um byte a mais para o alinhamento.
sábado, 22 de novembro de 2008
Oops: OpenOffice querendo alterar menu.lst?
Isto aconteceu na atualização via rede do Ubuntu 8.04 para o 8.10 no notebook do Armandinho:
WTF?
WTF?
sexta-feira, 21 de novembro de 2008
Buffer Overflow Attacks: Detect, Exploit, Prevent
Primeiro eu gostaria de dizer que eu acho que quase demorei mais tempo para escrever esse resumo/resenha do que para ler o bendito livro (tirando que tenho ele a muito tempo e somente comecei ler ele sério mesmo a pouco tempo atrás).
Bem o livro "Buffer Overflow Attacks: Detect, Exploit, Prevent", começa com uma ótima pergunta:
"Will the code you write today headline tomorrow's BugTraq mail list?"
E temos que concordar, não é uma situação muito agradável saber que seu software/sistema contem um bug que pode permitir que um atacante veja dados confidenciais, obtenha acesso de maneira indevida ou mesmo faça a aplicação toda travar. Ainda mais se for algum software que o programador gostou de trabalhar... programadores tem ciúmes de seus códigos ;)
Antes de iniciar o resumo, devo citar que o livro foi escrito por James C. Foster e contou com a ajuda de Vitaly Osipov, Nish Bhalla e Niels Heinen. Foi publicado pela Syngress e a única edição deste livro foi publicada em Fevereiro de 2005, digo isto pois todo o material de exemplo incluso é de até 2004 (e sabemos que a SI é um campo em constante evolução).
O livro contem aproximadamente 500 páginas e foi utilizado um papel, emho, de baixa qualidade.
O próprio autor divide o livre em 3 partes:
1 - Expanding on Buffer Overflows
2 - Exploiting Buffer Overflows
3 - Finding Buffer Overflows
Após cada parte há uma série de casos de estudos, que também irei comentar.
Parte 1 - Expanding on Buffer Overflows
Esta parte contem 4 capítulos com um total de 130 páginas aproximadamente, vamos ver um pouco sobre cada capítulo.
Capítulo 1: Buffer Overflows: The Essentials
Como esperado, é o capítulo de introdução, onde o autor define o que são Buffer Overflows, da algumas estatísticas baseada no número e tipo de falhas encontradas de 2001 a 2004, da um exemplo do site da Madonna hackeado e depois define uma penca de termos relacionados a Hardware, Software e Segurança.
Capítulo 2: Understanding Shellcde
Aqui ele começa introduzindo o que é um Shellcode, ferramentas úteis (NASM, GDB, ObjDumper, Ktrace (BSD), Strace (Linux) e Readelf) e faz uma introdução a assembly (mas espera que o leitor tenha conhecimento prévio) e por fim cita que o código assembly para Windows e Unix são diferentes.
Então ele começa a trabalhar nos detakges ao se escrever um Shellcode: o problema do endereçamento; o problema do byte nulo (NULL Byte, 0x00), como fazer Syscalls e mostra a diferença entre a passagem de argumentos em BSDs e Linux. E por fim da exemplos de Shellcodes para ataques remotos (port-binding) e ataques locais (execve, setuid e chroot), todos acompanhados de seus códigos em C e assembly.
Capítulo 3: Writing Shellcode
Nas 40 primeiras páginas deste capítulo ele pega alguns shellcodes do capítulo anterior (execve, port-binding) e alguns novos (reverse connection, reutilização de socket, reutilização de descritores de arquivos) e mostra a idéia, o que se quer fazer, apresenta um código em C, depois o código em assembly e explica como cada coisa funciona (comenta o código asm todo). Fala sobre codificação do shellcode, para - tentar - evitar a detecção por IDSs
Em seguida aborda como utilizar áreas de memória do próprio programa alvo para guardar dados, quando a área de payload para o shellcode é pequena e depois sobre shellcodes que podem ser utilizados em mais de um SO.
Por último faz uma engenharia reversa em um shellcode, para "descobrir" o que ele faz.
Capítulo 4: Win32 Assembly
Enquanto até agora, o foco foi em sistemas BSDs e Linux, neste capítulo passa a ser exclusivamente sobre Windows.
Ele começa mostrando como funciona o gerenciamento de memória e a Stack e a Heap.
Então ele começa (de novo) a uma introdução em assembly... registradores de índice, de stack, e outros gerais... EAX, EBX, ECX...AX, BX, CX... AL...AH...
Mostra algumas operações básicas em ams (CALL, MOV, INC, DEC, ADD, SUB, etc...) e faz um Hello World.
E foi isso o capítulo. Se isso não estivesse aqui, não faria diferença nenhuma, emho. Me pareceu mais algo que caiu de para-quedas por que a editora disse "Ei cara! Tem que colocar coisa de Windows ai!!!".
De qualquer forma, a parte 1 termina com 4 casos de estudo:
Caso 1.1 - FreeBSD NN Exploit Code
3 página de um código em Perl c/ assembly, ou seja o código do exploit.
Uma análise meia página sobre meia dúzia de linhas.
Realmente, não me acrescentou em nada... pois eu pulei.
Caso 1.2 - xlockmore User Supplied Format String Vulnerability
Começa melhor, pois mostra o trecho do código (em C) da aplicação que contem a vulnerabilidade. Mostra qual o problema. Porém, logo em seguida temos 2 paginas do dump do código do exploit (dessa vez em C + asm) e uma análise de 1/3 de página...
Muito fraco ainda, emho.
Caso 1.3 - Frontpage DoS Utilizing WinSock
Um "overview" de 1/3 de página... depois dump do código do exploit (em C + asm) de 1 página e uma análise de 1/3 de página novamente.
Depois vem um dump do "Hack.h", ocupando 6 páginas + 1 página de comentários, que são as funções de ajuda utilizadas no exploit do Frontpage.
Caso 1.4 - cURL buffer overflow on FreeBSD
Segue o mesmo do resto...2 paginas de dump do código do exploit e uma página de análise.
Eu particularmente, não gostei desses "Casos de estudo".
Primeiro porque *como* buffer overflows e ataques por strings de formatação são apenas explicados na segunda parte do livro.
Segundo por que, eu esperava de "Casos de estudo", estudar o buffer overflow e não o maldito exploit que alguem fez.... algo como desde a analise de um problema (SegFault) até achar onde se encontrava o bug e como fazer para explora-lo.
Depois de ficar um pouco desanimado com estes casos de estudo, vamos a segunda parte...
Parte 2: Exploiting Buffer Overflows
Esta é a parte principal do livro, com aproximadamente 200 páginas e demostra o funcionamento dos Buffer Overflows na stack e na heap e dos ataques via strings de formatação
Capítulo 5: Stack Overflows
Como esperado, começa iniciando com uma explicação de funcionamento da stack, volta a falar um pouco sobre asm básico e fala sobre o que fica na stack: variáveis locais, parâmetros em chamadas de funções, o EBP e o EIP salvos, etc... ou seja, mostra o que é um Stack Frame.
Em seguida vai demostrando alguns overflows na stack e suas consequências, depois passa para métodos para conseguir executar o payload (o shellcode que você colocou na memória) e depois como criar um payload adequado.
Comenta sobre os overflows "off-by-one", onde somente 1 byte a mais (devido a um erro de conta do programador) é sobre-escrito e que mesmo sendo somente 1 byte, pode trazer problemas.
Depois fala sobre as funções da biblioteca padrão do C que não são seguras como gets(), strcpy(), strcat(), sprintf(), etc... e suas versões seguras (que implicam que o programador defina um número máximo do tamanho do buffer... mas que ainda podem ser usadas erradas e causar "off-by-one" quando a conta é feita errada) como fgets(), strncpy(), strncat(), snprintf(), etc...
No final fala da dificuldade em se achar erros desse tipo na análise do código...cita analisadores léxicos (grep-like), semânticos (que funcionam como compiladores), tracers, fuzzers, etc...
Capítulo 6: Heap Corruption
Este capítulo começa com uma pequena descrição da heap e das funções em C para alocação de memória (malloc/calloc/realloc) em seguida um exemplo de Buffer Overflow em uma área alocada na heap.
Em seguida trata sobre como sobre-escrever ponteiros para funções em C++ (pois os ponteiros para as funções de uma classe ficam na heap).
E por fim, uma parte que eu gostei bastante, uma discussão sobre 2 algoritmos de gerenciamento da heap e quais as falhas que estes modelos proporcionam. Esta parte foi muito boa mesmo, tanto pela discussão do algoritmo, quanto das falhas. Os algoritmos discutidos foram o Doug Lea Malloc, que é a base do que o Linux usa hoje e o System V Malloc, utilizado no Solaris e no IRIX.
Capítulo 7: Format String Attacks
Começa com uma descrição do que são Format String, como é feita uma função em C que aceita argumentos variáveis e como utiliza-los através do va_args e mostra como tudo fica na stack e o funcionamento da função printf(), como exemplo.
Em seguida, vem a parte de como explorar strings de formatação, quando estas podem ser definidas pelo usuário e não são tratadas adequadamente pelo programa (assim como todos os problema de Buffer Overflow, que é a falta no tratamento dos dados enviados pelo usuário).
Começa demonstrando a forma mais fácil de explorar esse tipo de ataque que é causando um DoS (em contexto local... BSOD ou Kernel Panic), em seguida como ler e escrever na memória através de strings de formatação maliciosas.
E no final são discutidos os desafios ao tentar se explorar esse tipo de falha.
Capítulo 8: Windows Buffer Overflows
Preciso comentar que quando comecei este capítulo, pensei logo "Ixi... a mesma coisa que o Cap 4, caiu de para-quedas...".
Talvez depois de ler ele todo eu tenha entendido o propósito dele. Enquanto os capítulos 5 e 6, tratavam da teoria dos ataques (porem demonstrando os conceitos, só que em ambiente linux), este capitulo visa juntar toda a teoria que foi aprendida e realmente consturir um exploit para ambiente Windows.
Como eu disse, ele trata mais da construção, ou seja desde a exploração incial até a criação de um shellcode.
Uma coisa nova que ele trata é como usar e exploitar o "Structured Exception Handler" do Windows.
E aqui terminamos a Parte 2, e temos mais 5 casos de estudo:
Caso 2.1 - cURL Buffer Overflow on Linux
Uma falha de 2002, contem uma introdução pequena, 2 paginas com o código em Perl do exploit. Em seguida uma análise com o disassemble do shellcode e mais meia duzia de comentários sobre o código.
Caso 2.2 - SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability
Esse veio mais completo, contem uma introdução, seguido de detalhes da falha em si, comentários na estrutura de dados que permite a exploração e qual era o erro no código que permitia isto. Em seguida demonstra os problemas ao se tentar explorar esta falha... então a é feito um refinamento sobre a idéia do exploit e no final o código completo do exploit em C com quase 7 páginas ;)
Apesar de muito código, achei bem interessante toda a discussão feita em cima deste caso de uso.
Caso 2.3 - X11 R6 4.2 XLOCALEDIR Overflow
Uma introdução de 1/4 de página e seguido de uma analise bem legal de umas 3 paginas da vulnerabilidade. E por final o código do exploit em C, com 2 páginas aproximadamente.
Caso 2.4 - Microsoft MDAC Denial of Service
Uma introdução de meia página, seguido do código do exploit em C com 3 paginas, onde 80% é um shellcode do codigo de exploração... o que ele faz, só deus sabe. Em seguida mais 7 paginas com o arquivo hack.h de "funções úteis" para criação de exploits em C -_-'
Em seguida uma analise de 2 paginas desse codigo todo...
Caso 2.5 - Local UUX Buffer Overflow on HPUX
A coisa ficou underground agora. Mas continua no mesmo estilo... uma introdução pequena, codigo do exploit em Perl com 2 paginas e comentários sobre o código.
Os casos 2.2 e 2.3 são os que se salvam emho... anyway, continuando para a parte final do livro...
Parte 3: Finding Buffer Overflows
Esta parte contém um único capítulo e alguns casos de estudo.
E quando cheguei nela, achei que ela prometia, e muito!
Capítulo 9: Finding Buffer Overflows in Source
Este séria um dos melhores capítulos deste livro se... ele não falasse apenas de ferramentas. Ferramentas pagas, ferramentas comerciais, ferramentas opensource... cada uma analisando o código do seu jeito, etc...
Mostra como algumas funcionam, o tipo de output gerado, etc...
E é isso... e algumas das ferramentas inclusive ou não existem mais hoje...
Infelizmente, foi uma grande decepção... não que o material seja ruim, mas era melhor chamar o capítulo de "Using X, Y and Z softwares to help you in search for buffer overflows in your code" ou algo do tipo...
Acho que essa foi a parte mais patrocinada do livro :P
Em seguida temos 4 casos de estudo (que não tem nada a ver com esta parte 3...):
Caso 3.1 - InlineEgg I
Tem 2 páginas... uma introdução, o código do exploit e comentários sobre o que o exploit faz.
Alguem aqui viu algo relacionado a "como achar buffer overflows"?
Caso 3.2 - InlineEgg II
Acho que eles estavam ficando sem criatividade para escolher programas...
Uma introdução de 3 linhas (sério) seguido de uma pagina com código em exploit em Python e outra comentado o exploit.
Caso 3.3 - Seti@Home Exploit Code
Mais 4 linhas de introdução, 5 páginas com código do exploit e uma página... comentando o código do exploit.
Caso 3.4 - Microsoft CodeBlue Exploit Code
10 linhas de introdução, 4 paginas com código do exploit e uma página... de novo... comentando o código do exploit.
Apendice A: Tabela de conversão de caracteres para decimal, octal, binário, hexadecimal, etc...
Apendice B: Uma dúzia de syscalls disponíveis em sistemas Linux/BSD.
E pronto, o livro acabou.
Como provavelmente puderam perceber, eu *realmente* não gostei dos casos de estudo. Talvez eu tenha uma visão errada do que eles deveriam ser, mas pegar 10 exploits aleatórios no milw0rm e dizer que são casos de estudo, não me agrada muito.
Uma coisa legal, que esqueci de citar é que no final de cada capítulo há um resumo sobre os pontos vistos, links para sites relacionados aos assuntos abordados ou que foram comentados durante o capítulo e no final um FAQ (com umas perguntas bem aleatórias as vezes...).
Não posso dizer que seja um espetáculo de livro... mas também não é ruim.
Foi bom para revisar todos os conceitos... e sempre acaba-se aprendendo algo novo.
Ficou sendo apenas um livro... "normal".
Bem o livro "Buffer Overflow Attacks: Detect, Exploit, Prevent", começa com uma ótima pergunta:
"Will the code you write today headline tomorrow's BugTraq mail list?"
E temos que concordar, não é uma situação muito agradável saber que seu software/sistema contem um bug que pode permitir que um atacante veja dados confidenciais, obtenha acesso de maneira indevida ou mesmo faça a aplicação toda travar. Ainda mais se for algum software que o programador gostou de trabalhar... programadores tem ciúmes de seus códigos ;)
Antes de iniciar o resumo, devo citar que o livro foi escrito por James C. Foster e contou com a ajuda de Vitaly Osipov, Nish Bhalla e Niels Heinen. Foi publicado pela Syngress e a única edição deste livro foi publicada em Fevereiro de 2005, digo isto pois todo o material de exemplo incluso é de até 2004 (e sabemos que a SI é um campo em constante evolução).
O livro contem aproximadamente 500 páginas e foi utilizado um papel, emho, de baixa qualidade.
O próprio autor divide o livre em 3 partes:
1 - Expanding on Buffer Overflows
2 - Exploiting Buffer Overflows
3 - Finding Buffer Overflows
Após cada parte há uma série de casos de estudos, que também irei comentar.
Parte 1 - Expanding on Buffer Overflows
Esta parte contem 4 capítulos com um total de 130 páginas aproximadamente, vamos ver um pouco sobre cada capítulo.
Capítulo 1: Buffer Overflows: The Essentials
Como esperado, é o capítulo de introdução, onde o autor define o que são Buffer Overflows, da algumas estatísticas baseada no número e tipo de falhas encontradas de 2001 a 2004, da um exemplo do site da Madonna hackeado e depois define uma penca de termos relacionados a Hardware, Software e Segurança.
Capítulo 2: Understanding Shellcde
Aqui ele começa introduzindo o que é um Shellcode, ferramentas úteis (NASM, GDB, ObjDumper, Ktrace (BSD), Strace (Linux) e Readelf) e faz uma introdução a assembly (mas espera que o leitor tenha conhecimento prévio) e por fim cita que o código assembly para Windows e Unix são diferentes.
Então ele começa a trabalhar nos detakges ao se escrever um Shellcode: o problema do endereçamento; o problema do byte nulo (NULL Byte, 0x00), como fazer Syscalls e mostra a diferença entre a passagem de argumentos em BSDs e Linux. E por fim da exemplos de Shellcodes para ataques remotos (port-binding) e ataques locais (execve, setuid e chroot), todos acompanhados de seus códigos em C e assembly.
Capítulo 3: Writing Shellcode
Nas 40 primeiras páginas deste capítulo ele pega alguns shellcodes do capítulo anterior (execve, port-binding) e alguns novos (reverse connection, reutilização de socket, reutilização de descritores de arquivos) e mostra a idéia, o que se quer fazer, apresenta um código em C, depois o código em assembly e explica como cada coisa funciona (comenta o código asm todo). Fala sobre codificação do shellcode, para - tentar - evitar a detecção por IDSs
Em seguida aborda como utilizar áreas de memória do próprio programa alvo para guardar dados, quando a área de payload para o shellcode é pequena e depois sobre shellcodes que podem ser utilizados em mais de um SO.
Por último faz uma engenharia reversa em um shellcode, para "descobrir" o que ele faz.
Capítulo 4: Win32 Assembly
Enquanto até agora, o foco foi em sistemas BSDs e Linux, neste capítulo passa a ser exclusivamente sobre Windows.
Ele começa mostrando como funciona o gerenciamento de memória e a Stack e a Heap.
Então ele começa (de novo) a uma introdução em assembly... registradores de índice, de stack, e outros gerais... EAX, EBX, ECX...AX, BX, CX... AL...AH...
Mostra algumas operações básicas em ams (CALL, MOV, INC, DEC, ADD, SUB, etc...) e faz um Hello World.
E foi isso o capítulo. Se isso não estivesse aqui, não faria diferença nenhuma, emho. Me pareceu mais algo que caiu de para-quedas por que a editora disse "Ei cara! Tem que colocar coisa de Windows ai!!!".
De qualquer forma, a parte 1 termina com 4 casos de estudo:
Caso 1.1 - FreeBSD NN Exploit Code
3 página de um código em Perl c/ assembly, ou seja o código do exploit.
Uma análise meia página sobre meia dúzia de linhas.
Realmente, não me acrescentou em nada... pois eu pulei.
Caso 1.2 - xlockmore User Supplied Format String Vulnerability
Começa melhor, pois mostra o trecho do código (em C) da aplicação que contem a vulnerabilidade. Mostra qual o problema. Porém, logo em seguida temos 2 paginas do dump do código do exploit (dessa vez em C + asm) e uma análise de 1/3 de página...
Muito fraco ainda, emho.
Caso 1.3 - Frontpage DoS Utilizing WinSock
Um "overview" de 1/3 de página... depois dump do código do exploit (em C + asm) de 1 página e uma análise de 1/3 de página novamente.
Depois vem um dump do "Hack.h", ocupando 6 páginas + 1 página de comentários, que são as funções de ajuda utilizadas no exploit do Frontpage.
Caso 1.4 - cURL buffer overflow on FreeBSD
Segue o mesmo do resto...2 paginas de dump do código do exploit e uma página de análise.
Eu particularmente, não gostei desses "Casos de estudo".
Primeiro porque *como* buffer overflows e ataques por strings de formatação são apenas explicados na segunda parte do livro.
Segundo por que, eu esperava de "Casos de estudo", estudar o buffer overflow e não o maldito exploit que alguem fez.... algo como desde a analise de um problema (SegFault) até achar onde se encontrava o bug e como fazer para explora-lo.
Depois de ficar um pouco desanimado com estes casos de estudo, vamos a segunda parte...
Parte 2: Exploiting Buffer Overflows
Esta é a parte principal do livro, com aproximadamente 200 páginas e demostra o funcionamento dos Buffer Overflows na stack e na heap e dos ataques via strings de formatação
Capítulo 5: Stack Overflows
Como esperado, começa iniciando com uma explicação de funcionamento da stack, volta a falar um pouco sobre asm básico e fala sobre o que fica na stack: variáveis locais, parâmetros em chamadas de funções, o EBP e o EIP salvos, etc... ou seja, mostra o que é um Stack Frame.
Em seguida vai demostrando alguns overflows na stack e suas consequências, depois passa para métodos para conseguir executar o payload (o shellcode que você colocou na memória) e depois como criar um payload adequado.
Comenta sobre os overflows "off-by-one", onde somente 1 byte a mais (devido a um erro de conta do programador) é sobre-escrito e que mesmo sendo somente 1 byte, pode trazer problemas.
Depois fala sobre as funções da biblioteca padrão do C que não são seguras como gets(), strcpy(), strcat(), sprintf(), etc... e suas versões seguras (que implicam que o programador defina um número máximo do tamanho do buffer... mas que ainda podem ser usadas erradas e causar "off-by-one" quando a conta é feita errada) como fgets(), strncpy(), strncat(), snprintf(), etc...
No final fala da dificuldade em se achar erros desse tipo na análise do código...cita analisadores léxicos (grep-like), semânticos (que funcionam como compiladores), tracers, fuzzers, etc...
Capítulo 6: Heap Corruption
Este capítulo começa com uma pequena descrição da heap e das funções em C para alocação de memória (malloc/calloc/realloc) em seguida um exemplo de Buffer Overflow em uma área alocada na heap.
Em seguida trata sobre como sobre-escrever ponteiros para funções em C++ (pois os ponteiros para as funções de uma classe ficam na heap).
E por fim, uma parte que eu gostei bastante, uma discussão sobre 2 algoritmos de gerenciamento da heap e quais as falhas que estes modelos proporcionam. Esta parte foi muito boa mesmo, tanto pela discussão do algoritmo, quanto das falhas. Os algoritmos discutidos foram o Doug Lea Malloc, que é a base do que o Linux usa hoje e o System V Malloc, utilizado no Solaris e no IRIX.
Capítulo 7: Format String Attacks
Começa com uma descrição do que são Format String, como é feita uma função em C que aceita argumentos variáveis e como utiliza-los através do va_args e mostra como tudo fica na stack e o funcionamento da função printf(), como exemplo.
Em seguida, vem a parte de como explorar strings de formatação, quando estas podem ser definidas pelo usuário e não são tratadas adequadamente pelo programa (assim como todos os problema de Buffer Overflow, que é a falta no tratamento dos dados enviados pelo usuário).
Começa demonstrando a forma mais fácil de explorar esse tipo de ataque que é causando um DoS (em contexto local... BSOD ou Kernel Panic), em seguida como ler e escrever na memória através de strings de formatação maliciosas.
E no final são discutidos os desafios ao tentar se explorar esse tipo de falha.
Capítulo 8: Windows Buffer Overflows
Preciso comentar que quando comecei este capítulo, pensei logo "Ixi... a mesma coisa que o Cap 4, caiu de para-quedas...".
Talvez depois de ler ele todo eu tenha entendido o propósito dele. Enquanto os capítulos 5 e 6, tratavam da teoria dos ataques (porem demonstrando os conceitos, só que em ambiente linux), este capitulo visa juntar toda a teoria que foi aprendida e realmente consturir um exploit para ambiente Windows.
Como eu disse, ele trata mais da construção, ou seja desde a exploração incial até a criação de um shellcode.
Uma coisa nova que ele trata é como usar e exploitar o "Structured Exception Handler" do Windows.
E aqui terminamos a Parte 2, e temos mais 5 casos de estudo:
Caso 2.1 - cURL Buffer Overflow on Linux
Uma falha de 2002, contem uma introdução pequena, 2 paginas com o código em Perl do exploit. Em seguida uma análise com o disassemble do shellcode e mais meia duzia de comentários sobre o código.
Caso 2.2 - SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability
Esse veio mais completo, contem uma introdução, seguido de detalhes da falha em si, comentários na estrutura de dados que permite a exploração e qual era o erro no código que permitia isto. Em seguida demonstra os problemas ao se tentar explorar esta falha... então a é feito um refinamento sobre a idéia do exploit e no final o código completo do exploit em C com quase 7 páginas ;)
Apesar de muito código, achei bem interessante toda a discussão feita em cima deste caso de uso.
Caso 2.3 - X11 R6 4.2 XLOCALEDIR Overflow
Uma introdução de 1/4 de página e seguido de uma analise bem legal de umas 3 paginas da vulnerabilidade. E por final o código do exploit em C, com 2 páginas aproximadamente.
Caso 2.4 - Microsoft MDAC Denial of Service
Uma introdução de meia página, seguido do código do exploit em C com 3 paginas, onde 80% é um shellcode do codigo de exploração... o que ele faz, só deus sabe. Em seguida mais 7 paginas com o arquivo hack.h de "funções úteis" para criação de exploits em C -_-'
Em seguida uma analise de 2 paginas desse codigo todo...
Caso 2.5 - Local UUX Buffer Overflow on HPUX
A coisa ficou underground agora. Mas continua no mesmo estilo... uma introdução pequena, codigo do exploit em Perl com 2 paginas e comentários sobre o código.
Os casos 2.2 e 2.3 são os que se salvam emho... anyway, continuando para a parte final do livro...
Parte 3: Finding Buffer Overflows
Esta parte contém um único capítulo e alguns casos de estudo.
E quando cheguei nela, achei que ela prometia, e muito!
Capítulo 9: Finding Buffer Overflows in Source
Este séria um dos melhores capítulos deste livro se... ele não falasse apenas de ferramentas. Ferramentas pagas, ferramentas comerciais, ferramentas opensource... cada uma analisando o código do seu jeito, etc...
Mostra como algumas funcionam, o tipo de output gerado, etc...
E é isso... e algumas das ferramentas inclusive ou não existem mais hoje...
Infelizmente, foi uma grande decepção... não que o material seja ruim, mas era melhor chamar o capítulo de "Using X, Y and Z softwares to help you in search for buffer overflows in your code" ou algo do tipo...
Acho que essa foi a parte mais patrocinada do livro :P
Em seguida temos 4 casos de estudo (que não tem nada a ver com esta parte 3...):
Caso 3.1 - InlineEgg I
Tem 2 páginas... uma introdução, o código do exploit e comentários sobre o que o exploit faz.
Alguem aqui viu algo relacionado a "como achar buffer overflows"?
Caso 3.2 - InlineEgg II
Acho que eles estavam ficando sem criatividade para escolher programas...
Uma introdução de 3 linhas (sério) seguido de uma pagina com código em exploit em Python e outra comentado o exploit.
Caso 3.3 - Seti@Home Exploit Code
Mais 4 linhas de introdução, 5 páginas com código do exploit e uma página... comentando o código do exploit.
Caso 3.4 - Microsoft CodeBlue Exploit Code
10 linhas de introdução, 4 paginas com código do exploit e uma página... de novo... comentando o código do exploit.
Apendice A: Tabela de conversão de caracteres para decimal, octal, binário, hexadecimal, etc...
Apendice B: Uma dúzia de syscalls disponíveis em sistemas Linux/BSD.
E pronto, o livro acabou.
Como provavelmente puderam perceber, eu *realmente* não gostei dos casos de estudo. Talvez eu tenha uma visão errada do que eles deveriam ser, mas pegar 10 exploits aleatórios no milw0rm e dizer que são casos de estudo, não me agrada muito.
Uma coisa legal, que esqueci de citar é que no final de cada capítulo há um resumo sobre os pontos vistos, links para sites relacionados aos assuntos abordados ou que foram comentados durante o capítulo e no final um FAQ (com umas perguntas bem aleatórias as vezes...).
Não posso dizer que seja um espetáculo de livro... mas também não é ruim.
Foi bom para revisar todos os conceitos... e sempre acaba-se aprendendo algo novo.
Ficou sendo apenas um livro... "normal".
quinta-feira, 6 de novembro de 2008
Kubuntu 8.10 e alguns...err... bugs...
Como eu disse no meu post anterior... hoje, fazer atualização de distro não é algo não cabuloso.
A atualização do Kubuntu 8.04 para o 8.10 pela rede (com 1 Gb de pacotes... mais que o CD do Kubuntu 8.10) se saiu bem, atualizou tudo e agora está tudo funcionando.
Basicamente está tudo tão funcional quanto antes, apenas 3 pontos que me incomodaram e eu gostaria de destacar:
1) Anti-aliasing no KDE 4.
Quando eu rotaciono um Widget, ele fica com a borda toda picotada, depois de 2 ou 3 segundos ele alisa... mas WTF?! Isso não acontecia quando eu usava o KDE 4.0.x no Kubuntu 8.04.
E não é zica da minha placa de vídeo, pois testei na 6100 do notebook e na 8600GT do desktop.
2) Fui ligar hoje e ele reclamou que minhas configurações de vídeo/tela estavam zoadas e que por isso ele não ia mostrar nada (marrento, não?). Então ele abriu um mini-aplicativo (esse ele mostra...) para que eu escolhesse alguns passos... basicamente eu escolhi algo como refazer a configuração e detectar novamente baseado no hardware atual (não... não alterei hardware nenhum da minha máquina de ontem para hoje...).
Ele continuou tudo preto... Ctrl+Alt+Del... reiniciou e voltou... agora sim, tudo bem.
Só acho que ele deveria tentar se auto-reconfigurar... ainda mais se eu sei que instalei Kubuntu na casa da minha vó e no computador da minha irmã... elas não iriam saber (nem querer) responder esse tipo de coisa...
3) WTF!?!? O Adept novo, não tem UM botão para atualizar todos os pacotes "atualizáveis"???
Porra, ele espere que eu vá marcando de 1 em 1? Ou tem algum meio secreto que não descobri?
Além disso, achei a nova interface gráfica, muito ruim, muito pouca intuitiva... um quadrado azul vazio é algo não instalado... um verde preenchido é tudo que ta instalado e um triangulo amarelo são os atualizáveis??? O cara que fez isso fumou uma das brabas...
Então por enquanto... de volta ao Synaptic ;)
É isso, somente essas 3 coisas me incomodaram "sério".
É claro que depois de 6 meses ja com Kubuntu eu já pensei em mudar de novo... :P
Peguei o DVD do Mandriva... que foi uma das primeiras distros que usei (quando ainda era Mandrake... sei la... 7 alguma coisa...) . E tipo, eu até gosto da sinceridade deles, mas essa lista de errata é broxante:
http://wiki.mandriva.com/en/Releases/Mandriva/2008.0/Errata
Assim, é legal que eles assumem os problemas... mas acho que qualquer usuário normal que veja isso, vai desanimar :P
O Fedora 10 vai sair ai também... e como sempre é uma distro relativamente bem Bleeding Edge, o que eu gosto muito (como ja disse 45.929.347.324 vezes). Mas também não é muito estável emho... e essa preferência incondicional pelo GNOME me deixa enjoado :P
Ja cheguei a pensar de novo no Arch Linux e no Gentoo...
Uma das coisas que me preocupa para mudar de distro no meu note é a detecção da minha placa wifi... que no Kubuntu funciona tão bem (para a Broadcom que é...).
Claro que se é possível de ser feito em um, é possível de ser feito nos outros...
A atualização do Kubuntu 8.04 para o 8.10 pela rede (com 1 Gb de pacotes... mais que o CD do Kubuntu 8.10) se saiu bem, atualizou tudo e agora está tudo funcionando.
Basicamente está tudo tão funcional quanto antes, apenas 3 pontos que me incomodaram e eu gostaria de destacar:
1) Anti-aliasing no KDE 4.
Quando eu rotaciono um Widget, ele fica com a borda toda picotada, depois de 2 ou 3 segundos ele alisa... mas WTF?! Isso não acontecia quando eu usava o KDE 4.0.x no Kubuntu 8.04.
E não é zica da minha placa de vídeo, pois testei na 6100 do notebook e na 8600GT do desktop.
2) Fui ligar hoje e ele reclamou que minhas configurações de vídeo/tela estavam zoadas e que por isso ele não ia mostrar nada (marrento, não?). Então ele abriu um mini-aplicativo (esse ele mostra...) para que eu escolhesse alguns passos... basicamente eu escolhi algo como refazer a configuração e detectar novamente baseado no hardware atual (não... não alterei hardware nenhum da minha máquina de ontem para hoje...).
Ele continuou tudo preto... Ctrl+Alt+Del... reiniciou e voltou... agora sim, tudo bem.
Só acho que ele deveria tentar se auto-reconfigurar... ainda mais se eu sei que instalei Kubuntu na casa da minha vó e no computador da minha irmã... elas não iriam saber (nem querer) responder esse tipo de coisa...
3) WTF!?!? O Adept novo, não tem UM botão para atualizar todos os pacotes "atualizáveis"???
Porra, ele espere que eu vá marcando de 1 em 1? Ou tem algum meio secreto que não descobri?
Além disso, achei a nova interface gráfica, muito ruim, muito pouca intuitiva... um quadrado azul vazio é algo não instalado... um verde preenchido é tudo que ta instalado e um triangulo amarelo são os atualizáveis??? O cara que fez isso fumou uma das brabas...
Então por enquanto... de volta ao Synaptic ;)
É isso, somente essas 3 coisas me incomodaram "sério".
É claro que depois de 6 meses ja com Kubuntu eu já pensei em mudar de novo... :P
Peguei o DVD do Mandriva... que foi uma das primeiras distros que usei (quando ainda era Mandrake... sei la... 7 alguma coisa...) . E tipo, eu até gosto da sinceridade deles, mas essa lista de errata é broxante:
http://wiki.mandriva.com/en/Releases/Mandriva/2008.0/Errata
Assim, é legal que eles assumem os problemas... mas acho que qualquer usuário normal que veja isso, vai desanimar :P
O Fedora 10 vai sair ai também... e como sempre é uma distro relativamente bem Bleeding Edge, o que eu gosto muito (como ja disse 45.929.347.324 vezes). Mas também não é muito estável emho... e essa preferência incondicional pelo GNOME me deixa enjoado :P
Ja cheguei a pensar de novo no Arch Linux e no Gentoo...
Uma das coisas que me preocupa para mudar de distro no meu note é a detecção da minha placa wifi... que no Kubuntu funciona tão bem (para a Broadcom que é...).
Claro que se é possível de ser feito em um, é possível de ser feito nos outros...
domingo, 26 de outubro de 2008
Trocando de distro a cada 6 meses?
Recebi o seguinte comentário no meu post "6 meses de Arch Linux" e achei interessante alguns pontos colocados:
"O problema do linux é esse, cda 6 meses tem q mudar, pq? pq são tts distros q eles não conseguem ficar s fuçar e acaba saindo outra. A gente se ferra pq faz uma atualização q não da certo, vc precisa reinstalar o sistema, q na verdade não reisntala coisa nenhuma e vc perde td. Pior de td é q nunca uma distro é sequência da anterior. Aí é q a gente dança. Adorei o linux, usei durante 3 anos, mas sempre mudando, comprando cd e jogando pq não dava certo. Me desgostei de vez c o biglinux 4, pra comiçar uma cópia do xp, clone ou imitação, sei lá, pior msm é q mouse não funciona, da um trabalho pra fazer funcionar, depois de td pronto, td quase funcionado, faz uma atualização e pronto, mouse não funciona mais. Daí cansei, né? To c o xp, o xpsp3 ta bom, como eu já disse, parece o biglinux 4.0, única coisa chata é q ele pega uns vírus de vez em qd, mas daí a gente mata."
Olha isso não é mais tão verdade hoje em dia, emho.
Muitas distros como Fedora, (K)Ubuntu, etc.. oferecem a opção de você fazer o upgrade para uma versão mais nova. Sim, sei que isso nem sempre da certo (já deu bastante errado comigo :P).
Mas você também não precisa fazer upgrade para novas versões, ainda mais se for em um ambiente de produção (ou um PC de trabalho), aonde você não *precisa* de nenhuma funcionalidade da nova versão, talvez como um novo kernel ou novas versões de ferramentas que você usa.
Por exemplo, hoje um release normal do (K)Ubuntu tem suporte a updates de seus pacotes por até 1 ano e meio e as versões LTS tem suporte de 3 anos. O Fedora se não me engano é de 1 ano o suporte.
A diferença é que estas atualizações são somente fixes de problemas de segurança e bugs, nunca adição de novas funcionalidades (pelo menos no caso do (K)Ubuntu, não tenho certeza do Fedora pois ele é mais bleeding edge).
Uma dica que eu posso dar e é o que eu faço é utilizar seu /home em uma partição separada, pois caso o upgrade mande seu sistema para o vinagre, o *seus* dados, pelo menos os pessoais, estarão a salvo.
(Mas é claro que a política de backup pelo menos mensal - que ninguém - seria uma boa também... sabe deus quando seu HD vai para o brejo?)
Temos ainda outra classe de distros com o Arch Linux e o Gentoo que são chamadas de "Rolling Distros", ou seja distros que sempre estão atualizadas. Depois de instaladas uma única vez, se você sempre manter ela atualizada (pelo pacman no Arch e pelo portage no Gentoo), sempre terá uma instalação exatamente *igual* a qualquer nova versão que lancem.
Isso é somente uma questão de gosto e gerenciamento de pacotes... um exemplo que posso citar é o do kernel no (K)Ubuntu e no Arch.
No (K)Ubuntu 8.04, o kernel vai ser sempre o mesmo, o 2.6.24 (a menos que você pegue e compile o seu na mão... mas ai estamos roubando :P), isso durante os 3 anos (pois o 8.04 é um LTS, Long Time Suport, se não seria por 1 ano e meio), não importando quantas novas versões do kernel saiam nesse período. Quando sair o (K)Ubuntu 8.10 com kernel 2.6.27, quem quiser ficar com o 8.04 vai continuar usando o 2.6.24 e ponto.
Já no Arch, novas versões do kernel são rapidamente testadas inicialmente pelos desenvolvedores, colocadas no repositório testing e em pouco tempo ja estão no repositório principal para quem quiser usar. Assim que sair um novo CD de instalação do Arch ele estará com este mesmo novo kernel! (Se não me engano, ja teve até um caso em que o kernel do CD era mais antigo que o do repositório mesmo, ja no dia da instalação ou 1 ou 2 dias depois!)
Veja bem que uma "rolling distro" não precisa ser algo "bleeding edge".
No Arch Linux isso acaba acontecendo (mesmo sem usar o testing e outros...), mas no Gentoo por exemplo, caso você use a linha stable dele (como todos os sistemas de produção e ambientes de trabalho deveriam...) você não necessariamente tem os softwares mais atuais, mas quando um novo CD de instalação ou o que seja for lançado, você terá o mesmo sistema de quem utilizar este CD.
Por exemplo, hoje (26/10/2006) temos no Arch Linux o kernel 2.6.27.1 no repositório estável - Core - porém ja marcado como "obsoleto" por que já estamos na versão 2.6.27.4.
Porém no Gentoo a coisa é um pouco mais enrolada, como tudo é compilado pelo usuário lá, você pode pegar qualquer versão que queira, porém somente algumas são marcadas como estáveis....
Vamos lá... o pacote "vanilla-sources" que é o kernel como ele veio ao mundo, ou seja, é o kernel do kernel.org sem nenhum patch, temos as seguintes versões estáveis para x86 E AMD64:
2.6.19.7, 2.6.23.9, 2.6.23.17, 2.6.24.3, 2.6.24.4, 2.6.24.7 e a 2.6.25.9 que é a mais nova que esta marcada estável para os dois. Se formos ver somente para x86 ainda temos 2.6.25.11, 2.6.25.14 e 2.6.25.17.
Não me pergunte o por que da 2.6.25.14 e a 2.6.25.17 serem estáveis e as 2.6.25.15, 2.6.25.16 não. Coisa deles, testes deles. Mas temos todas as possíveis versões, até a 2.6.27.4 la, porém marcadas como instáveis. Pode usar? Claro que pode... mas eles tão dizendo que não colocam a mão no fogo por elas (nem nas outras eles colocam provavelmente :P).
Se você for ver então a "git-sources" (que representa a arvore de desenvolvimento do kernel) pode até pegar o kernel 2.6.28_rc1 (release candidate 1 da nova versão, a merge windows acabou de ser fechada!! É pedir para ter um kernel panic), ou mesmo o 2.6.28_rc1-git1 (o rc1 + as ultimas mudanças que fizeram de ontem pra hoje!). Claro que tudo isso é marcado como instável.
E por fim temos a "gentoo-sources" que trata de uma kernel com diversos patches aplicados pela equipe do gentoo, onde a mais estável para amd64 é o 2.6.25-r7 e para x86 é o 2.6.25-r8 (mesmo tendo ja o 2.6.27-r1)... apenas prestar atenção que esse -rX é relativo aos patches aplicados pela equipe do gentoo sobre o kernel, não confundir com o -rcX do kernel.
Voltando ao comentário... outro ponto é que concordo que existem muitas distros. Isso pode ser algo bom e ruim, mas realmente alguem novo ou que não tenha ainda escolhido uma (ou umas :P) que gosta mais, realmente fica bem perdido.
Acho que cada uma tem seus prós e contras, seria bom se fosse possível juntar todos os prós e remover todos os contras, mas infelizmente (ou seria felizmente?) cada distro tem sua filosofia de desenvolvimento, seu público alvo (Por exemplo... as vezes me sinto entediado no (K)Ubuntu. Ou então tente dar um Gentoo para quem nunca usou Linux na vida...).
E o principal temos as pessoas que colaboram e que fazem isso por que gostam de fazer e gostam do "jeito de ser" de uma determinada distro... não podemos força-las a desenvolver de outra maneira, para outro público alvo... apenas vai irrita-las ou chateá-las e não teremos mais desenvolvimento algum =/
(E pela filosofia do Software Livre... não deveríamos querer obrigar ninguém a fazer nada... aonde ao extremo, podemos fazer nós mesmo algo que não gostamos do jeito que está sendo feito :)
Sobre o BigLinux 4, eu particularmente nunca utilizei-o. Mas essa "tática" de ter um visual parecido com o XP é para ajudar o pessoal que vem do Windows, para tornar menos traumático :P.
Se todos usassem Linux/Unix desde criancinha, não seria necessário... mas crescemos usando windows 95, 98, 2000, XP, Vista, etc... (ok... eu tmb usei DOS e 3.11 xD) então ou a pessoa tem um estalo divino para usar Linux ou então a transição tem que ser amigável.
Eu acho a tela preta e a compilação de programas um charme no Linux... vai ver eu sou biruta de pedra.
Mas um usuário normal, minha mãe, minha irmã, minha vó, meu tio... aqueles que querem usar o Firefox (há... ja escondi o IE a muito tempo do computador deles :P) e ver e-mails e YouTube, querem se sentir "seguros"... do tipo "sei onde estou e sei o que estou fazendo".
Se o BigLinux consegue ser uma porta de entrada para muitas pessoas ao Software Livre eu dou meus parabéns a ele!!!
Por que se for para copiar o "visual do XP", muita gente ja copiou muita coisa do MAC e eu não uso MAC hoje por isso (eu não uso MAC porque eu sou pobre mesmo :P).
O Windows utiliza o sistema de gerenciamento de memória do BSD e não é por isso que eu utilizo o BSD (até porque essa joça não faz boot no meu notebook... -_-').
Eu particularmente, evito usar windows, não porque odeio a Microsoft, não acho que o Bill Gates é o filho do capeta e que tem a instituição dele lá que ajuda (e coloca ajuda nisso... o cara tem quase nada de dinheiro para doar) somente como faixada...
Eu uso Linux, por que GOSTO do Linux. Acho FODA o conceito de comunidade. Acho FODA PRA CARALHO o desenvolvimento colaborativo onde cada um ajuda como quer. Acho super legal a idéia do Software Livre, o conhecimento pertence ao mundo, yeah!
Mas se precisar, uso Windows de boa. (Afinal eu quero jogar também, sem ter que usar wine/cedega/etc... :P)
Não tenho problema no Windows com vírus nem com suas falhas de segurança. 99% dos vírus/worms/etc... com algumas precauções pode-se evitar facilmente. Falhas de segurança todos tem. O Linux (kernel) e os programas que utilizamos todos os dias... vixe, tem várias... eles corrigem rápido na maioria das vezes, mas isso não diz que estejam seguros... quantas pessoas não atualizam seus pacotes? Mesmo com as facilidades de hoje em dia? O mesmo vale para o Windows Update...
Infelizmente a segurança rompe no elo mais fraco... o usuário =]
(Já chegamos até em papo de segurança... acho que podemos ir parando por aqui :)
É isso... eu como disse, vou continuar utilizando meu Linux aqui e estou feliz com ele (mesmo sabendo que a minha natureza de nômade de distro, me fará mudar em breve :P).
Olha... o que eu ouço falar de nego reinstalado Windows de 6 em 6 meses... seja por que pegou vírus, ou por causa da famosa DLL Hell, ou por que o sistema travou e ferrou alguma coisa, ou então por que o registro foi para o saco, etc... (muita coisa... 99% culpa do usuário =).
Se for necessário, eu prefiro reinstalar o Linux de 6 em 6 meses... =]
"O problema do linux é esse, cda 6 meses tem q mudar, pq? pq são tts distros q eles não conseguem ficar s fuçar e acaba saindo outra. A gente se ferra pq faz uma atualização q não da certo, vc precisa reinstalar o sistema, q na verdade não reisntala coisa nenhuma e vc perde td. Pior de td é q nunca uma distro é sequência da anterior. Aí é q a gente dança. Adorei o linux, usei durante 3 anos, mas sempre mudando, comprando cd e jogando pq não dava certo. Me desgostei de vez c o biglinux 4, pra comiçar uma cópia do xp, clone ou imitação, sei lá, pior msm é q mouse não funciona, da um trabalho pra fazer funcionar, depois de td pronto, td quase funcionado, faz uma atualização e pronto, mouse não funciona mais. Daí cansei, né? To c o xp, o xpsp3 ta bom, como eu já disse, parece o biglinux 4.0, única coisa chata é q ele pega uns vírus de vez em qd, mas daí a gente mata."
Olha isso não é mais tão verdade hoje em dia, emho.
Muitas distros como Fedora, (K)Ubuntu, etc.. oferecem a opção de você fazer o upgrade para uma versão mais nova. Sim, sei que isso nem sempre da certo (já deu bastante errado comigo :P).
Mas você também não precisa fazer upgrade para novas versões, ainda mais se for em um ambiente de produção (ou um PC de trabalho), aonde você não *precisa* de nenhuma funcionalidade da nova versão, talvez como um novo kernel ou novas versões de ferramentas que você usa.
Por exemplo, hoje um release normal do (K)Ubuntu tem suporte a updates de seus pacotes por até 1 ano e meio e as versões LTS tem suporte de 3 anos. O Fedora se não me engano é de 1 ano o suporte.
A diferença é que estas atualizações são somente fixes de problemas de segurança e bugs, nunca adição de novas funcionalidades (pelo menos no caso do (K)Ubuntu, não tenho certeza do Fedora pois ele é mais bleeding edge).
Uma dica que eu posso dar e é o que eu faço é utilizar seu /home em uma partição separada, pois caso o upgrade mande seu sistema para o vinagre, o *seus* dados, pelo menos os pessoais, estarão a salvo.
(Mas é claro que a política de backup pelo menos mensal - que ninguém - seria uma boa também... sabe deus quando seu HD vai para o brejo?)
Temos ainda outra classe de distros com o Arch Linux e o Gentoo que são chamadas de "Rolling Distros", ou seja distros que sempre estão atualizadas. Depois de instaladas uma única vez, se você sempre manter ela atualizada (pelo pacman no Arch e pelo portage no Gentoo), sempre terá uma instalação exatamente *igual* a qualquer nova versão que lancem.
Isso é somente uma questão de gosto e gerenciamento de pacotes... um exemplo que posso citar é o do kernel no (K)Ubuntu e no Arch.
No (K)Ubuntu 8.04, o kernel vai ser sempre o mesmo, o 2.6.24 (a menos que você pegue e compile o seu na mão... mas ai estamos roubando :P), isso durante os 3 anos (pois o 8.04 é um LTS, Long Time Suport, se não seria por 1 ano e meio), não importando quantas novas versões do kernel saiam nesse período. Quando sair o (K)Ubuntu 8.10 com kernel 2.6.27, quem quiser ficar com o 8.04 vai continuar usando o 2.6.24 e ponto.
Já no Arch, novas versões do kernel são rapidamente testadas inicialmente pelos desenvolvedores, colocadas no repositório testing e em pouco tempo ja estão no repositório principal para quem quiser usar. Assim que sair um novo CD de instalação do Arch ele estará com este mesmo novo kernel! (Se não me engano, ja teve até um caso em que o kernel do CD era mais antigo que o do repositório mesmo, ja no dia da instalação ou 1 ou 2 dias depois!)
Veja bem que uma "rolling distro" não precisa ser algo "bleeding edge".
No Arch Linux isso acaba acontecendo (mesmo sem usar o testing e outros...), mas no Gentoo por exemplo, caso você use a linha stable dele (como todos os sistemas de produção e ambientes de trabalho deveriam...) você não necessariamente tem os softwares mais atuais, mas quando um novo CD de instalação ou o que seja for lançado, você terá o mesmo sistema de quem utilizar este CD.
Por exemplo, hoje (26/10/2006) temos no Arch Linux o kernel 2.6.27.1 no repositório estável - Core - porém ja marcado como "obsoleto" por que já estamos na versão 2.6.27.4.
Porém no Gentoo a coisa é um pouco mais enrolada, como tudo é compilado pelo usuário lá, você pode pegar qualquer versão que queira, porém somente algumas são marcadas como estáveis....
Vamos lá... o pacote "vanilla-sources" que é o kernel como ele veio ao mundo, ou seja, é o kernel do kernel.org sem nenhum patch, temos as seguintes versões estáveis para x86 E AMD64:
2.6.19.7, 2.6.23.9, 2.6.23.17, 2.6.24.3, 2.6.24.4, 2.6.24.7 e a 2.6.25.9 que é a mais nova que esta marcada estável para os dois. Se formos ver somente para x86 ainda temos 2.6.25.11, 2.6.25.14 e 2.6.25.17.
Não me pergunte o por que da 2.6.25.14 e a 2.6.25.17 serem estáveis e as 2.6.25.15, 2.6.25.16 não. Coisa deles, testes deles. Mas temos todas as possíveis versões, até a 2.6.27.4 la, porém marcadas como instáveis. Pode usar? Claro que pode... mas eles tão dizendo que não colocam a mão no fogo por elas (nem nas outras eles colocam provavelmente :P).
Se você for ver então a "git-sources" (que representa a arvore de desenvolvimento do kernel) pode até pegar o kernel 2.6.28_rc1 (release candidate 1 da nova versão, a merge windows acabou de ser fechada!! É pedir para ter um kernel panic), ou mesmo o 2.6.28_rc1-git1 (o rc1 + as ultimas mudanças que fizeram de ontem pra hoje!). Claro que tudo isso é marcado como instável.
E por fim temos a "gentoo-sources" que trata de uma kernel com diversos patches aplicados pela equipe do gentoo, onde a mais estável para amd64 é o 2.6.25-r7 e para x86 é o 2.6.25-r8 (mesmo tendo ja o 2.6.27-r1)... apenas prestar atenção que esse -rX é relativo aos patches aplicados pela equipe do gentoo sobre o kernel, não confundir com o -rcX do kernel.
Voltando ao comentário... outro ponto é que concordo que existem muitas distros. Isso pode ser algo bom e ruim, mas realmente alguem novo ou que não tenha ainda escolhido uma (ou umas :P) que gosta mais, realmente fica bem perdido.
Acho que cada uma tem seus prós e contras, seria bom se fosse possível juntar todos os prós e remover todos os contras, mas infelizmente (ou seria felizmente?) cada distro tem sua filosofia de desenvolvimento, seu público alvo (Por exemplo... as vezes me sinto entediado no (K)Ubuntu. Ou então tente dar um Gentoo para quem nunca usou Linux na vida...).
E o principal temos as pessoas que colaboram e que fazem isso por que gostam de fazer e gostam do "jeito de ser" de uma determinada distro... não podemos força-las a desenvolver de outra maneira, para outro público alvo... apenas vai irrita-las ou chateá-las e não teremos mais desenvolvimento algum =/
(E pela filosofia do Software Livre... não deveríamos querer obrigar ninguém a fazer nada... aonde ao extremo, podemos fazer nós mesmo algo que não gostamos do jeito que está sendo feito :)
Sobre o BigLinux 4, eu particularmente nunca utilizei-o. Mas essa "tática" de ter um visual parecido com o XP é para ajudar o pessoal que vem do Windows, para tornar menos traumático :P.
Se todos usassem Linux/Unix desde criancinha, não seria necessário... mas crescemos usando windows 95, 98, 2000, XP, Vista, etc... (ok... eu tmb usei DOS e 3.11 xD) então ou a pessoa tem um estalo divino para usar Linux ou então a transição tem que ser amigável.
Eu acho a tela preta e a compilação de programas um charme no Linux... vai ver eu sou biruta de pedra.
Mas um usuário normal, minha mãe, minha irmã, minha vó, meu tio... aqueles que querem usar o Firefox (há... ja escondi o IE a muito tempo do computador deles :P) e ver e-mails e YouTube, querem se sentir "seguros"... do tipo "sei onde estou e sei o que estou fazendo".
Se o BigLinux consegue ser uma porta de entrada para muitas pessoas ao Software Livre eu dou meus parabéns a ele!!!
Por que se for para copiar o "visual do XP", muita gente ja copiou muita coisa do MAC e eu não uso MAC hoje por isso (eu não uso MAC porque eu sou pobre mesmo :P).
O Windows utiliza o sistema de gerenciamento de memória do BSD e não é por isso que eu utilizo o BSD (até porque essa joça não faz boot no meu notebook... -_-').
Eu particularmente, evito usar windows, não porque odeio a Microsoft, não acho que o Bill Gates é o filho do capeta e que tem a instituição dele lá que ajuda (e coloca ajuda nisso... o cara tem quase nada de dinheiro para doar) somente como faixada...
Eu uso Linux, por que GOSTO do Linux. Acho FODA o conceito de comunidade. Acho FODA PRA CARALHO o desenvolvimento colaborativo onde cada um ajuda como quer. Acho super legal a idéia do Software Livre, o conhecimento pertence ao mundo, yeah!
Mas se precisar, uso Windows de boa. (Afinal eu quero jogar também, sem ter que usar wine/cedega/etc... :P)
Não tenho problema no Windows com vírus nem com suas falhas de segurança. 99% dos vírus/worms/etc... com algumas precauções pode-se evitar facilmente. Falhas de segurança todos tem. O Linux (kernel) e os programas que utilizamos todos os dias... vixe, tem várias... eles corrigem rápido na maioria das vezes, mas isso não diz que estejam seguros... quantas pessoas não atualizam seus pacotes? Mesmo com as facilidades de hoje em dia? O mesmo vale para o Windows Update...
Infelizmente a segurança rompe no elo mais fraco... o usuário =]
(Já chegamos até em papo de segurança... acho que podemos ir parando por aqui :)
É isso... eu como disse, vou continuar utilizando meu Linux aqui e estou feliz com ele (mesmo sabendo que a minha natureza de nômade de distro, me fará mudar em breve :P).
Olha... o que eu ouço falar de nego reinstalado Windows de 6 em 6 meses... seja por que pegou vírus, ou por causa da famosa DLL Hell, ou por que o sistema travou e ferrou alguma coisa, ou então por que o registro foi para o saco, etc... (muita coisa... 99% culpa do usuário =).
Se for necessário, eu prefiro reinstalar o Linux de 6 em 6 meses... =]
quarta-feira, 15 de outubro de 2008
Linux 2.6.27.1
Saiu uma nova versão do kernel, 2.6.27.1, com apenas um bugfix.
Este bugfix desabilita (e marca como broken) o CONFIG_DYNAMIC_FTRACE ("enable/disable ftrace tracepoints dynamically"), pois acredita-se que esta opção esteja causando uma corrupção de memória quando o módulo é descarregado e talvez este problema esteja relacionado com os recentes problemas de placas e1000.
Quem tem a 2.6.27 não precisa atualizar, pode somente desabilitar o DYNAMIC_FTRACE no seu .config e recompilar o kernel, pois como dito esta é a única mudança.
Este bugfix desabilita (e marca como broken) o CONFIG_DYNAMIC_FTRACE ("enable/disable ftrace tracepoints dynamically"), pois acredita-se que esta opção esteja causando uma corrupção de memória quando o módulo é descarregado e talvez este problema esteja relacionado com os recentes problemas de placas e1000.
Quem tem a 2.6.27 não precisa atualizar, pode somente desabilitar o DYNAMIC_FTRACE no seu .config e recompilar o kernel, pois como dito esta é a única mudança.
quinta-feira, 9 de outubro de 2008
O que esperar do Linux 2.6.27
O Linux 2.6.27 já esta em seu rc9, e em breve deverá acabou de ser lançado.
Mesmo o bug das placas de rede e1000e não tendo sido corrigido, o kernel conta com uma série de fixes que impedem que seja causado algum dano ao hardware.
Anyway, vamos dar uma olhada no quepodemos esperar desta temos nesta nova versão do kernel...
- Lockless page cache:
A "page cache" é o local onde o kernel deixa em memória uma cópia de um arquivo em disco, para evitar I/O.
Existia um lock para evitar problemas em sistemas com múltiplos CPUs, logo quando diferentes CPUs tentavam acessar arquivos diferentes não tínhamos problemas, porém quando dois CPUs tentavam acessar um mesmo arquivo (uma shared library do sistema por exemplo), somente um poderia ler a cada vez. Agora, graças a algumas novas regras que definem como a "page cache" é utilizada e pela utilização de RCU, será possível ler a "page cache" sem ser necessário fazer o lock.
Porém esta melhora só será observada em sistemas com muitas CPUs.
Links relacionados:
LWN: Toward better direct I/O scalability (http://lwn.net/Articles/275808/)
LWN: The lockless page cache (http://lwn.net/Articles/291826/)
WIKI: RCU (http://en.wikipedia.org/wiki/Read-copy-update)
- Lockless get_user_pages():
A função get_user_pages() é utilizada em operações de I/O diretas para travar o espaço de memória que será transferido.
Entretanto é uma função complexa e que utilizada semáforos e locks, que causavam problemas de escalabilidade quando se tinha diversos processos utilizando está função em uma mesma área de memória.
No kernel 2.6.27 uma nova função get_user_pages_fast() foi introduzida, a qual faz a mesma operação que a get_user_pages() porem determinadas operações foram simplificadas de modo que não é necessário obter o semáforo nem o lock. Alguns testes registraram uma melhora de 10% em um sistema quad-core com um banco de dados IBM DB2 com um workload OLTP.
Links relacionados:
WIKI: OLPT (http://en.wikipedia.org/wiki/Online_transaction_processing)
- Ext4: Delayed Allocation:
Neste versão foi adicionado ao sistema de arquivos ext4, um dos mais importantes recursos planejados a "Delayed Allocation" (alocação tardia, conhecida também como Allocate-on-flush).
Este recurso não altera a estrutura do disco, mas melhora a velocidade em diversas situações.
Uma breve explicação de como funciona: Quando uma aplicação quer escrever algo em disco, os dados não são escritos imediatamente, mas são colocados em uma área de memória RAM por algum tempo. Mas independente de ser escrita ou não imediatamente, o sistema de arquivos aloca as estruturas necessárias em disco na hora. A alocação tardia consiste em não alocar estas estruturas para os dados que estão cacheados na RAM, ela apenas atualiza a estrutura que indica quanto espaço livre em disco ainda temos, quando é feita uma operação de escrita. Os blocos e estruturas no disco são somente alocados quando os dados são realmente escritos.
Esta técnica é utilizada por outros sistemas de arquivos como o XFS, Btrfs, ZFS e o Reiser4 e apresenta um notável ganho de velocidade e também resulta em decisões melhores para a alocação dos blocos, pois neste momento o sistema de arquivos ja conhece tudo que deverá escrever.
Links relacionados:
WIKI: EXT4 (http://en.wikipedia.org/wiki/Ext4)
WIKI: Allocate-on-flush (http://en.wikipedia.org/wiki/Allocate-on-flush)
WIKI: Sistema de Arquivos (http://en.wikipedia.org/wiki/Filesystem)
WIKI: XFS (http://en.wikipedia.org/wiki/XFS)
WIKI: Btrfs (http://en.wikipedia.org/wiki/Btrfs)
WIKI: ZFS (http://en.wikipedia.org/wiki/ZFS)
WIKI: Reiser4 (http://en.wikipedia.org/wiki/Reiser4)
- Kexec jump: kexec/kdump based hibernation:
O Kexec é um recurso do Linux que permite que carregar um kernel na memória e executa-lo, ou seja permitindo que se "reinicie em um novo kernel", sem reiniciar o PC.
Assim era implementado o Kdump, um sistema de dump para quando o kernel travava: Um kernel estável/seguro (que se tinha certeza que iria funcionar) era carregado na memória assim que o sistema iniciasse e caso acontecesse do kernel principal do sistema travar o "oops code" executava o Kexec, que passava para o kernel estável/seguro, que então fazia um dump da memória.
Esta implementação foi melhorada no kernel 2.6.27 agora podendo ser usada para fazer a hibernação do sistema, ou seja, o sistema iria chamar o Kexec para executar um segundo kernel que faria o dump da memória em disco e depois desligaria o computador. Quando a máquina fosse religada, o initrd poderia carregar os dados e restaura-los.
Esta implementação de hibernação não substitui as outras, apenas é mais uma alternativa que tem algumas vantagens como não depender da ACPI. Porém por enquanto só funciona em sistemas X86-32.
Links relacionados:
LWN: Yet another approach to software suspend (http://lwn.net/Articles/242107/)
WIKI: Kexec (http://en.wikipedia.org/wiki/Kexec)
WEB: Kdump (http://lse.sourceforge.net/kdump/)
WIKI: Hibernação (http://en.wikipedia.org/wiki/Hibernate_(OS_feature))
WIKI: ACPI (http://en.wikipedia.org/wiki/ACPI)
WIKI: X86-32 (http://en.wikipedia.org/wiki/X86-32)
WIKI: initrd (http://en.wikipedia.org/wiki/Initrd)
- UBIFS:
UBIFS é um novo sistema de arquivos para dispositivos flash, desenvolvido pela Nokia com a Universidade de Szeged.
O UBIFS é bem diferente dos outros sistemas de arquivos tradicionais, ele não trabalha com dispositivos baseados em blocos, mas somente em dispositivos flashs "puros", manipulados pelo subsistema MTD no Linux.
Logo o UBIFS não funciona com o que muitas pessoas consideram dispositivos flashs como HDs flash, cartões SD, pen-drives/USB-sticks, etc, por causa que estes dispositivos utilizam uma camada de emulação para dispositivos de blocos, chamada FTL (Flash Translation Layer) que fazem com que estes dispositivos pareçam ser organizados através de blocos como.
O UBIFS foi feito para os dispositivos que não utilizam o FTL e que são manipulados pelo subsistema MTD e apresentam-se para o userspace como dispositivos MTD.
O UBIFS opera em cima de volumes UBI (Unsorted Block Images). (O UBI é uma camada como o LVM, que entrou no kernel na versão 2.6.22, que este sim opera em cima de dispositivos MTD). O UBIFS oferece diversas vantagens sobre o JFFS2: tempos de montagem mais rápidos e escalonáveis, tolerância a hard-reboots (conhecidos como dedoffs) pois é um sistema com journaling, suporte a write-back e a compressão "on-the-fly".
Links relacionados:
LWN: UBIFS (http://lwn.net/Articles/276025/)
WIKI: MTD (http://en.wikipedia.org/wiki/Memory_Technology_Device)
WIKI: FTL (http://en.wikipedia.org/wiki/Flash_Translation_Layer#Flash_file_systems)
WIKI: Userspace (http://en.wikipedia.org/wiki/Userspace)
WIKI: JFFS2 (http://en.wikipedia.org/wiki/JFFS2)
WIKI: Journaling (http://en.wikipedia.org/wiki/Journaling_file_system)
WEB: UBIFS FAQ (http://www.linux-mtd.infradead.org/faq/ubifs.html)
WEB: UBIFS DOCs (http://www.linux-mtd.infradead.org/doc/ubifs.html)
- OMFS:
OMFS significa "Sonicblue Optimized MPEG File System support" e é um sistema de arquivos proprietário utilizado pelo player de música Rio Karma e o ReplayTV DVR. Desconsiderando o nome, este sistema de arquivos não é mais eficiente que um sistema de arquivos padrão quando se trata de arquivos MPEG.
Links relacionados:
LWN: OMFS (http://lwn.net/Articles/278028/)
- Block layer data integrity support
Sistemas de arquivos modernos contam com o recurso de checksum de dados e meta-dados para proteger-se contra dados corrompidos. Porém a checagem é feita em tempo de leitura, que pode acontecer meses depois dos dados terem sido escritos e neste ponto os dados que a aplicação tentou escrever, provavelmente ja estão perdidos. A solução é verificar que o que esta sendo gravado em disco é o que realmente espera-se.
Recentes adições aos protocolos da família SCSI (SBC Data Integrity Field, SCC protection proposal) e ao SATA/T13 (External Path Protection) tentam melhorar esta situação adicionando suporte a adição de meta-dados de integridade em um I/O. Estes meta-dados de integridade contém um checksum de cada setor e um contador incremental que garante que os dados serão escritos na ordem certa.
Links relacionados:
LWN: Block layer: integrity checking and lots of partitions (http://lwn.net/Articles/290141/)
WIKI: Checksum (http://en.wikipedia.org/wiki/Checksum)
WIKI: SCSI (http://en.wikipedia.org/wiki/SCSI)
WIKI: SATA (http://en.wikipedia.org/wiki/SATA)
- Multiqueue networking:
Uma das principais estruturas de dados do subsistema de redes é a fila associada a cada dispositivo para a transmissão de dados.
Este métodos funcionou muito bem por anos, porém vem encontrando uma barreira ultimamente: Não funciona bem para dispositivos com múltiplas filas.
E dispositivos assim estão se tornando mais comuns, principalmente na área de redes sem fio, como por exemplo os dispositivos que implementam o Wireless Multimedia Extensions que podem ter 4 "classes de serviços", onde alguns serviços podem ter mais prioridades que outros.
O kernel 2.6.27 agora tem suporte a estes dispositivos.
Links relacionados:
LWN : Multiqueue networking (http://lwn.net/Articles/289137/)
WIKI: Wireless Multimedia Extensions (http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions)
- ftrace:
O ftracer é um simples tracer de funções que nasceu na árvore -rt (Real Time) de desenvolvimento.
Ele utiliza um recurso do compilador para inserir uma pequena instrução NOP de 5 bytes no início de cada função do kernel. Então estas instruções NOP são modificadas em tempo de execução em uma chamada ao tracer quando a opção de tracing está habilitada pelo administrador do sistema, caso esta não esteja o overhead encontrado é muito pequeno e desprezível até em micro-benchmarks.
Apesar do ftrace trabalhar com funções ele inclui um sistema de plugins que permite outros tipos de tracing.
Links relacionados:
WIKI: Real Time (http://en.wikipedia.org/wiki/Real-time_operating_system)
WIKI: NOP (http://en.wikipedia.org/wiki/NOP)
WIKI: Overhead (http://en.wikipedia.org/wiki/Computational_overhead)
WIKI: Benchmark (http://en.wikipedia.org/wiki/Benchmark_(computing))
- Mmiotrace:
Mmiotrace é uma ferramenta para capturar acessos MMIO (Memory Mapped IO) no kernel Como o MMIO é utilizado por drivers, esta ferramenta pode ser utilizada para debugging e engenharia reversa de drivers binários.
Links relacionados:
LWN: Tracing memory-mapped I/O operations (http://lwn.net/Articles/270939/)
WIKI: MMIO (http://en.wikipedia.org/wiki/IO_port)
- External firmware:
O Firmware normalmente é compilado junto com o drivers, porém por algumas questões legais (de licenciamento na maioria), a distribuição de alguns firmwares não é permitido por algumas empresas e alguns drivers tem suportado que um firmware externo seja carregado.
Porém mesmo que um firmware, que possa ser legalmente redistribuído, mas não atende as diretivas do "software livre", então algumas pessoas acham que isto quebra a GPL.
No kernel 2.6.27 os firmwares foram movidos de dentro dos códigos do drivers para um novo diretório "firmware/". Por padrão, o firmware não será compilado dentro do kernel (built-in) ou nos módulos, mas serão instalados em /lib/firmware quando o usuário fizer o "make module_install". Os drivers foram modificados também para chamar a função request_firmware() e carregar o firmware que eles necessitarão.
Entretanto ainda há uma opção na configuração do kernel para que os firmwares sejam compilados dentro dos drivers.
Links relacionados:
LWN: Moving the firmware out (http://lwn.net/Articles/284932/)
WIKI: Firmware (http://en.wikipedia.org/wiki/Firmware)
- Improved video camera support with the gspca driver:
A inclusão do driver gspca no kernel 2.6.27 provê suporte a mais uma grande lista de câmeras de vídeo, que pode ser conferida aqui:
http://lwn.net/Articles/291036/
Agora, a maioria das câmeras de vídeo disponíveis no mercado são suportadas no Linux.
- Extended file descriptor system calls:
Quando o Unix foi criado, muitas das interfaces não previam funcionalidades que seriam necessárias no futuro, como por exemplo a criação de um descritor de arquivo que tivesse uma flag como parâmetro. Esta limitação tornava impossível a criação de descritores de arquivo com novas propriedades como "close-on-exec", "non-blocking" e "non-sequential". Tornar isso possível hoje é essencial, inclusive para efeitos de segurança.
O Linux 2.6.27 adicionou um novo set de interfaces e syscalls que serão usadas pela glibc.
Links relacionados:
LWN: Extending system calls (http://lwn.net/Articles/281965/)
WIKI: Descritor de arquivo (http://en.wikipedia.org/wiki/File_descriptor)
WIKI: Syscall (http://en.wikipedia.org/wiki/Syscall)
WIKI: Glibc (http://en.wikipedia.org/wiki/Glibc)
- Voltage and Current Regulator:
Este framework foi criado para implementar uma interface genérica com reguladores de voltagem e corrente. A intenção é permitir que os sistemas ajustem dinamicamente a saída do regulador com o objetivo de economizar bateria e gastar menos energia.
Outras novidades:
X86:
- Adicionado suporte ao AMD IOMMU (AMD I/O Virtualization Technology).
- Suporte a 4096 CPUs.
Xen:
- Permite que o Xen seja executado em 64-bits.
- O Xen agora permite que máquinas virtuais sejam salvas e restauradas.
PowerPC:
- Removida a arquitetura PPC (arch/ppc), agora a POWERPC (arch/powerpc) suporta as duas.
- Kdbg com suporte a PowerPC
Rede:
- Novos drivers ath9k que suportam os chipsets das famílias AR5008 e AR9001 da Atheros.
Segurança:
- O módulo de segurança "dummy" foi removido. Agora o padrão é o módulo "capabilities".
- Suporte aos seguintes algoritmos de hash: RIPEMD-128, RIPEMD-160, RIPEMD-256, RIPEMD-320.
Outros:
- Suporte ao Palm TX.
- Remoção da arquitetura v850.
E como sempre *muitos* novos drivers, aumentando ainda mais a gama de dispositivos suportados!
Fontes de informação/pesquisa:
http://lwn.net/Articles/289510/
http://lwn.net/Articles/290428/
http://lwn.net/Articles/291461/
http://kernelnewbies.org/Linux_2_6_27
Mesmo o bug das placas de rede e1000e não tendo sido corrigido, o kernel conta com uma série de fixes que impedem que seja causado algum dano ao hardware.
Anyway, vamos dar uma olhada no que
- Lockless page cache:
A "page cache" é o local onde o kernel deixa em memória uma cópia de um arquivo em disco, para evitar I/O.
Existia um lock para evitar problemas em sistemas com múltiplos CPUs, logo quando diferentes CPUs tentavam acessar arquivos diferentes não tínhamos problemas, porém quando dois CPUs tentavam acessar um mesmo arquivo (uma shared library do sistema por exemplo), somente um poderia ler a cada vez. Agora, graças a algumas novas regras que definem como a "page cache" é utilizada e pela utilização de RCU, será possível ler a "page cache" sem ser necessário fazer o lock.
Porém esta melhora só será observada em sistemas com muitas CPUs.
Links relacionados:
LWN: Toward better direct I/O scalability (http://lwn.net/Articles/275808/)
LWN: The lockless page cache (http://lwn.net/Articles/291826/)
WIKI: RCU (http://en.wikipedia.org/wiki/Read-copy-update)
- Lockless get_user_pages():
A função get_user_pages() é utilizada em operações de I/O diretas para travar o espaço de memória que será transferido.
Entretanto é uma função complexa e que utilizada semáforos e locks, que causavam problemas de escalabilidade quando se tinha diversos processos utilizando está função em uma mesma área de memória.
No kernel 2.6.27 uma nova função get_user_pages_fast() foi introduzida, a qual faz a mesma operação que a get_user_pages() porem determinadas operações foram simplificadas de modo que não é necessário obter o semáforo nem o lock. Alguns testes registraram uma melhora de 10% em um sistema quad-core com um banco de dados IBM DB2 com um workload OLTP.
Links relacionados:
WIKI: OLPT (http://en.wikipedia.org/wiki/Online_transaction_processing)
- Ext4: Delayed Allocation:
Neste versão foi adicionado ao sistema de arquivos ext4, um dos mais importantes recursos planejados a "Delayed Allocation" (alocação tardia, conhecida também como Allocate-on-flush).
Este recurso não altera a estrutura do disco, mas melhora a velocidade em diversas situações.
Uma breve explicação de como funciona: Quando uma aplicação quer escrever algo em disco, os dados não são escritos imediatamente, mas são colocados em uma área de memória RAM por algum tempo. Mas independente de ser escrita ou não imediatamente, o sistema de arquivos aloca as estruturas necessárias em disco na hora. A alocação tardia consiste em não alocar estas estruturas para os dados que estão cacheados na RAM, ela apenas atualiza a estrutura que indica quanto espaço livre em disco ainda temos, quando é feita uma operação de escrita. Os blocos e estruturas no disco são somente alocados quando os dados são realmente escritos.
Esta técnica é utilizada por outros sistemas de arquivos como o XFS, Btrfs, ZFS e o Reiser4 e apresenta um notável ganho de velocidade e também resulta em decisões melhores para a alocação dos blocos, pois neste momento o sistema de arquivos ja conhece tudo que deverá escrever.
Links relacionados:
WIKI: EXT4 (http://en.wikipedia.org/wiki/Ext4)
WIKI: Allocate-on-flush (http://en.wikipedia.org/wiki/Allocate-on-flush)
WIKI: Sistema de Arquivos (http://en.wikipedia.org/wiki/Filesystem)
WIKI: XFS (http://en.wikipedia.org/wiki/XFS)
WIKI: Btrfs (http://en.wikipedia.org/wiki/Btrfs)
WIKI: ZFS (http://en.wikipedia.org/wiki/ZFS)
WIKI: Reiser4 (http://en.wikipedia.org/wiki/Reiser4)
- Kexec jump: kexec/kdump based hibernation:
O Kexec é um recurso do Linux que permite que carregar um kernel na memória e executa-lo, ou seja permitindo que se "reinicie em um novo kernel", sem reiniciar o PC.
Assim era implementado o Kdump, um sistema de dump para quando o kernel travava: Um kernel estável/seguro (que se tinha certeza que iria funcionar) era carregado na memória assim que o sistema iniciasse e caso acontecesse do kernel principal do sistema travar o "oops code" executava o Kexec, que passava para o kernel estável/seguro, que então fazia um dump da memória.
Esta implementação foi melhorada no kernel 2.6.27 agora podendo ser usada para fazer a hibernação do sistema, ou seja, o sistema iria chamar o Kexec para executar um segundo kernel que faria o dump da memória em disco e depois desligaria o computador. Quando a máquina fosse religada, o initrd poderia carregar os dados e restaura-los.
Esta implementação de hibernação não substitui as outras, apenas é mais uma alternativa que tem algumas vantagens como não depender da ACPI. Porém por enquanto só funciona em sistemas X86-32.
Links relacionados:
LWN: Yet another approach to software suspend (http://lwn.net/Articles/242107/)
WIKI: Kexec (http://en.wikipedia.org/wiki/Kexec)
WEB: Kdump (http://lse.sourceforge.net/kdump/)
WIKI: Hibernação (http://en.wikipedia.org/wiki/Hibernate_(OS_feature))
WIKI: ACPI (http://en.wikipedia.org/wiki/ACPI)
WIKI: X86-32 (http://en.wikipedia.org/wiki/X86-32)
WIKI: initrd (http://en.wikipedia.org/wiki/Initrd)
- UBIFS:
UBIFS é um novo sistema de arquivos para dispositivos flash, desenvolvido pela Nokia com a Universidade de Szeged.
O UBIFS é bem diferente dos outros sistemas de arquivos tradicionais, ele não trabalha com dispositivos baseados em blocos, mas somente em dispositivos flashs "puros", manipulados pelo subsistema MTD no Linux.
Logo o UBIFS não funciona com o que muitas pessoas consideram dispositivos flashs como HDs flash, cartões SD, pen-drives/USB-sticks, etc, por causa que estes dispositivos utilizam uma camada de emulação para dispositivos de blocos, chamada FTL (Flash Translation Layer) que fazem com que estes dispositivos pareçam ser organizados através de blocos como.
O UBIFS foi feito para os dispositivos que não utilizam o FTL e que são manipulados pelo subsistema MTD e apresentam-se para o userspace como dispositivos MTD.
O UBIFS opera em cima de volumes UBI (Unsorted Block Images). (O UBI é uma camada como o LVM, que entrou no kernel na versão 2.6.22, que este sim opera em cima de dispositivos MTD). O UBIFS oferece diversas vantagens sobre o JFFS2: tempos de montagem mais rápidos e escalonáveis, tolerância a hard-reboots (conhecidos como dedoffs) pois é um sistema com journaling, suporte a write-back e a compressão "on-the-fly".
Links relacionados:
LWN: UBIFS (http://lwn.net/Articles/276025/)
WIKI: MTD (http://en.wikipedia.org/wiki/Memory_Technology_Device)
WIKI: FTL (http://en.wikipedia.org/wiki/Flash_Translation_Layer#Flash_file_systems)
WIKI: Userspace (http://en.wikipedia.org/wiki/Userspace)
WIKI: JFFS2 (http://en.wikipedia.org/wiki/JFFS2)
WIKI: Journaling (http://en.wikipedia.org/wiki/Journaling_file_system)
WEB: UBIFS FAQ (http://www.linux-mtd.infradead.org/faq/ubifs.html)
WEB: UBIFS DOCs (http://www.linux-mtd.infradead.org/doc/ubifs.html)
- OMFS:
OMFS significa "Sonicblue Optimized MPEG File System support" e é um sistema de arquivos proprietário utilizado pelo player de música Rio Karma e o ReplayTV DVR. Desconsiderando o nome, este sistema de arquivos não é mais eficiente que um sistema de arquivos padrão quando se trata de arquivos MPEG.
Links relacionados:
LWN: OMFS (http://lwn.net/Articles/278028/)
- Block layer data integrity support
Sistemas de arquivos modernos contam com o recurso de checksum de dados e meta-dados para proteger-se contra dados corrompidos. Porém a checagem é feita em tempo de leitura, que pode acontecer meses depois dos dados terem sido escritos e neste ponto os dados que a aplicação tentou escrever, provavelmente ja estão perdidos. A solução é verificar que o que esta sendo gravado em disco é o que realmente espera-se.
Recentes adições aos protocolos da família SCSI (SBC Data Integrity Field, SCC protection proposal) e ao SATA/T13 (External Path Protection) tentam melhorar esta situação adicionando suporte a adição de meta-dados de integridade em um I/O. Estes meta-dados de integridade contém um checksum de cada setor e um contador incremental que garante que os dados serão escritos na ordem certa.
Links relacionados:
LWN: Block layer: integrity checking and lots of partitions (http://lwn.net/Articles/290141/)
WIKI: Checksum (http://en.wikipedia.org/wiki/Checksum)
WIKI: SCSI (http://en.wikipedia.org/wiki/SCSI)
WIKI: SATA (http://en.wikipedia.org/wiki/SATA)
- Multiqueue networking:
Uma das principais estruturas de dados do subsistema de redes é a fila associada a cada dispositivo para a transmissão de dados.
Este métodos funcionou muito bem por anos, porém vem encontrando uma barreira ultimamente: Não funciona bem para dispositivos com múltiplas filas.
E dispositivos assim estão se tornando mais comuns, principalmente na área de redes sem fio, como por exemplo os dispositivos que implementam o Wireless Multimedia Extensions que podem ter 4 "classes de serviços", onde alguns serviços podem ter mais prioridades que outros.
O kernel 2.6.27 agora tem suporte a estes dispositivos.
Links relacionados:
LWN : Multiqueue networking (http://lwn.net/Articles/289137/)
WIKI: Wireless Multimedia Extensions (http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions)
- ftrace:
O ftracer é um simples tracer de funções que nasceu na árvore -rt (Real Time) de desenvolvimento.
Ele utiliza um recurso do compilador para inserir uma pequena instrução NOP de 5 bytes no início de cada função do kernel. Então estas instruções NOP são modificadas em tempo de execução em uma chamada ao tracer quando a opção de tracing está habilitada pelo administrador do sistema, caso esta não esteja o overhead encontrado é muito pequeno e desprezível até em micro-benchmarks.
Apesar do ftrace trabalhar com funções ele inclui um sistema de plugins que permite outros tipos de tracing.
Links relacionados:
WIKI: Real Time (http://en.wikipedia.org/wiki/Real-time_operating_system)
WIKI: NOP (http://en.wikipedia.org/wiki/NOP)
WIKI: Overhead (http://en.wikipedia.org/wiki/Computational_overhead)
WIKI: Benchmark (http://en.wikipedia.org/wiki/Benchmark_(computing))
- Mmiotrace:
Mmiotrace é uma ferramenta para capturar acessos MMIO (Memory Mapped IO) no kernel Como o MMIO é utilizado por drivers, esta ferramenta pode ser utilizada para debugging e engenharia reversa de drivers binários.
Links relacionados:
LWN: Tracing memory-mapped I/O operations (http://lwn.net/Articles/270939/)
WIKI: MMIO (http://en.wikipedia.org/wiki/IO_port)
- External firmware:
O Firmware normalmente é compilado junto com o drivers, porém por algumas questões legais (de licenciamento na maioria), a distribuição de alguns firmwares não é permitido por algumas empresas e alguns drivers tem suportado que um firmware externo seja carregado.
Porém mesmo que um firmware, que possa ser legalmente redistribuído, mas não atende as diretivas do "software livre", então algumas pessoas acham que isto quebra a GPL.
No kernel 2.6.27 os firmwares foram movidos de dentro dos códigos do drivers para um novo diretório "firmware/". Por padrão, o firmware não será compilado dentro do kernel (built-in) ou nos módulos, mas serão instalados em /lib/firmware quando o usuário fizer o "make module_install". Os drivers foram modificados também para chamar a função request_firmware() e carregar o firmware que eles necessitarão.
Entretanto ainda há uma opção na configuração do kernel para que os firmwares sejam compilados dentro dos drivers.
Links relacionados:
LWN: Moving the firmware out (http://lwn.net/Articles/284932/)
WIKI: Firmware (http://en.wikipedia.org/wiki/Firmware)
- Improved video camera support with the gspca driver:
A inclusão do driver gspca no kernel 2.6.27 provê suporte a mais uma grande lista de câmeras de vídeo, que pode ser conferida aqui:
http://lwn.net/Articles/291036/
Agora, a maioria das câmeras de vídeo disponíveis no mercado são suportadas no Linux.
- Extended file descriptor system calls:
Quando o Unix foi criado, muitas das interfaces não previam funcionalidades que seriam necessárias no futuro, como por exemplo a criação de um descritor de arquivo que tivesse uma flag como parâmetro. Esta limitação tornava impossível a criação de descritores de arquivo com novas propriedades como "close-on-exec", "non-blocking" e "non-sequential". Tornar isso possível hoje é essencial, inclusive para efeitos de segurança.
O Linux 2.6.27 adicionou um novo set de interfaces e syscalls que serão usadas pela glibc.
Links relacionados:
LWN: Extending system calls (http://lwn.net/Articles/281965/)
WIKI: Descritor de arquivo (http://en.wikipedia.org/wiki/File_descriptor)
WIKI: Syscall (http://en.wikipedia.org/wiki/Syscall)
WIKI: Glibc (http://en.wikipedia.org/wiki/Glibc)
- Voltage and Current Regulator:
Este framework foi criado para implementar uma interface genérica com reguladores de voltagem e corrente. A intenção é permitir que os sistemas ajustem dinamicamente a saída do regulador com o objetivo de economizar bateria e gastar menos energia.
Outras novidades:
X86:
- Adicionado suporte ao AMD IOMMU (AMD I/O Virtualization Technology).
- Suporte a 4096 CPUs.
Xen:
- Permite que o Xen seja executado em 64-bits.
- O Xen agora permite que máquinas virtuais sejam salvas e restauradas.
PowerPC:
- Removida a arquitetura PPC (arch/ppc), agora a POWERPC (arch/powerpc) suporta as duas.
- Kdbg com suporte a PowerPC
Rede:
- Novos drivers ath9k que suportam os chipsets das famílias AR5008 e AR9001 da Atheros.
Segurança:
- O módulo de segurança "dummy" foi removido. Agora o padrão é o módulo "capabilities".
- Suporte aos seguintes algoritmos de hash: RIPEMD-128, RIPEMD-160, RIPEMD-256, RIPEMD-320.
Outros:
- Suporte ao Palm TX.
- Remoção da arquitetura v850.
E como sempre *muitos* novos drivers, aumentando ainda mais a gama de dispositivos suportados!
Fontes de informação/pesquisa:
http://lwn.net/Articles/289510/
http://lwn.net/Articles/290428/
http://lwn.net/Articles/291461/
http://kernelnewbies.org/Linux_2_6_27
Assinar:
Postagens (Atom)
