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:

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:

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.

sábado, 27 de dezembro de 2008

Promoção de natal/ano novo no Steam...

... e la se foi meu limite do CC :P

Sério... essas promoções me deixam pobre =/

*TUDO* esta com um desconto de 10% a 75%.

O que eu ja comprei até agora:
FlatOut 1, 2 e Ultimate Carnage == 18 dólares.
Dawn of War Complete Pack = 30 dólares(custa 70 normalmente... =X)
UT3 = 10 dólares\o/
Mass Effect = 27 dólares
Portal = 5 dólares

Total: 90 dólares aproximadamente =X


E ainda tem outros 3 que estou pensando em comprar:

Stalker Clear Sky a 18 dólares, desconto de 50% em relação ao preço normal!
Quake Wars = 15 dólares.
Frontlines = 23 dólares.
World in Conflict = 23 dólares.


Eu até pensei no Crysis Pack (54 dólares) e no Far Cry 2 (38 dólares)... mas calma... estes estão mais caros (e nem valem *tanto* a pena assim comparados com os preços aqui no Brasil) e provavelmente não terei tempo para jogar tanta coisa assim :P


Para quem quiser o Team Fortress 2 e/ou o CS:Source, ótima hora, os dois estão apenas 10 dólares! =]

Para mais informações e destaque, visitem o site do Steam aqui:
http://store.steampowered.com/holidaysale
(Não, não estou ganhando nada por isso :P)

Hacking Exposed: Computer Forensics

Yep... consegui terminar de ler mais um livro antes de acabar o ano :P



Este não será uma resenha nem um resumo muito longo... porque estou meio que desapontado com o livro.


Ok, o livro foi publicado no final de Nov de 2004. Acho que livros de segurança, hoje, estão ficando desatualizados muito rapidamente. Mas não foi isso que me incomodou, pois seria o mesmo caso do livro de Buffer Overflow, que apesar de não ser nenhum espetáculo, acabei aprendendo umas coisas bem legais.


O site do livro, por exemplo, nem existe mais. Acho isso um vacilo muito grande por parte da editora e dos autores.



Os 3 primeiros capítulos formas a parte 1 - e introdutória - do livro.


O primeiro capítulo, diz o que é uma análise forense, os passos normalmente tomados, tudo que tem de ser feito, desde o registro (para documentação posterior), coleta das evidências e finalmente a análise... bem básico.


O segundo capítulo explica coisas básicas como o que é a BIOS, tipos de mídia: hds, cds, disquete, fitas, etc... Até tem umas coisinhas interessantes... mas nada que realmente seja ligado a segurança, está mais para "conhecimentos gerais".


Capítulo 3 discute o que deve ser e como de ver um laboratório de investigação forense. Até aqui está bem interessante... mas bem básico. Ele fala sobre toda a segurança que você precisa ter, para não deixar pessoas não autorizadas entrarem por exemplo.



Agora começamos a parte 2.

O capítulo 4, trata da coleta da evidência.
O capítulo 5, fala sobre investigação remota.


Fala sobre como devem ser feitos, explicam algumas coisas... falam que deve ser feito o hash dos arquivos coletados, blablabla...
No mais, demonstra como fazer tudo utilizando ferramentas, tipo EnCase e algumas outras. (Quase sempre comerciais)



Parte 3:

Capítulo 6: Forense em ambiente Windows
Capítulo 7: Forense em ambiente Linux
Capítulo 8: Forense em ambiente MacOS


A parte mais interessante dos 3 capítulos é quando são discutidos os sistemas de arquivos mais utilizados nos 3 SOs.
Tirando isso, é somente mais uma longa sequencia de "como fazer isso usando a ferramenta XXX"... e normalmente a ferramenta é a EnCase.



Capítulo 9: Técnicas anti-forenses.
Aqui pode ser interessante para os investigadores terem uma noção de problemas que podem ter... como criptografia, estenografia, limpeza de disco (gravando bytes aleatórios diversas vezes por todo o disco)...



Capítulo 10: Análise em Storage em empresas.
Basicamente fala sobre RAID e fitas.



Capítulo 11: Análise de e-mail:
Fala sobre como abrir arquivos .pst (outlook), .dbx (outlook express), formato padrão de mailbox do unix, Netscape/Mozilla e AOL (WTF?!), Hotmail e Yahoo!.
No final, 2 páginas sobre cabeçalhos de e-mail... muito básico.



Capítulo 12: Rastreando as atividades dos usuários.
Fala sobre cookies e o cache dos browsers. E sobre meta-dados em documentos office.


[Aqui eu ja estava de saco cheio e comecei a ler as coisas com leitura dinâmica... ou seja... 4 pagina no tempo de 1]



Capítulo 13: Análise de PDAs e Celulares.
Esse é o capítulo "ultra novidade" deste livro... e a idéia é boa! Quem hoje não tem um celular que lava, passa e cozinha? (Só não liga quando é preciso :P).


Mas novamente é somente um "how-to" de ferramentas... PDA/Cell Seizure da Paraben e da EnCase. Desculpem... mas fiquei completamente de saco cheio.



A última parte, tenta mostrar tipos de relatórios (internos, para a justiça, etc...) e depois como o sistema de justiça dos EUA funciona. Interessante... pelo menos eles não falaram mais da EnCase aqui.



Depois temos os apêndices:

Apêndice A: Alguns formulários e checklists, para serem usados ou servirem como base para criação de outros.

Apêndice B: Consequências legais. Basicamente descreve um caso que foi a justiça.

Apêndice C: Fala sobre as leis (dos EUA) sobre o tratamento de evidências.

Apêndice D: RegExp básico em 4 páginas.

Apêndice E: Ferramentas que deverias estar no toolkit de um investigados. Diversas ferramentas... algumas livres, outras comerciais...



E pronto, é isso.

Se alguém ainda não entendeu minha frustração com o livro eu posso resumir em 1 linha:

O livro poderia se chamar "EnCase for Dummies" ;)


Infelizmente o modo do livro ser escrito, que em 90% é apenas "fazendo isso com *essa* ferramenta" me desmotivou muito a ler.

Apenas segui em frente pois queria acabar ele de uma vez.


Não recomendo o livro mesmo...

quinta-feira, 25 de dezembro de 2008

Lembrem: SEMPRE salvem seus jogos!

E não confiem no AutoSave -_-'

Ja é a segunda vez que acontece...

A 1 mês atrás foi com o Fallout 3.
Estava lá eu, n00b, jogando feliz meu Fallout 3 novo... bem no início em Megaton, quando sem querer eu aperto 'E' numa parada na Church of Atom que seria considerado crime.

Puta que pariu! Veio a cidade inteira atras de mim, até a porra da velha que não fazia porra nenhuma queria me dar umas paneladas! -_-'

Eu poderia tentar matar todo mundo (improvável)...
Mas pô... eu queria fazer as quests da cidade caramba.

Foi sem querer CARALHO! Não dava pra me dar uma multa? 50 flexões e 200 abdominais?
Holy shit...

Depois fui dar loadgame... e descobri que:
a) Meu savegame estava *beeem* velho.
b) O autosave, salvou depois que eu fiz a merda -_-'

WTF essa porra de autosave?!


Ok, passado o trauma do Fallout 3 e sempre salvando...

Nesta segunda comprei o Stalker (o primeiro... Shadow of Chernobyl) por 5 dolares no Steam! Whohoooooooooooo!
Vamos jogar...

Estou eu la n00bzão no jogo como sempre...

Ai depois de fazer uns 3 ou 4 jobs eu abro meu inventário e vejo la um daqueles bagulhos radioativos que você pode equipar e te da um boost na resistência a alguma coisa.

Po, ai o jogo me avisa que maneiro, aquilo gera uma radioatividade nociva pro seu corpo e vc tem que tomar um remedinho lá pra ficar tudo nos trinks... beleza... desequipo a parada e volto pro inventário, pq como em todo jogo que sou n00b leio a descrição de cada item até do "pão fresquinho" que achei num defunto.

Quando começa um beep-beep... ai... eu saio do inventário, vejo a porra da barrinha da vida com menos de 1 px cheio e ai morro e me vem um GAME OVER na cara -_-'

OMFG!!!!!!!!!! Puta que pariu!!!!

Tipo.... WTF MAN!?

Ok, ok... aceitei minha n00bice e fui dar load no save game.
Well... meu ultimo save game foi antes de completar esses 3 ou 4 jobs do jogo.

Ai caralho...
Ok, tinha um savegame la chamado "all" que é o que vai salvando pra você enquanto você ainda não tem um save específico do seu jogo.

Eu entendi que essa joça salvava sozinha... alem disso, volta e meia aparece um disquete piscando no canto inferior direito da tela. Se isso não for indicação de auto-save, é sacanagem!

Enfim... mefu de novo, la vou eu fazer os 4 jobs de novo... sorte que estou relativamente bem no início. E agora lembrando de salvar depois de cada passo, cada tiro disparado...
E sempre uns 10 saves diferentes... vai que eu me arrependo de algo que fiz né...

Feliz natal! Ho-ho-ho!

