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

Responder a