[GTER] ServerU L-800 - Primeiros Passos

Sun Aug 23 14:49:46 -03 2015

Sent from my iPhone

> On Aug 20, 2015, at 7:43 AM, Antonio Modesto <modesto at isimples.com.br> wrote:
> 
> 
> 
> On 08/19/15 19:21, Patrick Tracanelli wrote:
>>> Netmap é simplesmente uma interface de comunicação não assistida pelo kerneland entre o hardware e uma aplicação distinta, userland, ( isso ficou muito claro o hardware processa e o software toma a decisão )
>> Eu não diria não assistida, diria assistida pelo kernel - o recurso Netmap é um recurso de kernel e é o kernel quem expõe, e depois disso permite o acesso direto aos rings, passando pela benção do Kernel nas interfaces basicas do Netmap e outros primitivas básicas como alocação de memória. O que o kernel não faz é implementar recursos funcionais, ele expõe pra userland e ela se vira com a placa de rede, se não fizer nada, nada acontece, nem o básico, o pacote nem sai do hardware e fica la morgando até esgotar buffer ou alguém tirar da energia.
> 
> Patrick,
> 
> Nesse cenário que você explicou e com base no e-mail anterior, o netmap-fwd seria uma aplicação da userland (não um módulo do kernel ou algo do tipo) que coloca certas interfaces em modo netmap, toma decisões de roteamento para os pacotes que chegam nos rings das interfaces e os copia para as interfaces de saída coerentes? De uma forma básica, seria isso?

Exatamente isso. Dependendo do caminho do pacote (mesma interface) o pacote não precisa nem estagiar na aplicação, entra no ring da placa de rede e já sai por la mesmo. A decisão fica na abstração dos nic rings com os netmap rings. Tudo decidido pela aplicação de userland que colocou aquela porta (e aquelas queues de cada porta) em
modo netmap.

