Les actus du 15/06/2025

Publié le 15 Jun. 2025

🐧 Noyau Linux

EOL de la 6.14

La branche Linux 6.14 , publiée initialement le 24 mars 2025 , n’étant pas un noyau à support long terme (LTS), a atteint son End of Life (EOL) lors de la mise en ligne du point release 6.14.11 le 10 juin 2025. À partir de cette date, plus aucune correction ni mise à jour de sécurité ne sera effectuée pour cette série (kernel.org).

Le noyau 6.14.11 a été publié par Greg Kroah-Hartman, responsable de la maintenance des branches stables, marquant officiellement la fin de vie de la série 6.14. Dans son annonce, il incite vivement les utilisateurs à passer à la série 6.15 , plus récente et toujours maintenue, afin de bénéficier des derniers correctifs de stabilité et de sécurité (lxer.com).

Parmi les réactions de la communauté :

  • Tux Machines souligne l’importance de migrer dès que possible vers Linux 6.15 , rappelant que toute machine conservant la branche 6.14 restera vulnérable aux failles découvertes après la date d’EOL (news.tuxmachines.org).
  • Phoronix profite de la sortie concomitante de Linux 6.15.2 pour décrire les améliorations de performance et les correctifs critiques, encourageant la mise à niveau immédiate des systèmes de production (phoronix.com).

Liens utiles :

  • Annonce officielle du noyau 6.14.11 [EOL] sur The Linux Kernel Archives (kernel.org)
  • Article LXer : « Linux Kernel 6.14 Reaches End of Life, It’s Time to Upgrade … » (lxer.com)
  • Article Tux Machines : « Linux Kernel 6.14 Reaches End of Life … » (news.tuxmachines.org)
  • News Phoronix : « Linux 6.15.2 Released » (liée à la migration recommandée) (phoronix.com)

Évolution de la branche 6.15

La branche Linux 6.15 a été officialisée par Linus Torvalds le 25 mai 2025 , après une période de tests comprenant huit versions candidates. Cette nouvelle mouture apportait notamment :

  • Un premier aperçu du pilote Rust Nova pour GPU NVIDIA GSP, successeur de Nouveau (omgubuntu.co.uk, lkml.org)
  • Des gains massifs de performances sur exFAT (suppression d’un fichier de 80 Go en ~1,6 s contre > 4 minutes auparavant) (gbhackers.com)
  • De nombreuses évolutions réseau (zero-copy receive via io_uring, nouvelle option TCP_RTO_MAX_MS)
  • Des améliorations du support ARM/RISC-V et de pilotes (Apple Touch Bar, Xbox Turtle Beach, Ethernet Killer E5000…)

Linux 6.15.1 – 4 juin 2025

Moins d’une dizaine de jours après la sortie de la branche 6.15, Greg Kroah-Hartman a publié la version 6.15.1 pour corriger principalement un problème critique impactant certains portables équipés de GPU Qualcomm Snapdragon X1 : ceux-ci souffraient de surchauffe excessive , risquant d’endommager le matériel ou de provoquer des arrêts intempestifs.

  • Annonce officielle (message de Greg Kroah-Hartman) :

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.15.y (lwn.net)

  • Article de réaction (Phoronix) : « Linux 6.15.1 Ships With Fix To Prevent Snapdragon X1 GPUs From Severely Overheating » (phoronix.com)

Linux 6.15.2 – 10 juin 2025

Quelques jours plus tard, la version 6.15.2 est sortie pour résoudre un régression de consommation d’énergie au repos découverte sur certains systèmes : les états d’inactivité du CPU ne se déclenchaient plus correctement, entraînant une consommation bien supérieure à la normale et réduisant l’autonomie sur portables ou systèmes embarqués.

  • Annonce officielle (message de Greg Kroah-Hartman) :

Archive-link: https://lwn.net/Articles/1024715/ (lwn.net)

  • Article de réaction (Phoronix) : « Linux 6.15.2 Fixes « Quite Dramatically…Potentially Dangerous » Idle Power Regression » (phoronix.com)

Conclusion :

La branche 6.15, riche en nouveautés, a rapidement nécessité deux point releases pour corriger des régressions matérielles critiques. Tous les utilisateurs de 6.15 sont vivement invités à passer à la version 6.15.2 pour bénéficier de ces correctifs de stabilité et de sécurité.

La future 6.16

