Desarrolladores de Cloudflare trabajan en parches para aceleran el cifrado de disco en Linux
Los desarrolladores de Cloudflare han dado a conocer información sobre el trabajo que estan realizado para optimizar el rendimiento del cifrado de disco en el kernel de Linux, de lo cual mencionan que han preparado parches para los subsistemas dm-crypt y Crypto API.
Con ello, se permitió que la prueba sintética duplicara el ancho de banda para leer y escribir, así como reducir a la mitad la latencia. Al realizar pruebas en equipos reales, la sobrecarga del cifrado se redujo a casi el nivel observado al trabajar con un disco sin usar el cifrado de datos.
El interés por mejorar el cifrado de datos en el disco es debido a que Cloudflare usa dm-crypt para cifrar datos en unidades utilizadas para almacenar contenido en caché en una red CDN. Dm-crypt funciona a nivel de dispositivo de bloque y cifra las solicitudes de E / S para escribir y descifrar las solicitudes de lectura, actuando como una capa entre el dispositivo de bloque y el controlador del sistema de archivos.
Para evaluar el rendimiento de dm-crypt utilizando el paquete de prueba de E/S flexible, se midió la velocidad de trabajar con particiones cifradas y no cifradas en un disco RAM ubicado en RAM para eliminar las fluctuaciones en el rendimiento del disco.
Para particiones sin cifrar, el rendimiento de lectura y escritura se mantuvo a 1126 MB/s, pero cuando se activó el cifrado, la velocidad disminuyó 7 veces y ascendió a 147 MB /s.
Al principio, se sospechaba el uso de algoritmos ineficientes en el sistema criptográfico del núcleo. Pero las pruebas utilizaron el algoritmo aes-xts más rápido con 256 claves de cifrado, cuyo rendimiento al ejecutar el “punto de referencia cryptsetup” es más de dos veces mayor que el resultado obtenido al probar el disco RAM.
Los experimentos con indicadores dm-crypt para ajustar el rendimiento no funcionaron: cuando se usaba el indicador –perf-same_cpu_crypt, el rendimiento incluso disminuía a 136 MB/s, y cuando se usaba el indicador –perf-submit_from_crypt_cpus solo aumentaba a 166 MB/s.
Un análisis más profundo de la lógica del trabajo mostró que dm-crypt no es tan simple como parece.
Cuando se recibe una solicitud de escritura del controlador FS, dm-crypt no la procesa de inmediato, sino que la coloca en la cola “kcryptd”, que no se comprende de inmediato, pero cuando ocurre Un buen momento. Desde la cola, la solicitud se envía a Linux Crypto API para realizar el cifrado.
Al leer primero, dm-crypt agrega a la cola “kcryptd_io” una solicitud para recibir datos de la unidad. Después de un tiempo, los datos están disponibles y se colocan en la cola “kcryptd” para el descifrado.
Kcryptd envía una solicitud a la API de cifrado de Linux, que descifra la información en modo asíncrono. Las solicitudes no siempre pasan por todas las colas, pero en el peor de los casos, la solicitud de escritura se establece en las colas hasta 4 veces y la solicitud de lectura hasta 3 veces. Cada golpe en la cola conduce a retrasos, que son la razón clave de una disminución significativa en el rendimiento de dm-crypt.
Teniendo en cuenta que las unidades modernas se han vuelto más rápidas e inteligentes, se ha revisado el sistema de asignación de recursos en el kernel de Linux y se han rediseñado algunos subsistemas, los ingenieros de Cloudflare han agregado un nuevo modo operativo a dm-crypt, eliminando el uso de colas adicionales y llamadas asíncronas.
El modo está habilitado por un indicador separado “force_inline” y lleva a dm-crypt a la forma de un proxy simple que cifra y descifra las solicitudes entrantes. La interacción con Crypto API se ha optimizado mediante una elección explícita de algoritmos de cifrado que funcionan en modo síncrono y no utilizan colas de solicitud.
Al probar la carga en servidores reales, la nueva implementación mostró un rendimiento muy cercano a la configuración que funciona sin cifrado y la inclusión del cifrado en servidores con caché Cloudflare no afectó la velocidad de respuesta.
En el futuro, Cloudflare planea transferir los parches preparados al núcleo principal de Linux, pero antes de eso deberán ser modificados, ya que están optimizados para una determinada carga y no cubren todas las áreas de aplicación.
Fuente: https://blog.cloudflare.com