[GTER] ServerU L-800 - Primeiros Passos

Thu Sep 10 12:16:22 -03 2015

https://www.youtube.com/watch?v=jTIoTI0aK5g


2015-08-23 14:49 GMT-03:00 Patrick Tracanelli <eksffa at freebsdbrasil.com.br>:

>
>
> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Vinícius Zavam
keybase.io/egypcio/key.asc