Voici un aperçu des principales nouveautés attendues dans la série Linux 6.16 , actuellement en cours de stabilisation avant sa sortie finale prévue vers la fin juillet 2025.

Performances et systèmes de fichiers

  • Optimisations d’EXT4 et Bcachefs

Linux 6.16 introduit des améliorations majeures sur EXT4 (support des « large folios » pour des écritures plus rapides et commits atomiques) ainsi que des évolutions notables dans Bcachefs, visant à augmenter les débits et réduire la latence sur gros volumes de données (phoronix.com, serverhost.com).

  • XFS et EROFS

L’écriture atomique multi-blocs pour XFS permet désormais d’assurer l’intégrité des métadonnées, tandis qu’EROFS profite des accéléra­tions matérielles Intel QAT pour améliorer les performances de décompression DEFLATE (serverhost.com).

Support matériel élargi

  • Cartes graphiques NVIDIA Hopper/Blackwell

Le pilote Nouveau prend enfin en charge les architectures GPU Hopper et Blackwell, offrant une prise en charge open source plus complète des cartes récentes (phoronix.com, serverhost.com).

  • Technologies Intel APX et ACR

Préparation à la nouvelle architecture Intel APX (Advanced Performance Extensions) ainsi qu’au mécanisme Auto Counter Reload, permettant un comptage matériel plus précis pour l’analyse de performances (phoronix.com, serverhost.com).

  • CXL RAS

La branche 6.16 intègre pour la première fois les fonctionnalités RAS de CXL (Patrol Scrub, Error Check Scrub, Memory Sparing), renforçant la fiabilité mémoire sur plateformes prenant en charge CXL (phoronix.com).

  • RISC-V SBI Firmware Features

Ajout du support de l’extension Firmware Features (FWFT) de l’interface SBI pour RISC-V, ouvrant la voie à une meilleure interaction avec le firmware et aux futures évolutions de la plate-forme (phoronix.com).

Nouveaux services et outils

  • Service systemd pour cpupower

Un nouveau service systemd permet de gérer automatiquement les fréquences CPU via cpupower, simplifiant l’administration des politiques d’économie d’énergie et de performance (serverhost.com).

  • Comptage des lockups par sysfs

Les locks durs et doux (hard/soft lockups) sont désormais exposés via des compteurs sysfs, facilitant le diagnostic et la supervision des blocages système (phoronix.com).

Renforcement de la sécurité et Rust

  • Clés chiffrées hardware-wrapped pour fscrypt

Intégration du support des clés protégées matériellement (hardware-wrapped) dans fscrypt, augmentant la sécurité du chiffrement de données (serverhost.com).

  • Extensions Rust

De nouvelles abstractions Rust sont introduites dans le cœur du noyau (gestion de listes, boucles locksafe…), poursuivant la montée en puissance de Rust comme langage de développement de modules (phoronix.com).

Conclusion

Le cycle de merge window pour 6.16 étant fermé depuis le 8 juin (RC1), la période à venir sera dédiée aux tests et à la correction des derniers bugs. Les sept à huit Release Candidates hebdomadaires qui suivront prépareront la version stable, attendue fin juillet ou début août 2025. N’hésitez pas à tester la RC1 pour remonter d’éventuels problèmes avant la publication finale.

Rappel des publications des noyaux

Voici un rappel du cycle de publication du noyau Linux, avec la durée de support associée à chaque type de branche :

1. Branches non-LTS (Mainline)

  • Merge Window (2 semaines)

Immédiatement après chaque sortie stable, la « fenêtre de fusion » ouvre pendant 2 semaines pour intégrer toutes les nouvelles fonctionnalités et gros patches.

  • Release Candidates (6 – 8 semaines)

Chaque semaine, une Release Candidate (rc1, rc2, …) est publiée pour corriger les bugs remontés. En général, on compte 6 à 8 RCs , soit 1,5 à 2 mois de stabilisation.

  • Version stable

Après la dernière RC, Linus Torvalds tague la version stable (par ex. 6.16).

  • Support post-release

Cette branche « non-LTS » reçoit ensuite quelques point-releases correctives (X.Y.1, X.Y.2…) durant environ 1 à 2 mois , jusqu’à ce que la suivante (merge window) prenne le relais.

Impact pour les distributions « cutting edge »

Elles peuvent adopter la dernière version stable dès sa sortie, mais doivent assurer un suivi très régulier des regressions et maintenir un cycle de tests continu.

2. Branches LTS (Long-Term Support)

