Linux kernel 6-19

Introducció

Fa poques setmanes va sortir la versió del kernel 6.19, amb canvis importants i un anunci per part de Linus Torvalds: la fi de la era 6. La següent release començarà ja a utilitzar la nomenclatura 7, estrenant-la amb la 7.0.

Però a més d’aquest anunci, s’han implementat moltes millores en aquesta última versió, així que sense més preàmbuls, anem al gra.

API de DRM Color Pipeline

Per explicar aquest canvi del kernel primer cal saber com Linux “dibuixa” sobre la pantalla.

Aqui tenim els següents components claus:

• Hardware: Targetes gràfiques, monitors i Display Controller. Aquests dispositius poden tenir circuiteria per fer certes funcions de manera molt eficient.

• DRM (Direct Rendering Manager): Codi dins el kernel que controla pantalles i GPUs. Aquest està dividit en dues parts:

  • Codi compartit

  • Codi específic de venedor

• Driver d’espai d’usuari: Treballa amb el codi del venedor del DRM per aprofitar al màxim les capacitats de la GPU.

Bàsicament DRM habilita la GPU i dona control al driver d’espai d’usuari que després implementa OpenGL, Vulkan,…

Només amb DRM i el driver no en tenim prou, ja que sinó hauriem de recompilar cada programa per cada driver específic. Per això també tenim:

• Display server: Proveeix una manera estandaritzada per programes per parlar a la resta del sistema i mostrar les seves parts per pantalla (X/Wayland).

• Compositor: Encarregat de les regles per mostrar imatges (com barrejar els colors, com han de veure’s les finestres, com processar cada frame,…). Bàsicament és l’encarregat de preparar la imatge per ser mostrada.

El problema que té això és que el compositor està molt lluny del hardware i no aprofita les instruccions especials que puguin tenir per “preparar” la imatge, llavors la feina la fa el compositor en comptes de fer-la el hardware dedicat, a més que envia un estàndard que potser no és el que espera la pantalla.

La solució

Per poder aprofitar les funcions del hardware i lliurar de feina al compositor, s’ha implementat la DRM Color Pipeline API.

S’ha creat les operacions drm_colorop, que s’encadenen formant una llista. Aquesta llista la utilitzarà el compositor per interrogar al kernel durant la inicialització, i saber quines operacions de color suporta el driver, oferint avantatges com:

• Aprofitar el hardware dedicat per processar les imatges.

• Manera estandaritzada de processar frames via drm_colorop (es pot eliminar el codi del compositor que ho feia).

• Compatibilitat amb HDR més senzilla (no s’ha d’implementar tota una capa de compatibilitat per HDR, només fer una llista de drm_colorop que sabem que funcionarà per un frame HDR).

• Passthrough: Si el hardware pot fer tota la feina de processament de frames, el compositor només deixa passar la imatge sense aplicar-li cap operació, fet que redueix la latència.

https://www.kernel.org/doc/html/v6.19-rc7/gpu/rfc/color_pipeline.html

Eliminació de barreres d’especulació en l’accés a l’usuari

Per parlar d’aquest canvi, primer hem d’explicar què és la execució especulativa (ja vam explicar-ho breument a la release anterior però refrescarem memòria):

Execució especulativa

Les CPUs modernes per anar més ràpid intenten predir les instruccions que necessitaran. Si arriba a una instrucció que la obliga a triar, no espera a saber si la adreça és segura, tria un camí i comença a executar.

El perill es troba precisament en aquestes decisions: un atacant pot enganyar la CPU perquè especuli amb una adreça de memòria del kernel. En aquest cas, tot i que la CPU posteriorment s’adonaria de l’error i cancel·laria la operació, ha quedat rastre a la cache i això permetria filtracions.

La solució que hi havia fins ara era l’ús de barreres: la CPU especulava fins que arribés a una d’aquestes eleccions, on parava fins que estigués segura que les adreces fossin segures i les que toquen. El problema que afegeix aquesta solució és que es perd molt rendiment (bàsicament anul·lem la execució especulativa quan ens trobem en aquests punts).

