Acerca del informe mensual del kernel de Linux
Campo de lectura de Linux
La columna del informe mensual del kernel de Linux es un resumen de las tendencias de desarrollo de primera línea más importantes de la comunidad del kernel de Linux ese mes, lo que facilita a los lectores el seguimiento de las tendencias de desarrollo más avanzadas del kernel de Linux.
Debido a las limitaciones de espacio, solo se dará una descripción general aproximada de la última tecnología. Espere los artículos de seguimiento para obtener detalles técnicos. Los lectores también pueden contribuir con contribuciones a la comunidad de campos de códigos de lectura.
Los principales contribuyentes de este informe mensual:
Zhang Jian, Liao Weixiong, chenwei, verano
Enlaces anteriores:
Informe mensual de Linux Reading Field-Linux Kernel (junio de 2020)
Informe mensual de Linux Reading Field-Linux Kernel (julio de 2020)
Informe mensual de Linux Reading Field-Linux Kernel (agosto de 2020)
Informe mensual de Linux Reading Field-Linux Kernel (septiembre de 2020)
阅码场征稿Linux阅码场征集Linux工程师一线研发心得；工程师、高校学生老师、科研院所研研究人员对Linux某一技术要点深入分析的稿件。您的文章将获得近十万一线Linux工程师的广泛受众。投稿要求：原创且从未在任何媒体、博客、公众号发表过的文章。高屋建瓴、深刻全面地论述一个技术点或者面。投稿请微信联系小月：linuxer2016录取的稿件，我们也会奉上微薄的稿酬聊表寸心，稿费标准为300-500元/篇。
Uno, relacionado con la arquitectura
1.1 ARM / arm64 set_fs
补丁 集 1 ： ARM: eliminar los llamadores y la implementación de set_fs
Conjunto de parches 2: arm64: eliminar set_fs () y amigos
Cuando ve fs en el código del kernel, ¿en qué piensa? Sistema de archivos? Sin embargo, la imagen está rota, el fs del que vamos a hablar hoy es en realidad el registro fs de x86 [1]. La versión 0.1 del kernel introdujo set_fs para establecer el rango de direcciones del espacio de usuario (`set_fs (USER_DS)`) y el espacio del kernel (`set_fs (KERNEL_DS)`). Originalmente set_fs solo configuraba el registro x86 fs, y otras arquitecturas también seguían el nombre set_fs. Está bien si solo se confunde el nombre, el problema es que set_fs parece estar protegiendo, lo mismo
Es un punto de ataque. Si la restricción correspondiente `set_fs (USER_DS)` no se establece al regresar al espacio de usuario desde el kernel, el espacio de usuario tiene la capacidad de espacio de memoria ilimitado. Hubo informes similares en 2010 (CVE-2010-4258) y 2016.
El endurecimiento basado en set_fs [2] parecía ser una forma, pero fue rechazado porque afectaría el rendimiento de las llamadas al sistema del kernel. Por lo tanto, solo hay una opción: eliminar set_fs. emm, hace tres años, esto fue el resultado de las discusiones de la comunidad hace tres años. Este año Christoph Hellwig continuó con su propuesta original. En la actualidad, la parte del código central del kernel se ha completado y las arquitecturas restantes deben modificarse. Este mes, los parches de arquitectura ARM y ARM64 se están enviando para revisión.
Para ARM64, además del código de limpieza, es necesario lidiar con el código que involucra el cambio de espacio de usuario y kernel, que involucra principalmente tres partes: SDEI, PAN y UAO. Para ARM, además de eliminar el código set_fs, es necesario procesar varias llamadas al sistema de oabi.
参考资料
[1]https://lwn.net/Articles/722267/
[2]https://lwn.net/Articles/721305/1.2 KASan para ARM
Kernel Address SANitizer (KASAN) es un detector de errores de memoria dinámica que busca principalmente fuera de límites y uso después de libre. Actualmente, se admiten X86, ARM64, RISC-V, PowerPC y otras arquitecturas.
Linus Walleij envió el parche de la decimocuarta edición de KASan for Arm este mes (este es el soporte de la arquitectura ARM para KASan), en comparación con el parche del mes pasado, Linus reparó su falla en la plataforma Qualcomm APQ8060. Él también espera eso. Puede solucionar problemas informados por Florian y Ard.
KASan de ARM64 agrega detección de errores de memoria basada en etiquetas de hardware. Esta serie de parches aplica las capacidades de Memory Tagging Extension (MTE) a KASan, genera una etiqueta aleatoria cada vez que se asigna memoria y la comprueba automáticamente cada vez que se accede a la memoria. Si no coincide, se genera un error de etiqueta y KASan informa del error.
(Nombre del parche: kasan: agregar modo basado en etiquetas de hardware para arm64)
1.3 Transferir el registro de medición de IMA en kexec en ARM64
La implementación de cada arquitectura del kernel tiene tanto puntos en común como características, y a menudo los recién llegados considerarán modificar la implementación de una arquitectura anterior para que sea más general. El trabajo de RISC-VNUMA que presentamos en el informe mensual del kernel se basó en ARM64. El conjunto de parches de hoy es similar.
IMA (Arquitectura de medición de integridad) es uno de los dos componentes principales de la integridad del núcleo. IMA puede verificar la integridad del archivo cuando se ejecuta o se abre. Para kexec (kexec admite el inicio de un nuevo kernel desde el kernel actual): IMA puede verificar su kernel, initramfs y línea de comando. Los cuatro parches de Lakshmi son para complementar esta capacidad que actualmente no es compatible con ARM64.
1.4 Además de los parches anteriores, todavía hay muchos parches dignos de atención en octubre. P.ej
Presentar la MMU de TDP
El propósito es mejorar el rendimiento de la migración en caliente de las máquinas virtuales de memoria a nivel de TB. El significado de TDP es: paginación bidimensional. En la actualidad, TDP MMU se ha utilizado en la máquina virtual 12TiB m2-ultramem-416 de Google con 416 vCPU para proporcionar el rendimiento de migración en caliente necesario.
La motivación de este trabajo es procesar las fallas de página en máquinas virtuales muy grandes en paralelo. Cuando la máquina virtual tiene cientos de vCPU y TB de memoria, el bloqueo MMU de KVM sufre una competencia extrema, lo que resulta en un bloqueo suave o un gran retraso en el procesamiento de fallas de página en el sistema operativo invitado.
Agregue soporte para sistemas asimétricos AArch32
El propósito es utilizar la aplicación aarch32 en el espacio del usuario cuando solo una parte de la CPU arm64 del sistema es compatible con el entorno operativo aarch32 EL0. Observaciones: la CPU arm64 puede tener dos entornos operativos (EE: entorno de ejecución), a saber, aarch64 y aarch32.
PKS: agregar soporte de supervisor de claves de protección (PKS)
Este es un trabajo de kernel similar a PKU (claves de protección de memoria de espacio de usuario), y los escenarios de uso esperados son claves confiables y PMEM.
2. Relacionado con el núcleo del núcleo
2.1 puntos de seguimiento durmientes
Los Tracers actuales no pueden acceder a los datos en modo usuario porque no pueden manejar fallas de página, sin embargo, esto es a veces un requisito.
Esta serie de parches implementa un marco que permite a los rastreadores manejar fallas de página en el marco de puntos de rastreo, y varios rastreadores realizarán los cambios correspondientes en el futuro.
2.2 Programación principal v8
La programación del núcleo es una característica que permite que los procesos confiables se ejecuten al mismo tiempo en el cpus de recursos compartidos. El propósito principal es eliminar los ataques de canal lateral a nivel del núcleo sin deshabilitar la función SMT.
De forma predeterminada, esta función no cambiará ningún comportamiento de programación actual. El usuario debe decidir qué tareas se pueden ejecutar en el mismo núcleo al mismo tiempo. Por ejemplo, cuando se está ejecutando un proceso A, los hyperthreads del mismo núcleo están inactivos o solo pueden ejecutar procesos en los que confía el proceso A.
2.3 KFENCE v5: una herramienta de detección de errores de memoria de muestreo bajo
La característica principal de KFENCE es utilizar el menor sacrificio de rendimiento posible para muestrear varios errores de memoria en la línea. En comparación con KASAN, la precisión de KFENCE no es tan alta, pero KFENCE tiene poco impacto en el rendimiento y se puede implementar en una gran cantidad de entornos de producción. También puede detectar errores de memoria.
Esta serie de parches agrega compatibilidad con KFENCE para arquitecturas arm y x86.
3. Sistema de archivos y capa de bloques
3.1 Bloque de filtrado de solicitudes y módulo de instantánea de dispositivos de bloqueo
* Parche: https://lwn.net/Articles/834867/
* veeamsnap:
https://github.com/veeam/veeamsnap/
El autor del parche proviene de veeam, una empresa que ofrece soluciones de respaldo para Linux. Durante mucho tiempo, se ha proporcionado un servicio de copia de seguridad de dispositivos en bloque en forma de un módulo de árbol del núcleo (veeamsnap). Esta presentación es un intento de fusionar sus módulos de función principal en la rama principal.
El parche implementa dos funciones, blk-filter y blk-snap:
blk-filter implementa la interceptación de solicitudes BIO para dispositivos de bloque e intercepta solicitudes BIO muy pronto, sin afectar en absoluto la cola de procesamiento de solicitudes. Además de interceptar todo el medio de almacenamiento, también admite la interceptación de dispositivos de bloque específicos, tanto en unidades como en particiones. También hay una función que admite la activación y desactivación dinámica de funciones de filtrado. Cuando se carga el dispositivo de bloqueo, puede comenzar a filtrar automáticamente la solicitud BIO; cuando se quita el dispositivo de bloqueo, el filtro también se quita automáticamente.
blk-snap implementa funciones de seguimiento de cambios de instantáneas y bloques. No hay duda de que se basa en blk-filter. Está diseñado para crear una copia de seguridad de cualquier dispositivo de bloque sin utilizar un mapeador de dispositivos. La instantánea es temporal y se destruirá una vez que se complete el proceso de copia de seguridad. El seguimiento de bloques modificados permite copias de seguridad incrementales y diferenciales.
3.2 btrfs agregó soporte para lectura y escritura de subpágina 4K
* Parche: https://lwn.net/Articles/834872/
El parche es principalmente para permitir que los sistemas con un tamaño de página de 64K monten btrfs con un tamaño de sector de 4K y admitan lectura y escritura normales en este estado.
El tamaño de página de 64K provocará un desperdicio de espacio interno con algunos datos pequeños. Si puede haber una granularidad de operación menor, el desperdicio de espacio se puede aliviar en gran medida. Por lo tanto, es necesario admitir el funcionamiento de subpáginas 4K. Después de la prueba, el autor es lo suficientemente estable y cree que se pueden realizar operaciones de metadatos puros de tamaño de subpágina, como reflink. El autor verificó la subpágina de datos leídos en los casos comprimidos y sin comprimir, verificó la lectura y escritura de las subpáginas de metadatos y también verificó la escritura de la página completa en el caso sin comprimir.
Este parche en realidad tiene muchas cosas que hacer, así como muchos desafíos. Por ejemplo, los datos (no metadatos) escritos en la subpágina no se implementan. Por ejemplo, la escritura de los datos de la subpágina es compatible con iomap.
Cuarto, virtualización
4.1 Extensión de memoria protegida KVM
== Antecedentes y problemas relacionados ==
Hay muchas características de hardware (como MKTME, SEV) que pueden evitar que se acceda a la memoria de la máquina virtual mediante un acceso no autorizado en el host. Este conjunto de parches propone una función de software pura que puede mitigar algunos de los mismos ataques de solo lectura del lado del host.
== ¿Qué ha aliviado este conjunto de parches? ==
-El kernel del host accede "accidentalmente" a los datos de la máquina virtual (considere la especulación)
-El kernel del host provoca el acceso a los datos de la máquina virtual (write (fd & guest_data_ptr, len))
-Host el espacio de usuario para acceder a los datos de la máquina virtual (como a través de QEMU manipulado)
-Elevar los privilegios de la máquina virtual a través de un simulador de dispositivo QEMU manipulado
== ¿Qué no alivia este parche? ==
-El kernel del host está completamente alterado. El kernel mapeará la página nuevamente
-Ataques basados en hardware
La segunda edición del conjunto de parches RFC aborda la mayoría de los comentarios.
Pero aún no encontré una buena solución para solucionar el reinicio y KEXEC. En estas operaciones, es necesario cancelar la protección de toda la memoria, lo cual es inconsistente con nuestro objetivo de esta función.
Antes de no proteger el contenido necesario para reiniciar (o KEXEC), limpiar la mayor parte de la memoria requiere mucho tiempo y es propenso a errores. ¿Quizás deberíamos declarar que estas operaciones no son compatibles?
== Descripción general de la secuencia ==
Cifre los datos de la máquina virtual mediante funciones de hardware y luego asegúrese de que solo la máquina virtual correcta pueda descifrarlos, protegiendo así los datos de la máquina virtual. El efecto secundario de esto es que el mapeo directo del kernel y el mapeo del espacio de usuario (utilizado por QEMU, etc.) se vuelven inútiles.
Sin embargo, esto nos brinda información muy útil: para las operaciones ordinarias de una máquina virtual, la asignación del kernel y la asignación del espacio del usuario a veces no son realmente necesarias.
En nuestro conjunto de parches, no usamos cifrado, simplemente desasignamos la memoria. En comparación con permitir el acceso al texto cifrado, una de sus ventajas es que el acceso incorrecto provocará excepciones y será detectado, en lugar de simplemente devolver datos basura como datos cifrados.
4.2 KVM: interfaz de anillo sucio
El parche se actualizó dos veces en octubre, y ambos se adaptaron a la última rama de KVM. Este trabajo es una continuación del trabajo de interfaz de anillo sucio de KVM realizado por Lei Cao <[email protected]> y Paolo Bonzini.
Esta nueva interfaz de anillo sucio es otra forma de que las máquinas virtuales recuperen páginas sucias. En muchos sentidos, es diferente de la interfaz de registro sucio existente, principalmente:
Formato de datos: los datos sucios ahora están en formato de anillo en lugar de formato de mapa de bits, por lo que el bit utilizado para sincronizar el registro de datos sucios ya no depende del tamaño de la memoria de la máquina virtual, sino de la velocidad de los datos sucios. Además, el nuevo anillo sucio es exclusivo de cada vCPU, mientras que el mapa de bits sucio es compartido por todas las vCPU y el mapa de bits sucio es por VM.
Copia de datos: la sincronización de páginas sucias ya no necesita copiar datos. Por el contrario, el anillo sucio se comparte en el espacio del usuario y el espacio del kernel a través del intercambio de páginas (a través de mmap en vcpu_fd)
Interfaz: cuando queremos restablecer las páginas sucias recopiladas al modo de protección nuevamente, el nuevo anillo sucio usa la nueva interfaz ioctl KVM_RESET_DIRTY_RINGS en lugar de la interfaz KVM_GET_DIRTY_LOG, KVM_CLEAR_DIRTY_LOG original. Para recopilar bits sucios, solo necesitamos leer los datos en el anillo sucio y ya no es necesario llamar a la interfaz ioctl.
(FIN)
更多精彩，尽在"Linux阅码场"，扫描下方二维码关注