Certaines versions majeures sont désignées LTS par la Linux Foundation et Greg Kroah-Hartman :

Version LTS Date de sortie Fin de support officiel
6.1 11 déc. 2022 31 déc. 2027 (≈ 5 ans) (endoflife.date)
5.15 31 oct. 2021 31 oct. 2026 (5 ans) (endoflife.date)
5.10 13 déc. 2020 31 déc. 2026 (6 ans) (endoflife.date)
5.4 25 nov. 2019 31 déc. 2025 (6 ans) (endoflife.date)
  • Durée typique : 2 à 6 ans selon la version et la demande.
  • Backports uniquement : seules les corrections de sécurité et de stabilité sont acceptées.
  • Point-releases régulières : environ tous les 2–4 mois, un patch-release (X.Y.Z) est publié pour intégrer les dernières corrections upstream.

Impact pour les distributions stables (Debian Stable, RHEL, Ubuntu LTS…)

Elles privilégient les noyaux LTS pour garantir une stabilité multi-annuelle et limiter le nombre de tests fonctionnels.

3. Branches SLTS (Super-Long-Term Support)

Le Civil Infrastructure Platform (CIP) prolonge certaines LTS en SLTS :

  • Versions concernées : 4.4-cip, 4.19-cip, 5.10-cip, 6.1-cip (et bientôt 6.12-cip).
  • Durée de support : jusqu’à 10 ans (voire plus, théoriquement jusqu’à 15 ans selon les besoins industriels) (wiki.linuxfoundation.org).
  • Objectif : répondre aux cycles de vie très longs (25 – 50 ans) des infrastructures critiques.

Impact pour les éditeurs industriels

Permet de s’appuyer sur un noyau stable sur une décennie, sans avoir à internaliser tous les backports.

Synthèse de l’impact pour les distributions

Type de branche Fréquence de sortie Durée de support Charge de maintenance
Mainline ≈ 3 mois (stable) ≈ 2 mois Très élevée
LTS ≈ 2 ans (sélection) 2 – 6 ans Modérée
SLTS/CIP Selon LTS + CIP Jusqu’à 10 ans Faible (backports)

Chaque distribution choisit le bon compromis entre accès aux nouveautés , stabilité et charge de tests , en fonction de son modèle (rolling vs release, usage industriel vs grand public, etc.).

DCO : révolution performance OpenVPN

Sources:

https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/dco.html

https://blog.openvpn.net/openvpn-data-channel-offload/

https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21065.html

https://patchwork.kernel.org/project/netdevbpf/patch/20220803153152.11189-1-antonio@openvpn.net/

Le pilote DCO (Data Channel Offload) qui vient d’être intégré au noyau Linux représente une avancée majeure pour les performances OpenVPN, avec des gains de débit jusqu’à 8 fois supérieurs grâce à l’élimination des commutations coûteuses entre espaces utilisateur et noyau. Cette innovation architecturale divise OpenVPN en deux plans : le plan de contrôle reste en espace utilisateur pour la sécurité, tandis que le plan de données migre vers l’espace noyau pour les performances. Accepté officiellement dans le noyau Linux 6.16 en avril 2025 après des années de développement, DCO transforme OpenVPN d’une solution purement userspace vers une implémentation hybride noyau/utilisateur qui conserve la sécurité tout en maximisant l’efficacité.

Définition et signification de DCO

DCO signifie « Data Channel Offload » (Déchargement du Canal de Données), un module noyau Linux qui déplace le traitement des données OpenVPN de l’espace utilisateur vers l’espace noyau. Cette architecture révolutionnaire sépare les fonctions OpenVPN en deux plans distincts :

Le plan de contrôle demeure en espace utilisateur pour gérer les aspects sécuritaires critiques : handshake TLS, négociation SSL/TLS (y compris TLS 1.3), authentification des pairs, échange de clés, gestion de configuration et traitement des erreurs. Le plan de données migre vers l’espace noyau pour optimiser les performances : chiffrement/déchiffrement des paquets, transmission et routage, intégration avec l’accélération matérielle, et traitement multi-threadé.

Cette séparation permet à DCO de conserver le modèle de sécurité éprouvé d’OpenVPN tout en éliminant le goulot d’étranglement principal qui limitait les performances : les commutations de contexte répétées entre espaces noyau et utilisateur pour chaque paquet de données.

Intégration récente au noyau Linux