Nova solució

En els sistemes de 64 bits, la memòria es divideix en:

• Espai d’usuari

  Les adreces de memòria comencen per 0.

• Espai de kernel

  Les adreces de memòria comencen per 1.

Partint d’aquest principi s’ha implementat una màscara de bits per determinar si el kernel pot o no accedir a la posició, i fa el següent:

1. SAR (shift arithmetic right)

   Movem 63 posicions a la dreta, deixant com a primer bit l’original que hi havia.

   text

      1010 0010 -> després d'un moviment -> 1101 0001 -> al final -> 1111 1111

2. SHR (shift logical right)

   Partint del resultat anterior, movem tots els números a la dreta i al primer lloc deixem un 0.

1111 1111 -> 0111 1111

1. NOT

   Negarem el resultat (invertir 0s i 1s)

0111 1111 -> 1000 0000

1. AND

   Amb el resultat que hem obtingut i el valor original farem una operació AND.

1000 0000
1010 0010

1000 0000

Com podem veure, en aquest exemple el resultat és una adreça d’espai de kernel però amb aquestes transformacions la hem eliminat, ja no tenim el valor.

Si per contra, ho fem amb una adreça d’espai d’usuari, sempre ens donarà la mateixa adreça sense transformar-la, pel que la CPU només podrà especular amb adreces dins l’espai d’usuari.

Nou subsistema TSM

La computació confidencial ha anat millorant darrerament, però hi havia un apartat que quedava fora: els bus PCI-express.

La computació confidencial consisteix en aïllar una màquina virtual del seu host, presuposant que el host pugui ser atacat o segrestat per algú maliciós. Això es fa a nivell de CPU i cada fabricant ofereix la seva solució (Intel TDX i AMD SEV).

El problema és que si voliem parlar amb un dispositiu connectat per PCI-express, aquestes dades encriptades dins la VM s’havien de desencriptar, enviar a través d’un buffer compartit que pugui utilitzar el dispositiu PCI-e i tornar-se a encriptar. Això, a més de lent és insegur.

PCI-e 7.0

PCIe 7.0 integra nous estàndards de seguretat per dispositius PCIe:

• IDE

  Integrity and Data Encryption: Encriptació d’extrem a extrem entre el dipositiu PCIe i la CPU.

• TDI

  Tee Device Interface: Permet dividir un dispositiu en seccions independents i assignar aquestes seccions a diferents VMs de manera aïllada.

• CMA-SPDM

  Component measurement and authentication: Protocol que permet a la VM verificar que el hardware és el que diu ser.

Com funciona?

1. La màquina virtual demana accés a un recurs

2. El TEE (part segura de la CPU) contacta amb el hardware PCIe

3. Es crea un túnel encriptat

4. El dispositiu PCIe té DMA (Direct Memory Access) sense passar per buffers

Tot això aporta un rendiment més proper al natiu en màquines virtuals i més seguretat de la informació.

Arquitectures

x86 Intel

S’ha afegit suport per LASS (Linear Address Space Separation), una característica que defensa contra atacs side-channel.

x86 AMD

S’ha afegit SDCI (Smart Data Cache Injection), que permet agafar dades d’un dispositiu PCI a la memòria de la CPU.

ARM64

S’ha implementat suport per MPAM (Memory System Resource Partitioning and Monitoring).

LoongArch

Comença la implementació per sistemes de 32 bits.

RISC-V

S’ha afegit suport per HOTPLUG_PARALLEL, amb el que serà més ràpid habilitar nuclis secondaris en SoCs.

Sistemes de fitxers

ext4

• Optimització per defragmentació online.

• Suport per mida de bloc major que mida de pàgina de kernel

NTFS

Ara suporta timestamps d’abans de 1970.

HFS

Encara té suport, s’han implementat fixes i neteges al codi.

Bloc

Per moure dades entre disc i RAM, el kernel utilitza una estructura BIO.

Per crear un objecte BIO, el kernel ha de demanar memòria a l’Slab allocator (gestor de memòria). El problema d’això ve quan molts nuclis de la CPU volen demanar memòria alhora, que es produeixen bloquejos entre ells enlentint el sistema (i fent Slab el coll d’ampolla).

Per solucionar això s’ha implementat el Full per-CPU BIO caching. En comptes de demanar memòria nova cada vegada, cada nucli del processador guarda una cache de BIOs que s’han utilitzat i estan lliures. Així quan es necessita un nou BIO, el nucli mira la seva cache i, al ser local dins el nucli, no ha d’esperar ni bloquejar res, simplement l’utilitza.

Aquest sistema existia però en aquesta versió s’han modificat comportaments perquè sigui segur davant interrupcions, i ara ve habilitat per defecte.

Criptografia

S’ha implementat una optimització sobre AES-GCM que dona fins a un 74% més de rendiment en CPUs AMD Zen 3 i millors similars en altres arquitectures. Això és degut a que ara el kernel aprofita millor les instruccions AVX2.

VM

AMD x2AVIX (una tecnologia per gestionar interrupcions en màquines virtuals) ara suporta fins a 4096 vCPUs.

S’ha remodelat part del codi d’Intel TDX per arreglar systemic races (problemes que podien desencadenar en errors o vulnerabilitats).

LUO (Live Update Orchestrator) és una funció basada en kexec que permet que un kernel passi el control a un altre sense haver de reiniciar el sistema (però perdent la memòria això si), un gran avenç en un futur on no calgui reiniciar després d’una actualització.

GPU/Audio

El driver nouveau (driver open source per GPUs Nvidia) ara suporta una mida de pàgina més grossa i també suporta compressió. Aquesta millora és important perquè les gràfiques no són tan bones com el CPU a l’hora de moure’s entre pàgina.

S’ha afegit suport per audio d’Intel Nova Lake + Xe3P iGPU.

Xarxa

Fins ara el kernel utilitzava un mecanisme de cua amb bloquejos, pel que si molts processos volien enviar paquets alhora, la CPU estava més temps esperant que no enviant dades.

Ara s’ha implementat un sistema de llista lockless (sense bloquejos), donant fins a 4 cops més rendiment sota càrregues altes.

Altres

S’ha guanyat eficiència en sistemes massius gràcies a millores en MM CID (Memory Management Concurrency ID), aprofitant millor els recursos en sistemes amb molts nuclis. A més, s’ha reescrit RSEQ (Restartable Sequences) per integrar-se millor amb MM CID i guanyar un 14% de rendiment en aplicacions que depenen molt de memòria (com bases de dades).

També s’han implementat millores en la funció printk(), donant rendiments fins a 20 vegades superiors en situacions específiques.

Hardware

A més, s’ha afegit suport pel següent hardware:

• Tenstorrent Blackhole SoC (RISC-V)

• Black Sesame Technologies C1200 (hardware per cotxes)

• StarFive VisionFive 2 Lite Risc-V Board

Conclusió

Tot i no ser l’actualització més vistosa en termes de rendiment pur per a un usuari d’escriptori convencional, la versió 6.19 és un salt de gegant en els fonaments del sistema. La implementació de la DRM Color Pipeline, el nou subsistema TSM i les millores en la gestió de memòria i xarxa preparen Linux per a un futur on l’eficiència i la seguretat en entorns complexos (com la computació confidencial o l’HDR) són prioritaris.

Aquest kernel ens deixa un sistema més robust, més ràpid en operacions crítiques de servidor i totalment preparat per a la transició cap a la futura branca 7.0.

I fins aquí el post d’avui! Quina d’aquestes millores creus que tindrà més impacte en el teu setup? Si t’ha semblat útil, pots deixar un comentari o compartir-lo a les teves xarxes. Ens veiem al següent!