Os desenvolvedores da Cloudflare realizaram um trabalho de otimização do desempenho da criptografia de disco no núcleo do Linux. Como resultado, foram preparados para a subsistema e Crypto API, que permitiram aumentar em mais de duas vezes a capacidade de transferência em testes sintéticos ao ler e gravar, além de reduzir em duas vezes as latências. Ao testar em hardware real, as despesas gerais com a criptografia foram reduzidas praticamente ao nível observado em operações com disco sem criptografia de dados.
A Cloudflare utiliza dm-crypt para criptografar dados em armazenamentos usados para o cache de conteúdo na rede CDN. O dm-crypt opera no nível de dispositivo de bloco e realiza a criptografia de solicitações de entrada/saída de gravação e a descriptografia de solicitações de leitura, atuando como uma camada entre o dispositivo de bloco e o driver do sistema de arquivos.
Para avaliar o desempenho do dm-crypt, foi utilizado o pacote para medir a velocidade de leitura e gravação em partições criptografadas e não criptografadas em um disco RAM, alocado na RAM para excluir flutuações de desempenho dos discos e focar no desempenho do código. Para as partições não criptografadas, o desempenho de leitura e gravação se manteve em torno de 1126 MB/s, mas ao ativar a criptografia, a velocidade caiu 7 vezes e ficou em 147 MB/s.
Inicialmente, suspeitou-se da utilização de algoritmos ineficientes no sistema de criptografia do núcleo. Mas nos testes foi utilizado o algoritmo mais rápido aes-xts com uma chave de criptografia de 256 bits, cujo desempenho em "cryptsetup benchmark" é mais do que o dobro do resultado obtido no teste do disco RAM. Experimentos com bandeiras dm-crypt para ajuste de desempenho não tiveram sucesso: ao usar a bandeira "—perf-same_cpu_crypt", o desempenho até mesmo caiu para 136 MB/s, e ao especificar a bandeira "—perf-submit_from_crypt_cpus", aumentou apenas para 166 MB/s.
Uma análise mais profunda da lógica de funcionamento mostrou que o dm-crypt não é tão simples quanto parece — ao receber uma solicitação de gravação do driver do sistema de arquivos, o dm-crypt não a processa imediatamente, mas a coloca na fila "kcryptd", que não é atendida imediatamente, mas quando surge uma oportunidade. Da fila, a solicitação é enviada para a API Crypto do Linux para realizar a criptografia. Mas como a API Crypto utiliza um modelo de execução assíncrono, a criptografia também não é realizada imediatamente, passando por mais uma fila. Após a finalização da criptografia, o dm-crypt pode tentar executar a ordenação das solicitações de gravação pendentes, utilizando uma árvore de busca. . No final, um thread separado do núcleo novamente, com um certo atraso, coleta as solicitações acumuladas de entrada/saída e as envia para a pilha do dispositivo de bloco.
Ao ler, inicialmente o dm-crypt adiciona à fila "kcryptd_io" uma solicitação para obter dados do dispositivo. Após algum tempo, os dados se tornam disponíveis e são colocados na fila "kcryptd" para descriptografia.
O kcryptd envia a solicitação à API Crypto do Linux, que descriptografa as informações em modo assíncrono. As solicitações nem sempre passam por todas as filas, mas no pior cenário, uma solicitação de gravação permanece nas filas até 4 vezes, e uma solicitação de leitura até 3 vezes. Cada vez que uma solicitação entra em uma fila, isso gera atrasos, que são a principal razão para a significativa redução da performance do dm-crypt.
A aplicação de filas é necessária para o funcionamento em condições onde ocorrem interrupções. Em 2005, quando o modelo atual de operação do dm-crypt baseado em filas foi implementado, o Crypto API ainda não era assíncrono. Após a transição do Crypto API para um modelo de execução assíncrono, uma forma de proteção dupla passou a ser aplicada. Filas também foram introduzidas para economizar o uso da pilha do kernel, mas após seu aumento em 2014, essas otimizações perderam relevância. Uma fila adicional chamada "kcryptd_io" foi criada para superar um ponto crítico que resultava na espera pela alocação de memória com um grande número de solicitações. Em 2015, uma fase de ordenação foi implementada, pois as solicitações de criptografia em sistemas multiprocessadores podiam ser completadas fora da ordem de envio (em vez de acesso sequencial ao disco, eram acessos aleatórios e o planejador CFQ funcionava de forma ineficiente). Atualmente, com o uso de unidades SSD, a ordenação perdeu seu sentido e o planejador CFQ não é mais utilizado no kernel.
Considerando que os dispositivos modernos se tornaram mais rápidos e inteligentes, o sistema de alocação de recursos no kernel Linux foi revisado e algumas subsistemas foram reestruturados, engenheiros da Cloudflare no dm-crypt, um novo modo de operação foi introduzido, eliminando o uso de filas desnecessárias e chamadas assíncronas. O modo é ativado por uma flag separada "force_inline" e transforma o dm-crypt em uma simples proxy que criptografa e descriptografa as solicitações recebidas. A interação com o Crypto API foi otimizada ao escolher explicitamente algoritmos de criptografia que operam em modo síncrono e não utilizam filas de solicitações. Para operação síncrona com o Crypto API, foi um módulo que permite o uso de FPU/AES-NI para aceleração e que direciona diretamente as solicitações de criptografia e descriptografia.
Como resultado, foi possível aumentar a performance do dm-crypt em mais de duas vezes ao testar um disco RAM — a performance subiu de 294 MB/s (2 x 147 MB/s) para 640 MB/s, o que é muito próximo à performance da criptografia sem intermediários (696 MB/s).
Durante os testes de carga em servidores reais, a nova implementação mostrou um desempenho muito próximo da configuração que opera sem criptografia, e a ativação da criptografia em servidores com cache Cloudflare não afetou de forma alguma a velocidade de resposta. No futuro, a Cloudflare planeja integrar os patches preparados ao núcleo principal do Linux, mas antes disso, será necessário reestruturá-los, pois estão otimizados para uma carga específica e não abrangem todas as aplicações, como a criptografia em dispositivos embarcados de baixo consumo.
Fonte: opennet.ru
