Pessoal, Estive lendo as consideracoes sobre HTT e nao pude deixar de fazer algumas observacoes.
A SMT (simultaneous multithreading), "nome generico" pro que a Intel chama de HyperThreading Technology (nome patenteado). E', sob uma otica generalizada, muito boa, nao ha qualquer problema de seguranca ou performance HT no FreeBSD que nao seja igual ou pior em outros sistemas. Em relacao a seguranca explicitamente, o que acontece e que HTT no FreeBSD passou a vir desabilitado por padrao, o que pode ser redefinido pelo usuario (1) recompilando seu kernel com SMP e (2) definindo as seguintes variaveis no loader.conf: machdep.hyperthreading_allowed="1" E opcionalmente machdep.hlt_logical_cpus. Ainda sobre seguranca, eh fundamental ler: [1] http://www.daemonology.net/hyperthreading-considered-harmful/ [2] http://security.freebsd.org/advisories/FreeBSD-SA-05:09.htt.asc Resumindo a opera, por compartilhar o mesmo cache entre duas CPU logicas distintas e nao fazer separacao/isolamento desses espacos de enderecamento de cache entre cada unidade logica, e' possivel que um processo em uma CPU acesse e leia os dados sendo manipulados pela outra CPU logica, e em circunstancias muito raras e possivel ate que um processo em uma CPU nao apenas leia mas tambem modifique dados em cache de outra. Essa falha era apenas teorica, e foi descoberta pelo Colin Percival, na epoca parte do time de seguranca do FreeBSD e hoje o Security Officer. Essa falha pode ser explorada em qualquer sistema, e nenhum S.O. implementa uma forma de evitar essa exploracao. De fato no FreeBSD isso e um pouco dificultado devido a varias modificacoes do cperciva, quando HTT esta habilitado em um kernel SMP. Apos a divulgacao do estudo de vulnerabilidade[1] feito por cperciva, belos dias depois a Intel informou que a exploracao da vulnerabilidade era apenas teorica. No dia seguinte outro desenvolvedor FreeBSD, Poul-Henning Kamp divulgou trecho de um programa que poderia atuar como Worm, ser auto-instalado pela maioria dos Internet Explorers, e, no Windows, se a maquina fosse HTT, poderia "sentar" em uma unidade logica e ficar monitorando a espera de transacoes SSL e pegar o inicio, meio e fim de uma transacao SSL, e fazer copia do processo na outra CPU logica de todos os dados transmitidos pela sessao. Imaginem o impacto disso em transacoes bancarias. O pseudo-worm em questao nao era completo e nunca poderia ser compilado, mas talvez tenha servido de inspiracao. A intencao do PHK em divugar isso foi afirmar que a exploracao nao era apenas teorica, era perigosamente muito real, e especialmente danosa em ambiente Desktop, especialmente Windows. O codigo era apenas um POC (Prova de Conceito). Depois disso a Intel nao se pronunciou mais. Bom, em sistemas Unix a questao eh, em sistemas multiusuarios, um usuario desprivilegiado pode colocar um processo desses rodando e capturar sessoes OpenSSH ou OpenSSL inteiras de um processo privilegiado em outra CPU. E de forma bem facil de fato. Essas questoes estao documentadas no Security Advisory [2]FreeBSD-SA-05:09. Conteudo fica claro que em ambos os casos eh necessario algum privilegio, de fato, o minimo, poder executar uma aplicacao. Em Windows e com a familia de software Outlook e Internet Explorer, essa tarefa e' exageradamente simplificada. Em sistemas Unix atuando como servidores, de forma geral se nao houver outros usuarios no sistema, a tarefa eh menos simples de ser executada e a exploracao eh mais dificil. No FreeBSD ainda existe a tentativa de tentar melhorar o isolamento de processos em cada CPU logica, infelizmente incapaz de isolar completamente threads de um processo por questoes nao de software mas sim de arquitetura fisica da tecnologia HTT. Assim sendo, o potencial de exploracao passa a ser remoto e nao local, e ai chegamos em um ponto importante: hoje em dia felizmente a frequencia com que aplicacoes historicamente conseguem executar comandos remotos mesmo desprivilegiados caiu drasticamente, e quando essas falhas aparecem sao muito divugadas e sao facilmente conhecidas. No FreeBSD ainda temos o VuXML (portaudit) que ajuda demais a nao marcar bobeira com aplicacoes problematicas. Mas ainda existe um potencial muito real, sites Web com CGI, Java ou PHP. Essas abordagens Web permitem execussao de comandos como se fosse o usuario rodando o servico httpd. Entao (a) um cliente mal intencionado pode hospedar codigo que facilite ou mesmo realize essa tarefa malevola (hehe) ou (b) um cliente descuidado pode hospedar codigo mal escrito e sem sanidade de seguranca feita, e permitir, mesmo sem ter conciencia, que remotamente alguem explore esse recurso a mais - rodar uma aplicacao. Isso eh especialmente perigoso com Java e CGI, e popularmente explorado em PHP, que apesar de fornecer todos os meios necessarios pra ser usado com seguranca, poucos sysadmins tomam os cuidados necessarios pra assegurar o ambiente com PHP - e de fato menos ainda, com Java. Entao na teoria o usuario que roda o httpd (no FreeBSD, usuario www) ou que roda jacarta/tomcat poderia ser "o usuario local" a executar esse processo que ficaria monitorando o cache da outra CPU logica (e dela mesma, afinal "o cache" eh um recurso comum a ambas CPU). Esse seria um dos ambientes (provavelmente o mais) de potencial exploracao em ambiente servidor Unix. E nesse caso nao adianta medidas pseudo-tightened, como jail, chroot, UML, ou outro tipo de isolamento de processo por tecnicas de virtualizacao, porque nao interessa a estrutura hierarquica ou de privilegios do sistema operacional, estamos falando em CPU e cache de CPU, nao de privilegios no ambiente operacional. Entao se voce considerar seu ambiente bem auditado, e seguro nesses quesitos pode habilitar HTT sem duvida, ou se seu servidor simplesmente nao tem esse perfil de servico, deixar clientes hospedar aplicacoes. Bom, nesse momento cabem as consideracoes sobre Performance. As afirmacoes que uma CPU com HTT habilitada tem menor performance do que sem HTT nao podem ser consideradas sem ressalvas. Tecnicamente os gargalos de recurso causados por duas CPU logicas sao os mesmos de ter uma unica CPU. Isso ja foi muito discutido quando SMT comecou a ser pensado. A grande questao eh, que processos realmente tomam vantagem em um ambiente HTT? Essencialmente aplicacoes multithread. Se seu ambiente for essencialmente monothread pode haver varias implicacoes de performance negativas, teoricas, se tiver HTT habilitado. Mas se for multithread, a probabilidade de performance negativa eh quase nula, e o potencial de ganho de performance eh grande, chegando a 30% do poder total de processamento. Foram feitos varios benchmarks[3] que podem ser analisados com cuidados, e com graficos, quase todos usando aplicacoes multithread. Os ganhos em aplicacoes como Apache2, Postfix, BIND 9, MySQL 5, tambem podem ser bem grandes, ja aplicacoes como Qmail podem nao ter ganho nenhum, ou chegar em teoria a ter prejuizo. O caso eh que cada situacao, cada perfil de servidor, merece suas proprias observacoes, e se for generalizar, HTT em relacao a performance deve ser sempre habilitado - a ressalva ai volta a ser a seguranca - pois a possibilitada de degradacao de performance eh baixa. Historicamente de fato existe um ambiente onde a degradacao de performance eh certa, o uso de HTT com duas [4]combinacoes de software, Microsoft SQL Server e Citrix Metaframe. A Microsoft informa que o SQL Server eh massivamente multithread e tem algum ganho de performance com HTT, e a Citrix diz que o subsistema do protocolo ICA consegue ter ate 20% de ganho de performance em ambiente SMP real ou virtual. Mas o uso de ambos, que teoricamente separados usam HTT com vantagem, causa um resutado de grande queda de performance HTT chegando a ser mais prudente desabilitar HTT. O motivo? A Microsoft nao se pronuncia, a Citrix tambem nao, muito menos a Intel. Parece que eles querem dar um recado "nao sei, e isolado, meu produto nao apresenta essa deficiente entao o problema nao eh meu". Bom se o problema nao eh deles, muito menos nosso afinal nosso S.O. e' outro. Em ambiente Unix o unico caso em que vi uma discussao, controversa por sinal, onde um cara levatou a lepre de ter mais performance sem HTT do que com, foi com PostgreSQL 7, ha mais de um ano atras. Mas as consideracoes dele foram rebatidas por diversos outros que obtiveram resultado oposto, com ganho de performance usando HTT. O fato eh que se houver degradacao de performance com HTT, o caso tem que ser bem analisado e entendido, mas o senso comum eh que a diferenca de performance tem que ser positiva. Resumindo, agora minha consideracao pessoal. Todos os meus ambientes, de servidores de clientes a meu laptop, que puder ter HTT, eu uso HTT habilitado, e em todos casos so vi melhoria de performance e nunca tive qualquer problema de seguranca, e em linhas gerais a consciencia que a preocupacao de seguranca continua sendo as mais convencionais e comuns o possivel, em relacao a software desatualizado, ofusca muito a possibilitade de termos um ambiente cuja seguranca seja comprometida por ter HTT habilitado, afinal se alguem chegou ao ponto de executar uma aplicacao tao especifica no seu servidor, eh porque voce falhou em cuidar da seguranca em varios estagios anteriores, e mais primarios. [3] http://www.2cpu.com/articles/42_1.html [4] http://news.zdnet.co.uk/hardware/0,1000000091,39237341,00.htm -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