L’intégration de DCO au noyau Linux s’est déroulée sur plusieurs années avec un processus de développement rigoureux. Le développement initial a commencé en 2020 sous la direction d’Antonio Quartulli d’OpenVPN Inc., créant d’abord un module externe ovpn-dco maintenu sur GitHub.

La première soumission RFC aux listes de diffusion du noyau Linux (LKML) a eu lieu en juillet 2022, déclenchant un processus d’examen intensif de la communauté noyau. Après plus de 25 révisions de patches et des années d’itérations, le pilote DCO a été officiellement accepté le 17 avril 2025 pour inclusion dans le noyau Linux 6.16.

Cette intégration mainline élimine le besoin d’installer des modules externes et garantit une disponibilité automatique dans les futures distributions Linux. L’implémentation officielle utilise le nom de module ovpn (remplaçant ovpn-dco) et bénéficie de mises à jour de sécurité automatiques via les patches noyau.

Avantages techniques et performances

Les gains de performance de DCO sont spectaculaires. Les tests officiels sur un processeur AMD ThreadRipper 3970x montrent des améliorations dramatiques : OpenVPN traditionnel atteignait 370 Mbps, DCO côté client seulement permet ~1 110 Mbps (amélioration de 3x), tandis que DCO des deux côtés atteint ~2 950 Mbps (amélioration de 8x).

Ces performances proviennent de plusieurs optimisations techniques clés. L’élimination des commutations de contexte supprime le coût CPU élevé des transferts répétés entre espaces noyau et utilisateur. Le traitement multi-threadé permet le chiffrement parallèle sur plusieurs cœurs CPU, contrastant avec l’approche mono-thread traditionnelle.

L’intégration avec l’accélération matérielle exploite directement les API crypto noyau et les capacités d’accélération : Intel QAT pour les performances maximales AES-256-GCM, IPsec-MB pour de bonnes performances multi-algorithmes, AES-NI pour l’accélération matérielle de base, et un fallback logiciel qui offre encore des gains significatifs.

Les opérations zéro-copie minimisent les copies mémoire, le traitement par lots process plusieurs paquets ensemble, et l’utilisation d’instructions SIMD exploite les capacités vectorielles CPU pour optimiser davantage les performances.

Fonctionnement technique détaillé

L’architecture DCO implémente une intégration sophistiquée avec les sous-systèmes de réseau Linux. Le module crée des interfaces réseau virtuelles de type ovpn qui implémentent les opérations netdev standard et supportent IPv4 et IPv6.

Le chemin de réception (RX) des paquets suit un pipeline optimisé : réception des paquets chiffrés par la pile réseau, démultiplexage socket pour router vers la bonne interface ovpn, déchiffrement via l’API crypto noyau, validation et authentification de l’intégrité des paquets, puis routage vers l’interface réseau appropriée.

Le chemin de transmission (TX) inverse le processus : réception des paquets depuis l’interface virtuelle, chiffrement avec les clés spécifiques au pair, encapsulation avec les en-têtes protocole OpenVPN, puis transmission via socket UDP/TCP vers le pair distant.

DCO utilise une API Netlink générique pour la communication espace utilisateur, permettant la création/destruction d’interfaces, la gestion des pairs (ajout/suppression/énumération), les opérations de clés (ajout/suppression/rotation), et les requêtes statistiques. Cette API garantit une intégration propre avec l’écosystème Linux existant.

Limitations et considérations actuelles

Malgré ses avantages, DCO présente des limitations importantes à considérer. Le support chiffrement est restreint aux algorithmes AEAD uniquement : AES-256-GCM, AES-128-GCM, et ChaCha20-Poly1305. Le protocole transport est limité à UDP uniquement, sans support TCP.

Les configurations réseau ne peuvent pas utiliser de réseaux tunnel /30 ou inférieurs, et le routage interne OpenVPN (iroute) n’est pas supporté. Les fonctionnalités de compression sont désactivées avec DCO, et le support bridging est limité.

DCO nécessite OpenVPN 2.6.0 ou ultérieur et fonctionne uniquement avec des tunnels basés TLS. L’installation requiert les en-têtes noyau Linux, et certaines fonctionnalités OpenVPN legacy ne sont pas compatibles. Le suivi d’utilisation données per-peer n’est pas précis, et les systèmes secure boot nécessitent une configuration additionnelle.

Adoption industrielle et perspectives