> 
>> 
>>> agora com relação a segurança ( não me informei nada sobre isso, netmap é novo para minha pessoa ), se tiramos metades dos atributos de segurança que o kerneland
>> Não tira metade. Tira tudo! Fica só a abstração e exposição e o isolamento entre system e kernel fica por conta da malloc.
>> 
>>> oferece diretamente fica a pergunta, é de responsabilidade da aplicação lidar com tais potenciais falhas de segurança ou do hardware ?
>> Com toda certeza da aplicação. Mas estamos falando de pacotes de rede não de alocação arbitrária de instruções em memória. Se você olhar pelo lado “perigoso”, seria processar a camada 7 (aplicação), o que o suricata por exemplo ja faz. Mas o que o Suricata (ou qualquer outro IDS faz) ja é a mesma coisa e com a mesma responsabilidade, processar o payload da forma mais segura (ou insegura, ou qualquer forma se quiser) que o valha.
>> 
>> O kernel só vai garantir que o isolamento, separação de páginas de memória e proteções inerentes a uma aplicação da userland e uma aplicação em kernel continuem isolados. Por isso o Luigi Rizzo fez questão de se preocupar em manter o malloc e todo controle de alocação e acesso a memória da forma nativa, “pedindo benção” ao kernel. Diferente por exemplo do que o DNA (Direct NIC Access) faz.
>> 
>> Basicamente, bom, tem um fluxo de arquivos xxx.c por onde um pacote normalmente passa no kernel, eu tenho isso num dos slides que uso pro tema mas é mais ou menos o seguinte. Pra um pacote entrar no ring da placa e chegar na aplicação esse pacote, no kernel (em kernel-path) passaria por:
>> 
>> 0 - Pacote na placa, que grita interrupt request ou o polling vai la processar o ring antes da interrupção
>> 1 - Uma call sendto() ou receive (ou ioctl em modo receive)
>> 2 - uipc_syscalls.c (pelo menos 2 vezes, 2 calls aqui entro)
>> 3 - uipc_syscalls.c (pelo menos 2 vezes)
>> 4 - uipc_socket.c
>> 5 - uipc_socket.c (pelo menos 2 vezes também, sosend e mbuf)
>> 6 - tcp|udp_ussreq.c (pelo menos 1 vez, normalmente 2)
>> 7 - if_ethersubrc.c (pelo menos 1 vez, normalmente 2-5)
>> 8 - if_XXX.c (implementacao do driver da placa de rede, pelo menos 3 vezes)
>> 9 - if_XXX.c (implementacao do driver da placa de rede, pelo menos 3 vezes)
>> 10 - if_XXX.c (implementacao do driver da placa de rede, pelo menos 3 vezes)
>> 11 - ip_input.c ou ip_fw ou output dependendo do fluxo, ao menos 1 vez
>> 12 - FINALMENTE chegou na aplicação
>> 
>> Então ao se colocar uma porta em modo Netmap, se pula isso tudo e se joga direto pra aplicação, pula da etapa 0 pra etapas 12 e é ai que ganhamos a performance.
>> 
>> Sob a otica de segurança imagine que seu pacote “nocivo extremamente perigoso do mal” está agora transitando por pelo menos 12 etapas a menos de kernel, um malloc e uma inicialização do netmap ele ja chega na aplicação.
>> 
>> Entendeu o que estou tentando sugerir? O risco é menor, voce tem menos kernel envolvido e se algo “de ruim” ou “maldoso” acontecer será ja na aplicação, não em etapas do kernel, e portanto menos crítico. Se a aplicação tentar acessar área de memória do kernel, ele não deixa. Se a aplicação tentar acessar área de outra aplicação o kernel não deixa. Então o pior que a aplicação poderá é fazer mal a ela mesma. O que claro não é pouco, imagine eu interceptar um pacote que era seu e não era meu. Mas esse risco não é maior por ser em modo netmap. É na pior das hipóteses o mesmo riso de ter seu pacote entrando pelo suricata, snort, ou seu pacote entrando no natd via divert…
>> 
>>> A partir daqui surge mais uma infinidade de perguntas !! Algumas abaixo.
>>> - Como se corrige um bug no hardware quanto algo muito importante é o alvo, ele é calcanhar de Aquiles da solução pelo que notei,  visto que todo o processamento da chelsio está no hardware um bug ou falha de segurança poderá impactar negativamente uma area ( recurso ) enorme !!! como seria tais condições tratadas ? troca do hardware? desativação do modo netmap? ativação de backup que poderá lidar com a carga no qual o netmap conteve ?
>> Bug no hardware se resolve, jogando o hardware fora hehehe. Ou jogando de verdade ou reinventando e tentando reapresentar ele com outra roupagem. Lembra do HTT da Intel? Inseguro e bugado… jogou fora? Não, deu uma arrumada e uma outra roupagem e veio o SMT. Sem o bug que o HTT tinha que permitia um processo acessar toda informação que tem no registrador do outro hehehe
>> 
>> Lembra da primeira revisão do Firewire? Alta performance, nenhuma segurança. Jogaram fora e veio algo novo.
>> 
>> Enfim não entendi o aspecto amplo da sua pergunta mas se o problema é no hardware, é isso, joga fora hehehe. Ou como todo risco, voce pode aceitar e conviver. Sei la gestão de risco kkk ;-) O fato é que o software seja kernel-path ou DNA ou DPDK ou Netmap ou Linux skbuf ou umm NDIS do Windão.. o software não vai corrigir. Se tudo der certo o software não atrapalhará apenas mas corrigir não vai. Se for algo especifico firmware talvez seja suficiente atualizar. Uma hipótese mas depende da situação pratica real.
>> 
>> 
>>> - Ainda na parte de hardware e relacionado a segurança. Não tenho claramente o conhecimento e vivência do Sr. para questionar isso, mas o netmap não seria um potencial backdoor para falhar de segurança no qual o FreeBSD poderá não estar evoluído para lidar ( hardware ultrapassando kerneland sem vigília ) ? essa pergunta é interessante visto que conforme a pergunta anterior o netmap ultrapassa significativamente os recursos on-kernel de segurança deixando toda a carga de decisão para uma aplicação userland que poderá ser comprometida através do netmap. ( acho que é a mesma pergunta anterior com palavras diferentes. )
>> Como eu disse so se a aplicação em modo Netmap acessar uma área de memória que não é dela, seja do kernel ou de outra aplicação. Mas se isso acontecer não é uma falha do (ou motivado pelo) Netmap. Sua preocupação ela faz todo sentido numa abordagem tipo DNA. Na abordagem Netmap não, o kernel deu benção pra parada toda existir e a aplicação colocar a porta em modo Netmap. Se algo for explorado quem vacilou foi o kernel ;-)
>> 
>>> - Essa questão não é mais com relação a tecnologia diretamente, mas mercadológica. A principal diferença dos atuais fabricantes de hardware de comutação e roteamento é a capacidade de encaminhamento de pacotes e nos últimos 10 anos sistemas open-sources começaram a encomodar um nicho de mercado muito seleto, em pouco tempo uma caixa MX-5 da Juniper ou um Cisco ASR9001 serão 4 vezes mais caras que um L800 que possui 8 vezes mais recursos ( Inicialmente observados ). Há riscos de tais fabricantes começarem uma campanha negativa para tais inovações ?
>> Eu não diria que chega a incomodar no cenário atual.
>> 
>> Quando colocamos a L800 e a L100 no mercado foi pra preencher um GAP que olhamos, estava em aberto. Como se roteia 3, 5G BGP sem ir pra uma caixa proprietária e cara? Com 1G, até 2G, voce vai num hardware a custo bom pra um negócio desse porte. E começa a morrer por ai. Pra colocar 6 portas igb com 8 threads MSIX cada ou uma porta 10G ou 40G mesmo que a porta não reflita sua real necessidade de roteamento mas sim de conexão, num server de base Xeon voce começa a gastar uma fortuna… se não prestar atenção ja gastou um carro, se olhar de novo ja dava pra ter comprado um Juniper MX5.
>> 
>> A proposta nossa com a L800 é buscar fechar esse GAP. Tem negócios que vai rapidamente passar de 3, 5G, e em algum momento investir em algo bem mais caro não será uma decisão difícil. Mas tem negócios que não passarão disso tao fácil ou tao cedo, ou nunca passarão e pra esses negócios ficar com um hardware simples pode não ser suficiente. Ir pra um Juniper pode ser oneroso demais e muitas vezes não ter o retorno do investimento, afinal se o cara quer rotear 50G ir pra um Juniper serie MX é uma coisa mas se tudo que ele quer é rotear 3, 5G e ter alguma resiliencia a uma taxa de pps maior, num ataque ou uma “variação de humor” da Internet… o ROI dele vai levar anos e anos pra voltar se comprar um Juniper MX/X da vida. Principalmente se ele precisar de upgrade de licença pra ir pra portas 10G (mesmo tendo um negocio essencialmente de alguns pares de 1G apenas).
>> 
>> ROI e TCO se calcula em períodos cada vez mais curtos. Antes eram de 60 meses hoje ja se considera facilmente 30 meses. Não é qualquer negocio que devolve o ROI de uma caixa dessas em 30 (ou 60 que seja) meses. Esse é o GAP que nos queremos preencher.
>> 
>> Agora de volta a incomodar, bom o mercado se mexe. A Intel não gosta da ideia de alguém dizer que Intel não é bom pra alta taxa de PPS. Nem deixar de vender placas de rede dela porque alguém tem uma opção 5x mais cara com aceleração em hardware, seja FPGA, seja ASICS, seja GPGPU. Então ela corre atras e botou o DPDK na jogada.
>> 
>> A comunidade cientifica também ve que o kernel anda “demorando muito” pra fazer coisas numa taxa exponencialmente menor do que o mundo anda demandando e investe nesse sentido, tai Netmap e DNA por exemplo.
>> 
>> Guerra é guerra, os fabricantes estão ai se atacando e se comendo. Seja Cavium, seja Solarflare, seja Napa, seja Chelsio, seja Intel. Todos querem uma fatia do bolo. E quem ganha com isso, sinceramente, somos apenas nós. Fabricantes espertos ganham novos markets, nichos. Veja Palo Alto, não tem nada de novo ou inovador no que o NGFW da Palo Alto faz. Mas… como faz naquela taxa de PPS com um hardware que não é uma pechincha mas é acessível? GPGPU. Da pra gente “fazer em casa?” ué olha o OpenCL ai… olha CUDA. Quem tiver uma boa ideia e dinheiro e tempo pra investir nela pode ter bons resultados.
>> 
>> Eu particularmente não vejo Cisco ou Juniper se preocupando com nada disso, mas provavelmente estão de olho pra mapear em que momento podem tirar melhor proveito e integrar elas também. Por exemplo existe um “silencio” muito grande em torno do DPDK. E sabemos que tem gente usando, explorando, mexendo e testando. O que vai aparecer mês que vem ou em 3 meses depende diretamente do resultado de quem está trabalhando hoje. Veremos… pode ser um novo player ou um player antigo apresentando algo novo.
>> 
>> Mas se preocuar… duvido que algum grande player esteja se preocupando. Veja a Cisco quando se incomodou em não ter um produto que tirasse proveito de GPGPU pra filtro de email, conteudo, DLP, IDS/IPS… comprou a Ironport, um FreeBSD com tudo isso pronto e rodando hehehe.
>> 
>> Se alguém se incomodar voce ve uma aquisição em algum momento.
>> 
>>> sempre considero que dinheiro fazem humanos a fazerem ações inumanas e não compreendo como o mercado está lidando com uma caixa que tira os seus produtos de entrada do foco, e isso é claro a dois anos atrás Juniper MX5 e Cisco ASR 9000 series era a primeira indicação de quem ultrapassava a barreira dos 1 Mpps tanto na GTER, FUG e demais listas, hoje é o L800 que diferente do mikrotik veio para concorrer de igual para igual com grandes nomes e que em determinado momento superou as expectativas de um MX-5.
>> É esse o ponto em que eu discordo. Não tira seus produtos de entrada, muitas vezes o produto de entrada é grande demais hehehe. Esse buraco existe e os grandes players não colocaram um produto la pq provavelmente pra eles esse mercado seja irrelevante, e sendo assim vai demorar pra eles notarem. Que dirá se incomodarem… :P Mais provavelmente que não aconteça :-)
>> 
>> 
>> --
>> Patrick Tracanelli
>> 
>> FreeBSD Brasil LTDA.
>> Tel.: (31) 3516-0800
>> 316601 at sip.freebsdbrasil.com.br
>> http://www.freebsdbrasil.com.br
>> "Long live Hanin Elias, Kim Deal!"
>> 
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> 
> -- 
> 
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter