AES-NI no OpenSSL ou descarga no kernel: qual você precisa?

Duas etiquetas são usadas como se fossem a mesma coisa: acelerado por hardware e descarregado no kernel. Uma descreve quais instruções a rotina AES de uma biblioteca executa, a outra descreve onde ocorre o processamento dos pacotes. Uma VPN pode ter a primeira sem a segunda, a segunda sem a primeira ou ambas ao mesmo tempo. Qualquer decisão sobre desempenho deve começar nomeando qual das duas você está realmente mudando.

Dois eixos, não uma pontuação

O primeiro eixo é a implementação: o código que faz AES-256-GCM é encaminhado para uma versão que usa as instruções dedicadas do processador ou para uma rotina portátil que as executa como aritmética comum. Essa escolha vive dentro da biblioteca criptográfica e é feita quando ela é inicializada.

O segundo eixo é a colocação: o pacote atravessa o caminho de transformação do kernel ou um daemon no espaço do usuário lê de um dispositivo de túnel, cifra e grava de volta.

Nenhum eixo restringe o outro. Uma VPN no espaço do usuário numa CPU com instruções AES pode usá-las o tempo todo, e um caminho no kernel numa CPU sem elas recorre a uma implementação em software. Os rótulos nos materiais dos fornecedores raramente fazem essa distinção, e é por isso que conselhos de ajuste copiados entre as duas situações tantas vezes não fazem nada.

Eixo um: qual código faz a cifragem

O OpenSSL detecta recursos do processador durante a inicialização e usa o resultado para escolher caminhos de código otimizados, como descreve a documentação de recursos x86. AES-NI é um dos recursos documentados por trás desse despacho. Nada disso exige que a biblioteca se torne um componente do kernel.

Confirme que o recurso é visível para o processo antes de supor que o caminho rápido é usado. No Linux a fonte é o campo flags em /proc/cpuinfo, e dentro de um convidado ele reflete o que o hipervisor expõe e não o nome do modelo do host físico.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

O segundo comando nomeia os provedores carregados naquela compilação. Ele não diz qual biblioteca o serviço VPN linkou, e um host pode carregar duas instalações de OpenSSL enquanto o processo em execução usa apenas uma delas.

Eixo dois: onde o caminho dos pacotes roda

Colocar no kernel significa que a transformação ocorre na maquinaria IPsec do próprio kernel ou dentro de um driver de túnel no kernel, então os pacotes não precisam de uma ida e volta por um processo no espaço do usuário para cada lote. Isso pode cortar cópias e trocas de contexto, e distribuir o trabalho entre núcleos como um daemon de um único thread não consegue. Também move os contadores e rastros que você vai ler quando a vazão cair, porque o trabalho agora acontece do outro lado de uma fronteira que você não controla. Considere isso um custo de depuração, não apenas uma decisão de desempenho.

Isso não cria suporte a instruções, não configura uma cifra e não faz uma rota existente funcionar.

A virtualização acrescenta uma dobra também neste eixo. Um convidado pode receber um modelo de CPU mascarado que esconde recursos que o host tem, e um convidado aninhado pode ver ainda menos. Leia a visão de recursos de dentro do ambiente onde a VPN realmente roda, não do console do hipervisor.

O que cada escolha compra, e o que ela não pode

A pergunta prática é para onde vai o tempo. Se um único thread ocupado, cópias repetidas do buffer ou uma chamada de sistema por pacote limitam a vazão, mover a transformação para um caminho que elimina esses custos pode ajudar, desde que o kernel implemente a transformação de que você precisa.

Se o limite é um uplink congestionado, um caminho com perdas, um tempo de ida e volta longo, um serviço de destino saturado ou um thread fixado a um núcleo, a colocação não muda nada importante. O mesmo vale para a escolha de instruções: AES em hardware dedicado não conserta uma rota ausente e não ajudará se o túnel estiver ocioso porque a resolução de nomes falha.

Onde as duas se aplicam, elas se compõem. Um caminho no kernel pode usar o mesmo despacho em nível de instrução dentro da API criptográfica do kernel, e um caminho no espaço do usuário com uma biblioteca bem escolhida já o usa. A decisão não é qual é mais rápido em abstrato; é para qual custo você tem evidência.

Anote os quatro fatos antes de mudar qualquer coisa

Anote o binário do serviço e a biblioteca criptográfica à qual ele está linkado, porque esses decidem o eixo um. Depois registre a proteção de dados negociada, porque uma cifra sem caminho de instruções dedicado se comporta de forma diferente de uma com ele, e o conjunto é escolhido pelas duas partes.

Em seguida, a visão de recursos de dentro do ambiente em execução e, por fim, o caminho de pacotes ativo com evidência de que o modo que você acha habilitado está mesmo habilitado. Um módulo carregado não é prova de que um perfil o use, e uma linha de configuração não é prova de que o kernel a aceitou.

Mude uma coisa e compare com uma carga de trabalho constante com os mesmos extremos e a mesma direção de transferência. Uma afirmação de velocidade que você não mediu vale menos que uma nota dizendo que o backend nunca esteve em dúvida.