L’adoption de DCO s’accélère significativement dans l’industrie. OpenVPN Inc. l’a intégré dans OpenVPN 2.6.0+ et Access Server 2.12.0+. Netgate/pfSense propose DCO dans pfSense Plus 22.05+, et Microsoft Windows dispose d’un pilote DCO pour Windows 10 20H1+.

Les déploiements en production incluent CloudConnexa d’OpenVPN et plusieurs fournisseurs VPN majeurs. L’intégration mainline dans Linux 6.16 garantit une disponibilité automatique future dans toutes les distributions Linux modernes.

Les perspectives d’avenir sont prometteuses : élimination complète des modules externes, mises à jour sécurité automatiques, support étendu pour périphériques embarqués, et développement continu pour compatibilité fonctionnalités additionnelles.

Conclusion

Le pilote DCO représente une évolution architecturale majeure qui transforme OpenVPN d’une application purement userspace vers une implémentation hybride noyau/utilisateur sophistiquée. En déplaçant le plan de données critique pour les performances vers l’espace noyau tout en préservant le plan de contrôle sécuritaire en espace utilisateur, DCO atteint des améliorations de performance dramatiques sans compromettre le modèle de sécurité d’OpenVPN.

Cette innovation positionne OpenVPN comme une solution VPN haute performance compétitive, particulièrement adaptée aux environnements entreprise nécessitant débit élevé et efficacité. L’intégration mainline dans Linux 6.16 valide l’approche technique et assure une disponibilité et un support long terme, faisant de DCO un choix attractif pour les déploiements VPN modernes exigeants.

FreeBSD 14.3 est de sortie

FreeBSD célèbre le 10 juin 2025 la sortie de sa version 14.3, quatrième mise à jour de maintenance de la branche stable 14. Fidèle à sa philosophie « Engineering OS », cette release n’a rien d’une révolution : elle affine et consolide les fondations posées par FreeBSD 14.0 en novembre 2023, tout en préparant la voie vers FreeBSD 15, attendu fin 2025.

Un héritage de stabilité et d’innovation

Depuis ses origines, en novembre 1993, FreeBSD s’est imposé comme un système d’exploitation performant et fiable. La version 9.0, parue en janvier 2012, marque le premier grand tournant moderne en remplaçant GNU GCC par Clang/LLVM, une décision qui libère le projet des contraintes de licence et améliore la qualité du code . Deux ans plus tard, FreeBSD 10.0 introduit bhyve , son hyperviseur de type 1, et achève la transition vers des outils sous licence BSD (gcc, gdb, BIND remplacés par Clang/LLVM, LLDB et Unbound), posant les bases d’une virtualisation légère et fiable .

En avril 2021, la branche 13 enrichit encore le noyau : isolation accrue des pilotes réseau, support natif de WireGuard et renforcement de la pile ARM 64 bits, utilisés notamment sur Raspberry Pi et AWS . Puis, en novembre 2023, FreeBSD 14.0 franchit un nouveau cap : le système de fichiers OpenZFS 2.2, la prise en charge du TPM et du GPU passthrough dans bhyve, la gestion de jusqu’à 1024 cœurs CPU et la possibilité d’exécuter fsck UFS en tâche de fond viennent renforcer la robustesse et la flexibilité de l’OS .

FreeBSD 14.3 : raffinement et modernisation

La version 14.3, disponible dès maintenant, agrémente la branche 14 de mises à jour ciblées. Parmi les nouveautés phares, on note d’abord un support Wi-Fi modernisé : le pilote Intel iwlwifi gère enfin le mode 802.11ac/ax (Wi-Fi 5/6 et certaines puces Wi-Fi 7), fruit d’un effort soutenu de la FreeBSD Foundation et d’un enrichissement du LinuxKPI. Les drivers Realtek rtw88 et rtw89 importés depuis Linux viennent corriger diverses fuites mémoire et problèmes d’association, comblant un retard notable face à Linux .