Eu tenho estado meio sumido... mas é apenas por preguiça de postar aqui mesmo :P

A 2 semanas atrás estava correndo para terminar os últimos trabalhos da faculdade (mesmo com o período letivo acadêmico ja tendo encerrado :P) e uma última prova no dia 18...


Depois fiz uma viagem a Arraial do Cabo, que simplesmente pode ser descrita como "fodapracaralho", com amigos que também são "fodapracaralho" =]
Afinal, sem eles não haveria tanta graça... assim como não teríamos coisas como competição de comer sopa (com handcap :P) e "hipertensão? créééééu!" :P

Vamos ver se dessa vez eu coloco as fotos aqui no blog :P


Voltando... ontem eu fiz um pouquinho de grind e upei pro lvl 21... não sei ainda onde vou distribuir minhas skill points. Tenho que pensar direito, porque do jeito que sou n00b nesse jogo, só vou upar de novo daqui a uns 365 dias =]


Tenho feito basicamente ficar lendo random coisas na internet e olhando o Bugzilla do Gentoo :P

Dei uma parada nos livros que eu estava lendo... fico basicamente jogando TF2/CS:S/Outro jogos aqui.
Falando em jogos... estou aqui sentado esperando a Valve começar a promoção de natal no Steam :P

E falando em livros... essa alta do dólar ta me fudendo aspira... é desanimador comprar livros a 2.40, depois de ter comprado a 1.60~1.70 =/


Vale notar que ontem saiu o Linux 2.6.28 (e dessa vez eu não vou fazer resumo - sry - quem quiser dar uma olhada, a página do KernelNewbies ta bem legal). Com isso a janela de merge foi aberta... o Ingo acordou cedo hoje e ja começou a mandar uns changesets gigantes por exemplo...

Saiu o GIT 1.6.1 também.
(Só to falando o que chega até minha inbox :P)


Bem, acho que é isso. Até o final do ano eu vou fazer um diff com relação ao post das coisas que eu queria ter feito este ano e vamos ver como eu me saí :P

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

Calendários do Advento Natalino

Perl-Mode-On ;)


Muito legal essa idéia e tem *muitas* dicas boas!

Aqui vai o e-mail original enviado pelo Breno para a lista RioPM:

"O calendário Perl do advento natalino é uma tradição na comunidade
desde o ano 2000. A idéia é apresentar um módulo bacana (para qualquer
definição de "bacana") do CPAN em cada dia de dezembro que antecede o
Natal.

O desse ano já está no ar!

http://perladvent.pm.org/2008/

O dia 1 fala do ToolSet, um módulo que agrega todos os seus módulos
mais usados em um único import, evitando assim o "ctrl-c/ctrl-v".

Dia 2 fala de um módulo que eu particularmente acho o maior barato, o
Math::Prime::TiedArray, que cria um array virtual com todos os números
primos.Todos?! Todos. Afinal, é um array virtual, ele computa o número
primo que ocupa a posição desejada conforme a demanda ;-)

Fiquem atentos ao site oficial do calendário! Quem tiver curiosidade é
só olhar o histórico para os outros anos, e se vc acha que seu [insira
módulo xodó aqui] está sendo injustiçado por não ter sido apresentado
até hoje, escreva para eles! O pessoal do calendário está sempre atrás
de idéias (e escritores!!!!!)

Finalmente, mas não menos importante, já saiu também o calendário
Catalyst do advento natalino, que desde 2005 complementa o calendário
do Perl com dicas e módulos específicos para o Catalyst!

http://www.catalystframework.org/calendar/2008/

O dia 1 apresenta as estatísticas da pesquisa de Catalyst (que
circulou inclusive pela lista, infelizmente apenas 2 brasileiros
responderam).

Dia 2 mostra as diferentes formas de se implantar o Catalyst em
servidores Web (servidor built-in, mod_perl, fastcgi, etc)

O dia 3 apresenta um módulo bonitão que já mencionei por aqui, o
Chart::Clicker, e como usá-lo junto com o Catalyst para exibir páginas
com gráficos informativos.

Como sempre, é possível ver calendários de anos anteriores, e eles
também adoram voluntários!


[]s, e boas festas ;-)

-b
"

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:
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.

domingo, 23 de novembro de 2008

Quotes

Sempre que eu reunir 10 quotes que eu achar interessantes, estarei postando por aqui... por enquanto, aqui estão os 10 primeiros:

"You know, you really are supposed to understand the code you are modifying..." - Al Viro

"Grr. I'd love to say "I told you so", and write another rant about -rc series patches. But I'm too lazy, so people - please mentally insert my standard rant here." - Linus Torvalds

"If you have a difficult task, give it to a lazy person; He will find an easier way to do it." - Hlade's Law

"Throughout your life, advance daily, becoming more skillful than yesterday, more skillful than today. This is never-ending." - Hagakure

"We are what we pretend to be, so we must be careful what we pretend to be." - Mother Night, Kurt Vonnegut, Jr.

"Nada me intriga tanto como o tempo e o espaço. E nada me preocupa menos do que o tempo e o espaço, porque nunca penso neles." - Charles Lamb

"Segundo o velho ditado, é melhor viajar com esperança do que chegar. Nossa busca de descobertas alimenta nossa criatividade em todos os campos, não apenas na ciência. Se chegássemos ao fim da linha, o espírito humano definharia e morreria. Mas não creio que um dia sossegaremos: aumentaremos em complexidade, se não em profundidade, e seremos sempre o centro de um horizonte de possibilidades em expansão." - Stephen Hawking

"Keep in mind that with careful study, calculated preparation and a possitive attitude... you'll probably still die."

"The universe doesn't care what you believe. The wonderful thing about science is that it doesn't ask for your faith, it just asks for your eyes." — xkcd.com

"The excitement of learning separates youth from the old age. As long as you're learning you're not old." - Rosalyn S. Yalow

sábado, 22 de novembro de 2008

Oops: Evento quase de graça.

No seguinte flyer do evento Encontro de TI (olha a propaganda de graça):




A seguinte informação chamou a atenção do pessoal que estava no LCI



WTF?

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?

WinHEC 2008 e novidades no Windows 7

Estava lendo coisas aleatórias na wikipedia, quando comecei a ler um artigo sobre as novidades do Windows 7, que deverá ser lançado no meio de 2009.

Realmente, hoje utilizo linux a maior parte do tempo em que faço algo útil... apenas indo para o Windows na hora de jogar (e não.. não fica bom no wine, ou no cedega ou no que for). Mas mesmo assim, eu adoro ler sobre os novos recursos dele.

Enfim... clica aqui, clica alí... fui parar no site do WinHEC 2008: Windows Hardware Engineering Conference.


E comecei a ver algumas apresentações e aqui estão algumas das que eu achei mais legais (não se preocupem... OpenOffice abre .pptx... meio capado, mas basta usar sua imaginação aonde ele não conseguir renderizar da forma correta):

The Manycore Shift: Microsoft Makes Parallel Computing Personal [WinHEC 2008; 3.9 MB]:
Fala sobre o suporte a programação paralela no Visual Studio 2010.


UEFI Momentum - the AMD Perspective [WinHEC 2008; 1.2 MB]:
Eu nem sabia que existia esse raio de UEFI.

Direct3D 11: New GPU Compute Shader [WinHEC 2008; 6.2 MB].

DirectX11: New Hardware and APIs [WinHEC 2008; 4.3 MB]:
As novidades do DirectX 11 ;)


Infelizmente, algumas apresentações eu não consegui abrir pois travaram o OpenOffice...
Making Technology and Products Matter for Developers [WinHEC 2008; 12.1 MB]
DirectX: Core Graphics for Windows 7 [WinHEC 2008; 6.8 MB]

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".

NFS Undercover... owned!

Dia 17 (ou 18 sei lá) tivemos o lançamento do novo jogo da série Need For Speed, NFS: Undercover... cheio de promessas e dizendo que iria revitalizar a série (que a um bom tempo anda bem +-)...

Hoje vi o review na ign, e o NFS Undercover ganhou um magnífico: 5! Isso mesmo... cinco! Suficiente para render uma classificação "Meh"... provavelmente de "uma merda".

Não se fazem mais NFSs como antigamente....


Bem, pelo menos será menos um jogo para sugar o meu tempo livre =]

Update 1: Por incrível que parece a Gamespot deu uma nota mais alta que a IGN... um razoável 7.0. Será que vale a pena testar?

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...

terça-feira, 4 de novembro de 2008

HAWX

Poooooooooooo!!!

Vi hoje no steam que o Tom Clancy's HAWX vai sair para PC tmb \o/

Eu não sou nenhum viciado em jogos de avião... mas esse parece que está *MUITO LEGAL*.


E... se passa no Brasil? O.o
Podem ver o Maracanã aqui (primeira screenshot na pagina do Steam):
http://cdn.steampowered.com/v/gfx/apps/900586/0000004447.1024x768.jpg?t=1225817403


Eu odeio o Steam... ele me faz ficar pobre :P

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... =]

sábado, 25 de outubro de 2008

True Blood

Vou falar da ultima série que comecei a assistir e está ainda no sétimo episodio de sua primeira temporada (mas domingo temos o 8 \o/).

Primeiro... se não fosse minha namorada eu nunca ia saber da existência dessa série :P


Então... a série basicamente é sobre vampiros... num mundo como o nosso, mas onde vampiros existem publicamente. Se são aceitos ou não... é controverso, alguns personagens são a favor, outros contra... tem até lei a favor dos vampiros a ser votada (x-man? lei a favor dos mutantes? alguem?).

Bem, uns japas criaram ai uma bebida (TruBlood, há!) que seria um sangue sintético, assim permitindo que os vampiros possam se alimentar disso ao invés de... sabe... pessoas. Mas é claro que coisas naturais são bem melhores ;)

Enfim, os personagens principais são:

Sookie Stackhouse: A protagonista da série. Ela tem uma habilidade muito peculiar, que a deixa muitas vezes desconfortável com outros humanos... e por isso ela tem uma quedinha por vampiros :P
Por causa desta habilidade muita gente acha que ela tem problemas. Ela vive com sua avó e seu irmão...

Jason Stackhouse: Irmão de Sookie, é o mais putão que eu ja vi. OMFG sério. Ele tem sérios problemas com vampiros, odeia todos eles. É o muleque irresponsável e que sempre faz merda =D

Tara Thornton: Amiga de infância de Sookie e Jason. IMHO, essa mulher ta com TPM 24x7 :P. Tem uma quedinha (mentira, é uma quedona mesmo) por Jason e fará de tudo para protege-lo. Tem também um sério problema com sua mãe, que é alcoólatra.

Sam Merlotte: Dono do bar onde Sookie e Tara trabalham. É um personagem muito misterioso... muito pouco é falado sobre sua história/passado. Tem uma queda (para não dizer desmoronamento) por Sookie.

Bill Compton: Esse é O CARA (ou melhor, O VAMPIRO). É o "vampiro do bem"... ou que tenta se integrar a sociedade, mesmo que alguns outros vampiros sejam contra isso e prefiram continuar do mesmo modo que sempre foi.
Ele é caralisticamente foda... e ainda da uns pegas na Sookie.

Lafayette Reynolds: Primo de Tara e trabalha na cozinha do bar de Sam. Ele é Gay ou Bi, não sei... mas é engraçado pra caraleo.


Bem, esses são os personagens principais apresentados até agora =]

A série no geral é bem legal... não posso dizer que seja perfeita que nem Lost, mas ja to querendo desesperadamente o oitavo episodio :P
No início eu achei ela meio +-, legal e tal, mas nada de demais... mas do 5o pro 7o, a coisa ficou TENSA!!!! =D

Uma coisa... eu não sei o que raios tem nessa cidade, mas que ta todo mundo no cio, 20% de cada episodio é sexo. Não que eu esteja reclamando... mas esse pessoal ta demais... da-lhe V-Juice...


E para terminar a intro da série (que eu achei muito boa), e a música tema é a Bad Things - Jace Everett:

quinta-feira, 23 de outubro de 2008

Alguns filmes...

Que vi neste mês:

Speed Racer:
Legal... sim, apenas isso. Nada de demais. Não me fez sentir *aquela* saudade de quando eu era menor. Ficou muito F-Zero-like... não que seja ruim... mas foi apenas isso.

Os personagens estão muito bem representados, com destaque para o Pops, emho =D

O Corredor X, poderia ter ficado *muuuuito* mais legal... =/


Mandando Bala:
É distribuição de balas (e cenouras) o filme inteiro e o "heroi" é melhor que o MacGayver... ou seja: ÓTIMO FILME!
Sério, muito bom mesmo =D


O Vidente:
O plot até que é legal... mas o mais maneiro mesmo é como o "poder" do protagonista é mostrado, ficou muito foda!!! =D
Destaque para quando ele faz uma BFS dentro do navio! :P


Super-herois, a Liga da Injustiça:
Fato: não tem história (novidade...). Mas é muito divertido por todas as sátiras aos outros filmes =]


Corrida Mortal:
POOOHA!!!!!!!!!! MUITO BOOOOOOOOOM!!!
Me amarrei nesse filme!!! =D
Quero achar um jogo de PC nesse estilo ASAP! :P

quarta-feira, 15 de outubro de 2008

O transito no rio...

... insuportável. Ou pelo menos na Zona Oeste...

2+ hrs para fazer Fundão -> Barra, algo que pode ser feito em 30 minutos com transito bom ou 1 hr no máximo em horário de engarrafamento (de manhã por exemplo).

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.

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 que podemos 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