Le LinuxKPI (Linux Kernel Programming Interface) est une couche de compatibilité qui permet de porter des pilotes Linux (notamment les drivers Wi-Fi, GPU, etc.) dans l’environnement FreeBSD avec un minimum de modifications :

  1. Principe
    • Ensemble de fichiers d’en‐tête C (.h) et de stubs qui réinterprètent les appels d’API Linux (les « KPI ») vers les fonctions équivalentes de FreeBSD.
    • L’objectif est que le code source original du pilote Linux puisse être compilé et exécuté quasiment « tel quel » sous FreeBSD (cdaemon.com).
  2. Usage courant
    • drm-kmod (pilotes graphiques Intel/AMD) s’appuie sur LinuxKPI pour porter le code DRM de Linux, avec quelques ajustements spécifiques FreeBSD.
    • Les pilotes Wi-Fi modernes (iwlwifi, rtw88, rtw89) utilisent LinuxKPI pour gérer les interfaces 802.11ac/ax sans repartir de zéro (freebsdfoundation.org).
  3. Avantages
    • Gain de temps : pas besoin de réécrire entièrement les pilotes Linux sous FreeBSD.
    • Mises à jour plus rapides : adopter les correctifs et nouvelles fonctionnalités des drivers Linux en grande partie.
  4. Limites et perspectives
    • Couverture incomplète : certaines interfaces Linux n’étant pas mappées, il peut manquer des fonctionnalités (ex. debugfs) ou apparaître des régressions de performance.
    • Travail de « clean room » nécessaire pour réécrire sous licence BSD le code GPL des parties non compatibles, afin d’éviter tout problème de licence.

En résumé, LinuxKPI est la brique technique qui fait de FreeBSD une plateforme capable d’héberger rapidement les pilotes Linux, tout en conservant la cohérence et la fiabilité du noyau FreeBSD.

Pour répondre aux pratiques de déploiement actuelles, FreeBSD 14.3 publie également des images officielles au format OCI , disponibles sur Docker Hub et GitHub Packages. Elles permettent de tester et déployer FreeBSD dans un conteneur sans passer par une machine virtuelle complète .

1. OCI, c’est un format, pas un moteur d’exécution

L’OCI définit uniquement :

  • Un format d’images (couches, métadonnées)
  • Une API de bas-niveau pour démarrer un conteneur (le runtime)

Mais il n’impose pas le noyau utilisé : Linux, FreeBSD, Windows… (en.wikipedia.org).

En pratique, un runtime OCI (comme runc sur Linux) va :

  1. Lire l’image
  2. Monter ses couches (overlayfs, etc.)
  3. Configurer l’isolation (namespaces, cgroups, etc.)
  4. Lancer le processus dans le conteneur

Sur FreeBSD, les mécanismes équivalents existent (jails, VNET, flags de sécurité), mais le runtime Linux (runc) ne fonctionnera pas directement.

2. Docker « standard » ne tourne pas nativement sur FreeBSD

  • Le Docker Engine officiel (daemon + dockerd) est conçu pour Linux et s’appuie lourdement sur les namespaces et cgroups du noyau Linux.
  • Il n’existe pas de port officiel de Docker Engine sur FreeBSD.

Vous ne pouvez donc pas démarrer un conteneur FreeBSD (ou même Linux) avec le Docker Engine « out-of-the-box » sous FreeBSD.

3. Pour exécuter une image OCI FreeBSD

Il faut :

  1. Un hôte FreeBSD (ou un noyau FreeBSD, même dans une VM).
  2. Un runtime OCI adapté à FreeBSD , capable de transformer une image OCI en jail FreeBSD.

Quelques options expérimentales :

Exemple sommaire de mise en place :

pkg install runj containerd nerdctl
service containerd start
# Pull de l'image FreeBSD
nerdctl pull freebsd:14.3
# Exécution en tant que jail via runj
nerdctl run --rm freebsd:14.3 uname -a

4. Pourquoi Docker Hub et GitHub ?

Publier sur Docker Hub/GitHub Container Registry facilite l’accès :

  • Vous pouvez faire un docker pull freebsd:14.3 (ou ctr images pull ghcr.io/freebsd/14.3) depuis n’importe quel poste…
  • …mais pour en tirer parti, c’est votre runtime (sur FreeBSD) ou une VM FreeBSD qui doit prendre le relais.

En revanche, tenter de lancer docker run freebsd:14.3 sur un hôte Linux échouera : le noyau Linux ne peut pas directement exécuter un binaire FreeBSD.

Au cœur du noyau, un nouvel appel système setcred() offre désormais la possibilité de définir en une seule opération l’ensemble des identités d’un processus (UID/GID réels, effectifs et étiquetage MAC), renforçant la granularité du contrôle Mac Policy. La gestion des jails s’enrichit elle aussi : on peut désormais configurer des paramètres sysctl à distance pour une jail enfant (donc sans avoir besoin de s’y connecter en ssh ou console) et utiliser un nœud « mac » commun pour ses réglages MAC,

  • MAC ici signifie Mandatory Access Control , c’est-à-dire les mécanismes de contrôle d’accès obligatoires (modules comme mac_biba, mac_mls, mac_portacl, etc.).
  • Chaque jail pouvait déjà être associée à un ou plusieurs labels MAC, mais avec la granularité limitée au moment de la création.
  • Nœud “mac” commun : on dispose maintenant d’un seul point de configuration (une arborescence sysctl ou un pseudo-système de fichiers dans /sys signalant “mac”) qui regroupe tous les réglages MAC applicables à la jail enfant.
  • Cela permet de consulter et modifier en un même endroit l’intégralité des politiques MAC (par exemple : quels processus ou quels fichiers la jail peut accéder) sans avoir à jongler avec plusieurs interfaces ou répertoires.

tandis que VNET gagne des tunables réseau spécifiques à chaque jail dès l’amorçage .

  • VNET : c’est la fonctionnalité de FreeBSD qui donne à chaque jail son propre pile réseau virtuelle (interfaces, routage, pare-feu, etc.), isolée du reste de l’hôte et des autres jails.

  • Tunables réseau : variables de configuration du sous-système réseau (tailles de buffer, queues, comportements de congestion, etc.) qu’on peut régler au démarrage du noyau via /boot/loader.conf ou dynamiquement via sysctl.

  • Spécifiques à chaque jail dès l’amorçage signifie qu’au moment où la jail est lancée, on peut lui appliquer directement des valeurs de tunables réseau différentes de celles de l’hôte ou d’autres jails, sans nécessiter de réglages manuels après coup.

  • Concrètement, on pourrait écrire dans la configuration de la jail :

    ini
CopierModifier
vnet = new;
vnet.interface = epair0b;
vnet.sysctl.net.inet.tcp.sendbuf_max = 262144;
vnet.sysctl.net.ip.forwarding = 1;

et ces paramètres seront pris en compte automatiquement au boot de la jail.

La stack OpenZFS passe en version 2.2.7, intégrant les dernières optimisations de compression LZ4 et des correctifs de performance, et le bootloader UEFI voit sa compatibilité avec les tables SMBIOS 64 bits consolidée pour les machines récentes .

Sécurité et performances consolidées

Le chantier sécurité englobe l’intégration de tous les advisories depuis la 14.2 : correctifs dans OpenSSH, NFS, ktrace, et mise à jour d’OpenSSL 3.0.16 avec un bundle de certificats racine rafraîchi. Le firewall pf propose un nouveau tunable, net.pf.default_to_drop, pour basculer en « default deny » sans recompilation du noyau . Côté userland, les utilitaires sont actualisés : xz 5.8.1, expat 2.7.1, less 668 et LLVM/Clang 19.1.7 viennent optimiser le quotidien des administrateurs.

Réactions et impact

L’accueil de FreeBSD 14.3 est largement positif. Sur Reddit, la communauté salue unanimement le support Wi-Fi amélioré, même si quelques retours sur des cas limites subsistent . Un utilisateur illustre bien l’amour-haine entretenu avec FreeBSD : « J’ai réinstallé la 14.2 puis fait la mise à jour vers 14.3 : là le Wi-Fi marche… et c’est le driver graphique qui lâche ! »

https://www.reddit.com/r/freebsd/comments/1l7l23z/freebsd_143release_announcement/#:~:text=Instalei e o Wi,caso de amor e ódio

Sur le plan écosystémique, pfSense et OPNsense profiteront directement des correctifs et de la meilleure prise en charge des chipsets Intel i225/i226 pour leurs appliances. Quant à TrueNAS Core, iXsystems a déjà orienté ses développements vers TrueNAS Scale (Linux), mais la 14.3 améliore la prise en charge du 100 GbE et corrige plusieurs bugs NFS qui pourraient bénéficier aux déploiements FreeBSD. De son côté, Netflix , utilisateur historique pour son CDN Open Connect, déploie généralement les commits FreeBSD en 5–15 semaines, atteignant jusqu’à 90 Gb/s de trafic TLS par serveur avec seulement 55 % de CPU, démonstration de la robustesse de l’OS .

FreeBSD 14.3 n’est pas une révolution, mais une étape solide qui renforce les atouts d’un système déjà réputé pour sa fiabilité et sa performance. Elle prépare le terrain pour FreeBSD 15, qui marquera la fin du support des plateformes 32 bits et inaugurera la prochaine ère de l’ingénierie système BSD.

Nouvel appel système FreeBSD 14.3

Le nouvel appel système setcred() introduit dans FreeBSD 14.3 n’est pas un mécanisme de création de nouveaux processus, mais un moyen atomique de modifier en une seule fois l’ensemble des credentials (UID réel, effectif et sauvé ; GID réel, effectif et sauvé ; groupes supplémentaires ; et même le label MAC) du processus courant.

1. Pourquoi pas les appels traditionnels ?

Historiquement, pour changer d’identité (par exemple passer d’un UID 0 à un UID non privilégié) on utilisait :

  1. un binaire setuid root ;
  2. à l’intérieur, une suite d’appels (seteuid(), setegid(), setgroups(), etc.) dans un ordre précis (il faut en général appeler setuid() en dernier pour ne pas perdre les privilèges avant d’avoir réglé tous les autres IDs) ;
  3. un fork/exec si l’on veut lancer un autre programme sous cette nouvelle identité.

Ce “montage en plusieurs étapes” a deux inconvénients principaux :

  • fenêtre d’exposition : entre les appels, le processus peut temporairement avoir des droits intermédiaires (ni root, ni l’utilisateur cible), ce qui ouvre une surface d’attaque pour un éventuel exploit.
  • manque de contrôle fin : le noyau ne peut pas appliquer de politique MAC (« Mandatory Access Control ») en connaissant à la fois l’ensemble des anciens et nouveaux credentials, puisqu’il voit chaque appel séparément. (man.freebsd.org)

2. Que fait setcred() ?

  • Atomicité : tous les champs de credentials passent de l’ancien état au nouvel état dans un même appel. Il n’y a pas de moment où le processus est dans un état “intermédiaire” potentiellement dangereux.
  • Hooks MAC : le framework MAC (en particulier le module mac_do(4)) peut regarder avant et après l’appel pour décider si la transition est légitime, selon des règles administrateur. Par ex., on peut autoriser le passage de root à un UID précis avec certains groupes, mais interdire tout autre mélange (lists.freebsd.org).
  • Pas besoin de nouveaux processus : contrairement à un fork/exec, le même PID change simplement ses credentials. Utile dans des démons qui doivent temporairement “s’abaisser” en privilèges pour effectuer une tâche, puis remonter (ou vice-versa) sans recréer de processus.

3. Exemple d’usage simplifié

#include <sys/syscall.h>
#include <unistd.h>
#include <err.h>
#include <sys/types.h>
#include <sys/ucred.h>

struct setcred {
    uid_t uid;
    uid_t ruid;
    uid_t svuid;
    gid_t gid;
    gid_t rgid;
    gid_t svgid;
    int ngroups;
    gid_t *groups;
    /* optionnel : MAC label */
    void *mac_label;
};

int
main(int argc, char **argv)
{
    struct setcred sc;
    gid_t grplist[] = {100, 101};

    sc.uid     = 1000;   /* nouvel effective UID */
    sc.ruid    = 1000;   /* real UID */
    sc.svuid   = 1000;   /* saved UID */
    sc.gid     = 1000;
    sc.rgid    = 1000;
    sc.svgid   = 1000;
    sc.ngroups = 2;
    sc.groups  = grplist;
    sc.mac_label = NULL; /* pas de changement de label */

    if (syscall(SYS_setcred, SETCREDF_UID|SETCREDF_GID|SETCREDF_GROUPS,
                &sc, sizeof(sc)) < 0)
        err(1, "setcred");
    /* À partir d’ici, le processus est passé en UID/GID 1000 atomiquement */
    /* ... */
    return 0;
}

Ici, le flag passé en premier argument (une combinaison de SETCREDF_UID, SETCREDF_GID, SETCREDF_GROUPS, etc.) indique quels champs de struct setcred doivent être pris en compte.

4. Bénéfices concrets

Caractéristique Ancien mode (setuid+binaires) Avec setcred()
Atomicité Non (en plusieurs appels) Oui (tout dans un seul appel)
Surface d’attaque Fenêtre entre appels Nulle pour la transition
Politique MAC Impossible de voir transition globale Possible via hooks MAC/do
Création de process Souvent fork+exec Pas nécessaire

En résumé

L’intérêt de setcred() n’est pas de créer un nouveau processus, mais de transformer en toute sécurité et atomiquement les credentials d’un processus existant, tout en s’intégrant à la couche MAC de FreeBSD pour un contrôle fin des transitions.

Partagez cet article !